How to Build a Product Roadmap
When Everything Feels Like a Priority
At early stage, every customer request feels urgent, every competitor move feels threatening, and every team member has a different idea of what to build next. A roadmap isn’t a wish list — it’s a set of deliberate bets. Here’s how to build one that actually guides decisions.
- What a roadmap is actually for (and what it isn’t)
- The one question that cuts through every priority debate
- How to collect and weigh input without being pulled in 10 directions
- The prioritisation framework that works without a product team
- How to structure a roadmap for seed vs Series A
- Communicating the roadmap to customers and investors
- When to change it — and when not to
What a Roadmap Is Actually For
A roadmap is a communication tool, not a promise. It communicates your current best judgment about what the product should do next and why — to your team, your customers, and your investors. The moment you treat it as a fixed delivery schedule, it becomes a source of anxiety rather than clarity.
At early stage specifically, a roadmap serves three jobs: it forces you to articulate the bets you’re making (which surfaces disagreements before they become expensive), it gives your team enough direction to work without needing you in every decision, and it gives customers and investors a credible picture of where the product is going. It does not need to be detailed, quarterly-slotted, or shared publicly to do these jobs.
The roadmap trap: building a roadmap that makes everyone happy instead of one that reflects your actual priorities. A roadmap that has 40 items “in progress” or “coming soon” is not a roadmap — it’s a backlog with optimistic dates. A useful roadmap has 3–5 items in the next 90 days and deliberately leaves other things off it.
The One Question That Cuts Through Every Priority Debate
When you’re stuck on what to prioritise, this question cuts through: “What’s the single thing that, if we shipped it in the next 60 days, would most move the metric we care most about right now?”
The follow-up question is equally important: “What’s our evidence that this is true?” Not our belief, not our hypothesis — our evidence. Customer interviews, usage data, churn reasons, sales objections. If you can’t point to evidence, you’re prioritising on instinct. That’s sometimes fine, but it should be a conscious choice, not a default.
How to Collect and Weigh Input Without Being Pulled in 10 Directions
The most damaging roadmap inputs: the loudest customer (who may not represent the ICP), the most recent customer conversation (recency bias), and internal opinions from people who aren’t talking to customers regularly. None of these should drive the roadmap alone.
A simple input framework: collect feature requests systematically (a shared doc, a Notion board, or a lightweight tool like Canny), tag each with the source and the customer segment, and review the full list together rather than acting on individual requests in real time. The pattern across multiple requests from the right customer segment is the signal. The single urgent request from your noisiest customer is noise.
Weight inputs by: how many customers raised it, how closely those customers match your ICP, whether it’s blocking sales or driving churn, and whether it aligns with the direction you’re building. A feature that 2 customers asked for but that 8 prospects mentioned as a blocker in sales conversations is worth more than a feature 6 customers requested but that doesn’t affect acquisition or retention. For synthesising this kind of feedback fast, see our AI Customer Research Stack.
“Here is my current product backlog: [list your items]. My most important metric right now is [metric — e.g. activation rate, churn, NRR, conversion to paid]. My ICP is [describe]. Help me: (1) Score each item on its likely impact on my north star metric (high/medium/low), (2) Score each item on effort (high/medium/low), (3) Flag any items that are likely to be requested by customers but won’t actually move retention or revenue, (4) Suggest the 3–5 items I should commit to in the next 60 days and explain why. Be direct — I need a prioritised list, not a framework to do it myself.”
The Prioritisation Framework That Works Without a Product Team
RICE (Reach × Impact × Confidence ÷ Effort) is the most commonly recommended framework and the one most founders abandon after one use because it requires too much estimation. A simpler version that actually gets used: score each item on three dimensions, 1–3, where 1 is low and 3 is high.
Revenue/retention impact: will this directly affect whether customers pay or stay? Customer signal strength: how many customers have explicitly asked for or been blocked by this? Effort: 1 = days, 2 = weeks, 3 = month+. Multiply impact × signal ÷ effort. Sort descending. The top of that list is your roadmap. It won’t be perfect — but it’s better than instinct and faster than RICE.
How to Structure a Roadmap for Seed vs Series A
Seed stage roadmap: 3 columns — Now (current sprint), Next (next 60 days), Later (everything else). No dates on Later. No more than 5 items in Now. The whole thing fits on one page. Its primary audience is your team and co-founder — keeping you aligned on what you’re actually building.
Series A roadmap: introduces quarterly themes (not features — themes, like “reduce time-to-value” or “enterprise readiness”), with specific initiatives under each theme. Investors at Series A want to see that you’re making strategic bets, not just responding to customer requests. The roadmap should reflect a thesis about where the market is going and how you’re positioning ahead of it. See our PRD playbook for how to spec individual roadmap items once priorities are set.
Communicating the Roadmap to Customers and Investors
Two versions of the roadmap: internal (specific, with owners and effort estimates) and external (directional, with themes rather than features and no dates). Never share the internal version with customers or investors. The external version should communicate your strategic direction without creating contractual expectations about delivery timelines.
When customers ask “when will feature X be ready?” the honest answer is almost always: “It’s on our roadmap. I can’t give you a firm date but I can tell you what’s ahead of it and why.” This is more trustworthy than a made-up date, and it gives you an opportunity to understand how important the feature actually is to them — which informs the priority.
When to Change It — and When Not To
Change the roadmap when: a significant new data point (a major customer churning over a specific missing feature, a competitor shipping something that changes the landscape, discovery of a new high-value use case) changes what’s actually most important. Don’t change it because one loud customer pushed hard or because a team member had a new idea in a brainstorm.
The test: does this new information change what we believe the most important thing to build is? If yes, update the roadmap explicitly and communicate the change and the reason. If no — if it’s just a competing voice for something already considered — log it in the backlog and move on. A roadmap that changes every two weeks isn’t a roadmap; it’s a symptom of unclear priorities.
Get 50 more prompts for product, growth, and prioritisation — free.