The Roadmap Is a Story, Not a Spreadsheet
Lead with themes and a narrative; link out to the systems for the granular how
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 93%
Zhang's core roadmapping rule: a scored spreadsheet of projects is not prioritization and it is not a roadmap. What teams actually crave is a story that explains why this body of work matters. The roadmap artifact is a written prose document of themes, linking out to the live systems (e.g. Jira) for detail, so it never goes stale.
Origin
Zhang's own practice, developed at Airbnb, WeWork and Webflow and taught in her Stanford PM course. She explicitly contrasts it with the RICE scoring framework (Intercom's reach-impact-confidence-effort model), which she says people mistake for prioritization.
Core principles
- 01Humans need to know why they are doing a body of work; scores do not supply that.
- 02Themes are the altitude of a roadmap; the team owns the how and the projects.
- 03Prose forces the granularity that a deck's bullet points hide.
- 04A spreadsheet is a snapshot at a point in time and goes stale; the team's live system does not.
- 05New learning should change the story and the themes, not just the numbers in a cell.
How to run it
- 1
Articulate the narrative in your own head first
Before writing anything, get crisp on the story you believe about your users and your product area, and the assumptions inside it. This is what new learnings will later update.
- 2
Write a prose document, not a deck or a sheet
In a remote or hybrid culture a deck needs a voiceover to make sense. Force yourself to write full prose — the act of writing adds the level of granularity that bullets skip.
Pro tip Structure the doc as: what we're trying to achieve, the big areas to invest in, the themes, then the big projects under each theme.
- 3
State themes as the levers, not projects as line items
Name the biggest things to invest in and the biggest levers to pull. Give the team the scaffolding to know what matters and let them generate the actual projects and details.
Watch out Do not descend into the granular how — that is the team's job and it is what keeps the roadmap from being maintainable.
- 4
Link out to the live system for the snapshot
Instead of embedding a prioritization spreadsheet, link the themes out to the actual artifacts and systems the team works in (Jira or equivalent), so anyone can see the current state at any point in time.
Watch out Spreadsheets and docs go out of date because they are frozen snapshots; a link to the working system never does.
- 5
Edit the themes only when a learning is major
When you learn something that invalidates an assumption — e.g. that your user base is far more non-technical than you assumed — rewrite the theme. Otherwise leave it and let the linked systems carry the churn.
Pro tip Standardize the artifact templates across teams (Zhang invested in a product operations function to do exactly this — it 'greases the wheels' and gets teams speaking the same language).
In the wild
Zhang describes discovering mid-cycle that the product had far more non-technical (or far more power) users than assumed. In a spreadsheet model, that produces a round of cell-tweaking. In the story model, that single input rewrites the narrative and therefore the themes.
→ The roadmap changes in a dramatic and coherent way, because the input hits the level of the story rather than the level of the scores.
Zhang's teams maintain shared artifacts — the general product development process, spec templates, broader roadmap templates — and invested in a product operations function to share and evolve them across teams.
→ Teams take the artifacts and tweak them but speak the same language, reducing the friction of every cross-team handoff.
Common mistakes
Mistaking a scored spreadsheet for prioritization
Filling in impact, cost and effort columns for every project and presenting it to the team does not tell anyone why they are doing the work, so it neither aligns nor motivates.
Presenting the roadmap as a deck in a remote culture
Decks require a voiceover to be understood. Asynchronously, they lose the reasoning, which is the entire payload of a roadmap.
Is it for you?
Best for
Product leaders and heads of product who need a whole team to internalize why a quarter's work matters, especially in remote or hybrid orgs
Not ideal for
Situations demanding hard capacity trade-off arbitration between many equal-sized items where a scoring model genuinely adds signal, or a single-squad team with one obvious next thing
From the transcript
“for Road mapping my biggest thing that I tell my teams is you're telling a story”
“what people what humans really crave is like why am I doing this body of work”
“tell a story what are your themes make it so that your team can come come up with the actual like how and the projects”
“so often docs get out of or like spreadsheets get out of date right because they're they're like a snapshot of whatever it is that…”
From the episode
Building minimum lovable products, stories from WeWork and Airbnb, and thriving as a PM
Jiaona Zhang (Webflow, WeWork, Airbnb, Dropbox)