Impact-first roadmap
Six weeks of engineering, in two teams, pointed at a belief nobody had checked.
FlowDesk's board saw themes, their leadership saw objectives, their engineers saw features — one timeline, four altitudes. Which is how, in August, a single failed assumption pruned both teams' plans in an afternoon.
"Feature F ships in Q4 because objective O." A roadmap that can't finish that sentence is a Gantt chart.
Steps 01–02
Leadership sets themes. Teams decide how to answer them.
FlowDesk is a 40-person product org: a retention team, a platform team, 400 customers.
A theme is an organisation-wide bet about where the year goes — reducing churn, customer centricity, an international launch. It has a name and a share of the investment, and that's deliberately all it has.
Each product team then writes its own objective for how it intends to support that theme. The objective comes from the team, which is the point of the split. FlowDesk's retention team chose a churn number. Their platform team chose setup time.
Both were legitimate answers to "reduce churn," and both were planned in the same two quarters, which is exactly where the interesting problem starts.
Themes in slides and objectives in a tracker always agree, because nothing ever checks them against each other.
Step 03 · July
Two objectives, two teams, one unexamined belief
Nobody duplicated anything deliberately. They both read the same theme and drew the obvious conclusion.
Everyone at FlowDesk believed onboarding was too hard. Because objectives on this roadmap carry the assumption they rest on, both teams' Q4 plans showed the same badge: cause — onboarding too hard.
That's the duplicate a roadmap can actually catch: two teams betting six weeks of engineering on one claim nobody had sourced. They were building different things.
Import wizard v2
Four weeks, two features. Assumes the blocker is effort.
Guided setup flow
Two weeks, one feature. Assumes the blocker is effort.
Steps 04–05
One roadmap, four conversations
The altitude changes with the audience. The structure underneath doesn't.
Because every card knows its parent, you can zoom to whoever is in the room without maintaining a second artefact for them.
Four sentences, four audiences, one object. The common alternative is a slide for the board, a spreadsheet for leadership and a ticket queue for engineers, which go out of sync by week three.
Step 06 · August
One assumption fell, and the roadmap pruned itself
This is the state most roadmaps cannot represent at all.
The evidence said the churning accounts had already finished onboarding. The objective stayed exactly where it was, and because both teams' epics descended from the same failed assumption, the roadmap could show what to stop in one afternoon in August, rather than half-built in October.
A roadmap needs four states: planned, in flight, stopped and why, and shipped but not yet proven. With only the first two available, roadmaps drift into fiction by week six and get rebuilt from scratch every quarter.
The value of a roadmap is how cheaply it lets you change your mind in public.
Investment share
The allocation was right. The reasoning under it wasn't.
Which is the honest case for putting investment share on the roadmap at all.
FlowDesk's split across themes never changed. Reducing churn deserved the majority of the year in July and still deserved it in December.
What changed was that a theme gained an owner. The dispatcher didn't exist in the company's plans in July. By August, depot experience had a persona attached to it and an argument for growing next year.
January
The roadmap was the review. There was no separate deck.
One timeline showing what was planned, what stopped and why, what shipped, and what is still being assessed — including the objective that reached 15% against a 12% target and stayed open. Nobody assembled it the week before.
Fair questions
What people ask about roadmap planning
- Who sets the themes, and who sets the objectives?
Themes are organisation-wide and usually leadership's call — reducing churn, customer centricity, an international launch — with a share of the investment attached. Each product team then writes its own objectives for how it will support the themes that apply to it. That separation is what stops a roadmap becoming a task list handed downward.
- Is this a timeline roadmap or a now-next-later one?
Intervals are yours to define — quarters, releases, sprints, or three fuzzy horizons. In the demo, quarters, because the board meets quarterly. What matters structurally is themes above and objectives below. Column width is yours.
- Can I show a different level to different audiences?
That's the main reason to build it this way. Same roadmap, zoomed: themes and investment for a board, objectives per quarter for leadership, epics for a product team, features with their parent objective for engineers. No second artefact to keep in sync.
- Won't dates turn into promises?
They do when the only states are planned and done. Items here can also be stopped with a reason, or shipped and still in assessment, so a changed mind reads as evidence rather than as a slip.
- How does this catch duplicate work across teams?
Because objectives carry the assumption they rest on, two teams betting on one belief appear under the same theme with the same badge. In the demo, the duplicate is two teams funding one unsourced claim while building different features.
- We're one team. Do we need two levels?
Probably not yet. Use objectives on a timeline and add themes when you have more teams than you can hold in your head, usually around the third one.
Can your roadmap tell an engineer why their feature exists?
Put your themes and your objectives on one timeline, and every altitude answers from the same object.
FlowDesk is the Shorter Loop demo workspace. The theme-to-feature chain, the four states and the single zoomable timeline is live in it — open it and check any number here.