Every product manager has built a roadmap. Most of us have also built one that quietly died — reviewed in a quarterly planning session, celebrated with a slide deck, and then never quite executed. The features got deprioritised, the engineers got pulled onto something urgent, and by Q3 the roadmap looked nothing like reality.
I've managed roadmaps across gift card payment platforms across gift card payments, e-commerce, and a large B2B marketplace. Each context was different, but the failure modes were identical. Over time I developed a framework that's made my roadmaps stick. Here it is.
The Core Problem: Roadmaps Are Often Built for the Wrong Audience
The first mistake most PMs make is building a roadmap for leadership — to show progress, justify headcount, or impress investors. This creates a document that's optimised for looking good in a presentation rather than guiding a team. When the rubber meets the road at sprint planning, nobody knows how to translate the roadmap into actual work.
A roadmap has two jobs: communicate direction to stakeholders, and guide daily prioritisation for the team. Most roadmaps only do the first. The ones that get shipped do both.
My Framework: The Three-Layer Roadmap
I structure every roadmap in three layers, each serving a different audience and time horizon:
Layer 1 — The Strategic Layer (6–12 months)
This is the "why" and the "where." It captures the big bets, the OKRs they map to, and the outcome we're trying to drive. No feature names, no timelines — just direction. This layer is for leadership, investors, and cross-functional heads. It should fit on one slide and hold up to the question: "How does this move the needle on our company goals?"
Real example: At my current employer, our strategic layer for 2023 was simple — "Reduce partner onboarding time from several months to a few weeks, enabling several new partners this year." Everything on the roadmap had to connect back to that.
Layer 2 — The Quarterly Layer (3 months)
This is where features start appearing, but framed as outcomes, not outputs. Instead of "Build new API endpoint," it says "Enable real-time transaction status for acquirers — reducing support tickets meaningfully." Each initiative maps explicitly to a Layer 1 goal. This layer is what you review with your direct stakeholders every quarter.
Layer 3 — The Sprint Layer (2 weeks)
This is the actual work — epics broken into stories, prioritised by business value and development effort. This layer lives in JIRA. It's where the roadmap either becomes real or stays fiction. The key discipline is ruthless scope control: only what fits in the sprint gets committed.
The Alignment Tax — Pay It Upfront
The biggest time investment in roadmap execution isn't planning — it's alignment. Every stakeholder who isn't involved in building the roadmap becomes a potential blocker later. I've learned to pay the "alignment tax" upfront rather than in delays.
My process:
- Discovery interviews: Before finalising any quarter's roadmap, I do 1:1 conversations with every major stakeholder — engineering lead, design, ops, sales, customer success. I ask: "What's the most painful unsolved problem in your world right now?" These conversations surface priorities I'd otherwise miss and build buy-in before anything is announced.
- Pre-mortem sessions: With the engineering lead, I run a pre-mortem before committing any quarterly roadmap. We ask: "It's three months from now and this initiative failed — what happened?" This surfaces technical risks early enough to act on them.
- Stakeholder review with an edit window: I share the draft quarterly roadmap with stakeholders two weeks before finalising, with explicit permission to push back. No surprises at go-time.
The Sprint Accountability Loop
Where most roadmaps break down is the gap between the quarterly plan and the sprint board. The quarterly layer says "Build partner API by end of March," but the sprint board fills up with urgent bug fixes and last-minute requests. By March, the API is only partially done and the roadmap is already fiction.
The fix is a weekly ritual I call the roadmap health check. Every Monday, for ten minutes, I ask three questions with the engineering lead:
- Are we on track for this sprint's commitments?
- Has anything entered the sprint that wasn't on the roadmap?
- If yes — what do we drop to compensate?
The third question is the hard one. It forces a conscious trade-off instead of letting scope silently expand. In practice, this ten-minute check has saved me from countless late-quarter scrambles.
When to Say No — And How
A roadmap is only as good as what it excludes. Every "yes" to a new request is implicitly a "no" to something already committed. The trick is making that trade-off visible.
When a stakeholder brings an urgent request mid-quarter, I use a simple framing: "Absolutely, we can add this. Here's what it will push out — does that trade-off work for you?" Nine times out of ten, when the cost of the "urgent" request is made concrete, the urgency evaporates.
The one exception: customer-impacting production issues always jump the queue. Everything else is a negotiation, not a mandate.
Measuring Roadmap Health
I track two metrics every quarter:
- Planned vs delivered ratio: What percentage of the quarterly commitments shipped? Healthy teams typically run in the 70–80% range. Below that range means planning is too ambitious. Consistently above 85–90% usually means teams are sandbagging.
- Unplanned work ratio: What percentage of sprint capacity went to things not on the roadmap? Healthy is typically below a quarter of sprint capacity. Above roughly a third is a signal that something upstream — stakeholder management, incident volume, or technical debt — needs attention.
The Mindset Shift That Made Everything Click
The most important shift I made was moving from thinking of the roadmap as a commitment to thinking of it as a hypothesis. A roadmap is your best current guess about what will create the most value over the next few months, given what you know today. New information should change it.
This doesn't mean the roadmap is disposable. It means treating it as a living document — reviewed and adjusted with intention, not abandoned whenever something shiny appears. The discipline is in the adjustment process, not in rigid adherence to a plan built months ago.
Build for outcomes. Align early. Guard the sprint. And always, always make trade-offs visible. That's how roadmaps actually get shipped.
