skip to content

Search

Why Most Product Roadmaps Fail, and What to Build Instead

Less than one minute read Updated:

Roadmaps feel productive. But most of them are planning theater, a coordination artifact mistaken for a decision-making tool.

# product-management
# strategy
# leadership
# roadmaps
Not in series

A roadmap with a date on every row is not a plan. It is a list of promises nobody has tested yet.

I have sat in the planning meeting at three companies: supply-chain platforms at Dell, an AI creative platform at Pixis, the data layer under InMobi’s ad exchange. Every one of those roadmaps had dates on every row. Fewer than half of the rows had a reason attached to them.

At Pixis, the roadmap that actually worked was the shortest one. Fifteen-plus voice-of-customer interviews on the Prism launch surfaced far more feature ideas than the team could build in a quarter. Five shipped. Forty were declined, on purpose, each with a reason written down.

This post is about the gap between those two roadmaps: the one with a date on every row, and the one with a reason.

So that’s today’s post.

Today’s Post

Why the artifact keeps winning over the argument, in five sections.

  • Why a roadmap with dates is not a decision system
  • The four moments a feature becomes politically untouchable
  • What a decision system looks like instead, with a real one
  • Why the quarter makes the trap worse
  • What Pixis did with 15+ interviews, and the number it produced

1. A roadmap is a list. A decision is a system.

Most roadmaps confuse two different documents.

The first is a feature list: what will ship, and when. The second is a decision system: what you believe, what would prove you wrong, and what you will do about it. Most teams write only the first one and call it strategy.

A feature list has one state. A decision system has three. Same three rows, two documents. Only one of them has a place to write down why. Grey monospace text names where each row comes from. FEATURE LIST DECISION SYSTEM A date, next to a feature name one state: not done, then done quarter first, reason later or never Hypothesis, risk, signal, threshold three states: draft, approved, implemented specs/ROADMAP.md, this site Moves to done because the date arrived the calendar decided no review required Moves to implemented because the eval went green the evidence decided spec passed review first Killing a row reads as a broken promise political, not analytical removing it feels like failure Declining a row is a written reason, on record Pixis, Prism launch 5 shipped, 40 declined, each with a reason feature list: a promise with no place for a reason decision system: a bet with a written reason
Same three rows, two documents. Only one of them has a place to write down why. PNG ↓

Look at the difference on this site’s own spec-driven SDLC project. specs/ROADMAP.md is one file, and every row carries a status: draft, approved, or implemented. A row does not move to implemented because a date arrived. It moves because a spec passed review and an eval went green. The roadmap is the backlog, not the plan; the specs behind each row are the plan.

That is a small mechanical difference with a large consequence. A feature-list roadmap has one state per row: not done, then done. A decision-system roadmap has three, and the middle one, approved, is where a bad bet gets caught before a single line of code ships.

2. The four moments a feature becomes untouchable

The reasons roadmaps calcify are predictable. I have watched all four happen at three companies.

Moment 1 - A date gets attached

The date: once a feature has a quarter next to it, removing it reads as missing a commitment instead of correcting a plan.

Moment 2 - A designer starts mocks

Sunk design time: the mock exists, so killing the feature now feels like throwing away work, even though the mock cost a day and shipping the wrong feature costs a quarter.

Moment 3 - Engineering estimates the work

The estimate: an estimate reads like a contract, even though it was a guess made before anyone knew whether the feature mattered.

Moment 4 - A stakeholder puts it in a deck

Social weight: the feature now belongs to someone’s credibility in a board meeting, and pulling it embarrasses a person, not just a plan.

None of these four moments is a decision about value. Each one is friction accumulating on a row that nobody has re-argued since the day it was written.

3. What a decision system looks like instead

A decision system replaces “ship by Q3” with four fields per row: hypothesis, risk, signal, threshold.

Hypothesis: what will change, for whom, and why you believe it.

Risk: the assumption most likely to be wrong.

Signal: the metric that tells you whether the assumption held.

Threshold: the number that triggers kill, pivot, or scale.

The threshold is the field most roadmaps skip Four fields per row, and a return loop for the one row in four that gets killed. Grey monospace text names the concrete case: a Pixis onboarding bet. Hypothesis what changes, for whom and why you believe it brand self-serves a live ad Risk the assumption most likely to be wrong brand won't trust the model Signal the metric that tests the assumption live on-brand ad, not a login Threshold the number that triggers kill, pivot, or scale 4 brands live inside 2 weeks Decided: kept, killed, or changed the reason goes in the log $800K ARR in 2 months, 4 brands back to the backlog, re-argued what you believe and how you'll know the judgement call before you build the number written before the review, not during it a row that outlives the feature
The threshold is the field most roadmaps skip, and it is the one that decides the other three. PNG ↓

The Pixis onboarding sprint ran exactly this loop. The hypothesis was that a brand would self-serve a live, on-brand ad inside two weeks. The risk was that the brand would not trust the model with its own creative. The signal was a published ad, not a login. The threshold was four brands live inside the window. It cleared, and the sprint produced $800K ARR in two months before the full motion reached $10M ARR in five.

That fourth field, the threshold, is the one most roadmaps skip, and it is the one that matters. Without a number written down before the feature ships, every review becomes a negotiation about what “good enough” means, argued by whoever is most senior in the room that day.

4. The quarter makes it worse

Quarters are an accounting convention, not a unit of customer insight. Most roadmaps organize themselves by Q1 through Q4 anyway, as if a customer’s problem waits politely for a fiscal boundary.

Watch what that produces. A team spends the last two weeks of Q1 in crunch mode finishing a “Q1 commitment” that new evidence already made irrelevant. Quality drops because the deadline, not the customer, is setting the pace. Q2 starts already behind, because the crunch borrowed two weeks it never had.

A two-week crunch borrows time Q2 never had Same three weeks. One lane spends them finishing a stale commitment, the other spends them checking a threshold. Grey monospace text is what the team is doing at each moment. Scroll slowly, this plays once. last 2 weeks of Q1 Q1 close first 2 weeks of Q2 FEATURE LIST, ORGANIZED BY QUARTER THRESHOLD WRITTEN BEFORE THE SPRINT Crunch mode finishing a Q1 commitment the date is setting the pace Threshold check did the signal clear the bar the number is setting the pace Quality drops already-slipping evidence, ignored shipped anyway, on the date Kept, killed, or changed decided against the written number shipped, held, or dropped Q2 starts behind the crunch borrowed 2 weeks nobody chose this Q2 starts clean the row moved, the sprint didn't slip booked on ship day the calendar deciding the pace the written threshold deciding the pace
Same three weeks. One lane spends them finishing a stale commitment; the other spends them checking a number it wrote down in advance. (animates as you scroll to it) PNG ↓

None of that is a resourcing problem. It is a calendar that rewards finishing over correcting, and punishes the one skill that actually matters here: changing your mind while there is still time to act on it.

5. What Pixis did with 15+ interviews

At Pixis, the Prism launch ran 15+ voice-of-customer interviews before a single roadmap row got written. Those interviews did not produce five ideas. They produced far more feature candidates than five weeks of engineering could touch.

The discipline was not picking the five best features from the pile. It was writing down, for each of the other forty, the specific reason it was not the bet worth the next stretch of work. Declining is not automatic if it is silent. Declining has to be a decision, on the record, or the same idea resurfaces next quarter with a new champion attached.

15+ interviews produced more ideas than the roadmap needed The interviews are the wide bar. Shipping five of them is the narrow one, and forty got a reason instead of a slot. Bar length is proportional; the number in monospace is the count. Voice-of-customer interviews, Prism launch before a single roadmap row was written 15+ Feature ideas the interviews surfaced every one of them a plausible roadmap row many Shipped Prism roadmap 5 Declined, each with a written reason not silence, a decision that a stale row cannot resurface without 40 shipped, and measured against a threshold declined on the record, not forgotten
The interviews are the wide bar. Shipping five of them is the narrow one, and forty got a reason instead of a slot. PNG ↓

Prism shipped with five features, each carrying a threshold, and a documented reason for each of the other forty. The launch moved trial-to-paid up 25% and cut onboarding time 40%.

Takeaways

Why most roadmaps fail, and the fix Five sections on trading a feature list for a decision system, with numbers from Pixis and this site Hoshank Ailani · hoshank.vercel.app 1. List vs system FEATURE LIST DECISION SYSTEM one state: not done, done draft, approved, implemented moves on because the date arrived moves on because the eval went green killing a row: a broken promise declining a row: a written reason no place to write why a row that outlives the feature a promise a bet with a reason attached source: specs/ROADMAP.md, this site's own build 2. Four untouchable moments A date gets attached to the row A designer starts mocks Engineering estimates the work A stakeholder puts it in a deck none of the four is a judgement about value, each one is friction on a row nobody re-argued the mock cost a day, the wrong feature costs a quarter 3. The four fields per bet 1 Hypothesis: what changes, for whom 2 Risk: the assumption most likely wrong 3 Signal: the metric that tests it 4 Threshold: written before the review $800K ARR in 2 months, 4 brands, one written threshold 4. The quarter makes it worse last 2 weeks of Q1 → crunch, quality drops Q1 closes → shipped on the date, not the evidence first 2 weeks of Q2 → Q2 starts behind the calendar decided the pace, nobody chose that 0 weeks of runway a Q1 crunch actually had to borrow 5. What Pixis did with 15+ interviews 1 15+ voice-of-customer interviews, Prism 2 Far more feature ideas than the roadmap needed 3 40 declined, each with a written reason 4 5 shipped, measured against a threshold +25% / −40% trial-to-paid up, onboarding time down, Prism launch 6. What to change on your own roadmap Add a hypothesis field to every row Write the threshold before the sprint starts Book the review the day you ship Write down why you declined a row a roadmap row with a date and no reason is a promise nobody has tested yet unwritten means undecided A roadmap with a date on every row is a list of promises nobody has tested yet. The test: pick the last row you killed, and check whether the reason is written anywhere. Full post: hoshank.vercel.app/posts/why-most-product-roadmaps-fail Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Five panels, one per section. The callout is the thesis, and the test to run on the last row your team killed.

Final Words

Most teams already have a roadmap. What they are missing is a place to write the reason: the hypothesis before the build, the threshold before the review, and the sentence that explains why a row got declined instead of quietly forgotten.

Pick the last feature your team shipped, or the last one you killed, and write the four fields it should have had.

Reply and tell me what you found. I am collecting the misses for a follow-up.

Cheers, Hoshank