How do you prioritize a product roadmap?

Roadmap prioritization fails when teams treat it as a scheduling problem instead of a judgment problem. The real work is deciding which problems are worth solving at all — then sequencing ruthlessly. Do that well and your team ships less, learns faster, and compounds toward something users actually remember.

Start with the problem, not the feature list

Most roadmaps are graveyards of good intentions. A feature gets added because a customer asked for it, a competitor shipped it, or someone in a planning meeting said it sounded reasonable. None of those are sufficient reasons. Before anything enters your roadmap, you need to answer three questions: Who is harmed by the absence of this? How often? How badly? If you cannot answer all three concretely, the idea is not ready to be prioritized — it is ready to be researched or discarded.

This is where stakeholder context earns its keep. Garry Tan's approach to issue quality, as described in the gstack spec, emphasizes explaining who cares about a problem and why — from the end-user perspective, the product perspective, and the engineering perspective simultaneously. That triple framing forces you to surface whether a feature is genuinely valuable or just internally convenient. A feature that helps your sales team close deals but adds friction for the actual user is a different kind of bet than one that reduces churn for your highest-value segment. Naming the difference explicitly is the first act of real prioritization.

Practically, this means every item on your roadmap should have a one-paragraph problem statement before anyone writes a spec. Not a solution description — a problem description. Who experiences this? When? What do they do instead today, and why is that insufficient? Teams that skip this step spend engineering cycles solving imaginary problems and then wonder why adoption is low.

Ruthless sequencing: what only you can do right now

Once you have a legitimately validated problem, the sequencing question is separate and equally hard. The default instinct is to prioritize by impact score — some version of reach times magnitude divided by effort. Frameworks like RICE exist for this reason and they are useful as a forcing function. But Rik Haandrikman's observation about the consumer app market points to a failure mode in pure impact scoring: anything that is hard to measure gets cut. Delight, tone, a moment of surprise — these do not score well in a RICE spreadsheet, so they get deprioritized until the product is technically complete and completely forgettable.

The better sequencing question is: what can only this team, with this particular insight, ship right now? Not what has the highest expected value in a vacuum, but what is uniquely ours to build given what we know that nobody else knows yet. That framing separates roadmap items into two buckets — table stakes that any competent team could eventually ship, and differentiated bets that compound your specific advantage. Table stakes need to exist, but they should not dominate your sequencing. You should be spending disproportionate energy on the second bucket.

A useful heuristic: if a feature could appear on a competitor's roadmap without anyone being surprised, it is probably table stakes. If it requires a specific belief about your users that your competitors have not yet formed, it is a differentiation bet. Sequence your differentiation bets first, and hire or automate your way through the table stakes.

Cut more than you think you need to

The most common roadmap mistake is not bad prioritization — it is too much volume. When you have forty items ranked by priority, items eleven through forty are still on the list, still consuming planning bandwidth, still creating the impression that they might get done this quarter. They will not. The psychological overhead of maintaining a long backlog costs more than most teams realize: engineers have to context-switch mentally around items they are not working on, PMs spend time re-defending deprioritized items, and the team loses the sense that they are making real choices.

Paul Graham's argument in 'Life is Short' — that treating finite quantities as discrete rather than continuous forces honest accounting — applies directly here. If you have twelve engineering weeks in a quarter, you have twelve. Listing thirty features does not expand that supply. Making the scarcity concrete — 'we have eight weeks of real shipping capacity after accounting for bugs and incidents, what are the eight most important things we will not regret skipping?' — forces a different quality of conversation than 'here is our prioritized backlog.'

In practice, a healthy roadmap for a seed-stage team probably has three to five items in the current sprint, three to five in the next cycle, and a deliberately vague future bucket for everything else. If you have more specificity than that beyond two cycles, you are doing fiction, not planning. Market conditions change, users surprise you, and the thing you learn from shipping the current sprint will reshape what matters next.

How to defend prioritization decisions under pressure

Roadmap prioritization is not a one-time event — it is a repeated negotiation between your team's judgment and everyone else's opinions. Customers want their specific request. Investors want the feature that sounds impressive in a board deck. Sales wants whatever closes the next deal. If you do not have a clear framework for saying no, the roadmap becomes a political document rather than a strategic one.

The most durable defense is showing your reasoning, not just your conclusions. When you decline a feature request, the explanation that builds trust is not 'we scored it lower than other items' — it is 'here is the user problem we are actually solving this quarter, here is why solving it first unlocks more value than solving your request first, and here is when we will revisit your request.' That response requires you to have done the problem-first work described above, which is another reason it matters.

For internal pressure, the discipline of verifying current state before proposing changes is critical. Before your team commits to a roadmap item, you should be able to point to specific evidence — user interviews, behavioral data, support ticket clusters — that confirm the problem is real. Garry Tan's engineering practice of citing specific code before proposing changes reflects the same instinct: assumptions made from memory or intuition are far more expensive than assumptions verified against evidence. Apply that to product decisions and you will ship fewer wrong things.

The thing that scoring frameworks miss

RICE, ICE, the Kano model — these tools are genuinely useful scaffolding, but they all share a structural blind spot: they measure what you can already measure. They are retrospective instruments being used to make prospective bets. The things that make a product truly worth using — a flow that feels effortless, a moment of unexpected delight, a voice that sounds like it was written for exactly this user — resist quantification, so they get filtered out before they have a chance to matter.

Rik Haandrikman's point about consumer apps is that clean onboarding and a tested paywall are now baseline competence, not competitive advantage. The apps that retain users and grow through word of mouth are the ones that feel like they were made by people who care, not assembled from best-practice components. That quality is a product roadmap decision. It means occasionally prioritizing a polish sprint with no measurable output metric, investing in copy and tone as seriously as you invest in feature development, and resisting the pressure to ship something half-finished because momentum demands it.

The practical implication: every roadmap cycle should include at least one item whose value is primarily qualitative. Call it a 'heartbeat item' — something that exists to remind users that a human team built this product and cares whether they love it. It will not score well in any framework. Ship it anyway.

“Building has never been easier. Getting memorable has never been harder. That gap is where the real work happens now.”

— Rik Haandrikman, source

The one thing to do

Before your next planning session, delete every roadmap item that lacks a written, evidence-backed problem statement naming a specific user, their frequency of pain, and why existing alternatives fail them.

Frequently asked questions

Should I use a scoring framework like RICE to prioritize my roadmap?

Scoring frameworks are useful for forcing explicit trade-offs and surfacing hidden assumptions, but treat them as a starting point for conversation, not a final answer. They systematically undervalue qualitative outcomes like delight and brand voice, so compensate by deliberately protecting space for items that resist easy measurement.

How do I handle customers who lobby for specific features?

Separate the request from the underlying problem. Customers are usually right about the pain they are experiencing and often wrong about the best solution. Acknowledge the pain specifically, explain what problem you are solving this cycle and why it takes priority, and give a concrete date when you will revisit their request.

How far out should a product roadmap look?

For most early-stage startups, one quarter of detailed commitment and one quarter of directional intent is the practical limit. Beyond that you are making bets, not plans — and the learning from what you ship this quarter will substantially change what matters next quarter.

What is the most common mistake founders make when building a roadmap?

Listing too many things. Volume creates the illusion of productivity while actually diffusing focus, consuming planning bandwidth, and delaying the discovery of what actually matters. Cut your list until it is uncomfortable, then cut it once more.

Sources

More playbook answers · Growth Prophet home