Most roadmaps fail the same diagnostic test. When asked "why is this on the list?" they cannot produce a clear answer. The reason is rarely lack of effort. It is the absence of a framework rigorous enough to filter input from execution. Without it, every loud voice gets a feature, and the roadmap becomes a record of internal politics rather than product strategy.
The Aha! framework for product development is built around answering four questions in order. This article borrows that backbone from the Aha! framework guide and reduces it to a working version any PM team can implement this quarter.
Why frameworks matter (especially when you do not want one)
The pushback against frameworks is real. They can become bureaucracy. They can slow down decision making. They can produce documentation theater that nobody reads.
But the alternative is worse. Without a framework, every roadmap decision relies on the personal judgment of whoever is in the room loudest. Frameworks externalize the criteria, so the judgment is repeatable and defensible. The best frameworks are not heavy. They just make the implicit explicit.
The 4 questions, in order
Question 1: Who are we serving?
Not "who are our users" in the abstract. Who specifically are we serving with this roadmap initiative? Which segment, with which job-to-be-done, in which situation?
Common failure: "all users". That answer is almost always wrong. Products serve specific people doing specific things. A roadmap that cannot name the target segment for an initiative is making decisions on instinct.
Concrete test: can you name the customer interview that informed this initiative? If yes, you probably have a real answer to Question 1. If no, the initiative is speculative.
Question 2: Why does it matter?
Once you know who you are serving, why does this initiative matter to them and to the business? What problem does it solve? What metric does it move? What strategic position does it support?
Common failure: "because customers asked for it". That is a request, not a reason. Many customer requests, if granted, would degrade the product. The reason needs to connect to a business outcome, not just to a request log.
Concrete test: write the one-sentence value statement. "For [segment], who has [problem], we are building [solution] so they can [outcome], which produces [business result]." If you cannot fill in all five blanks, you do not have a reason yet.
Question 3: What are we building?
Only now do you specify the solution. Most teams reverse the order: they start with the solution and back-justify it with audience and reasoning. The result is a roadmap full of features looking for justification.
Common failure: "a redesign of the dashboard". That is a feature, not a what. The what should describe the user-facing change in plain language. "Users can see their three most important metrics on a single screen without filtering."
Concrete test: if a customer reads the description, can they tell whether they got what they wanted? If yes, the description is at the right level. If not, you are still describing implementation.
Question 4: When and in what sequence?
The when question is the most political. Stakeholders want their items first. The sequencing decision is where roadmap discipline lives. Three inputs:
- Dependencies: if A must ship before B, the order is fixed.
- Risk-adjusted value: a 60% likely $1M outcome beats a 10% likely $5M outcome, despite the larger headline number.
- Optionality: if doing X opens future paths and doing Y closes them, X has hidden value.
Common failure: sequencing by stakeholder political weight. The fix is to make the sequencing inputs visible and force conversations about them rather than about the order itself.
How the 4 questions reshape the roadmap conversation
| Old conversation | New conversation |
|---|---|
| Should we add feature X? | For whom, why, what specifically, and when? |
| Why is feature X delayed? | Did the why change? Did the dependencies shift? |
| Customer wants feature X. Add it. | What segment is this customer? What outcome would it move? Where does it sequence? |
Notice the new conversations take longer. That is the point. The cost of the longer conversation is far less than the cost of the wrong feature shipped on time.
Most bad roadmaps fail Question 1. If you cannot name the specific segment, every later answer is built on sand.
A worked example
Old roadmap entry: "Q3 - Build advanced reporting."
Same entry after the 4 questions:
- Who: Operations managers at companies between 50 and 200 employees who already use our analytics weekly. Identified from 12 interviews in May.
- Why: They currently export to spreadsheets and rebuild the same three reports each week. This costs each manager ~3 hours weekly. Solving it reduces churn risk in this segment (which represents 38% of MRR) and unlocks an upsell path to the Enterprise tier.
- What: A reporting builder where managers can save up to 5 custom dashboards and schedule weekly email exports. Not a full BI replacement; the goal is to eliminate the spreadsheet round-trip.
- When: Q3, after the activation experiment finishes in Q2 (so we know which users to target). Sequenced before the Enterprise tier launch in Q4 because it is a prerequisite feature for that segment.
The original entry could be ignored or argued about. The expanded version is defensible and reviewable.
The 4-question filter for incoming requests
Every feature request that arrives (from sales, support, customers, executives) goes through the same filter before it enters the roadmap consideration set:
- Who specifically?
- Why does it matter to them and to the business?
- What exactly are we changing?
- Why now versus later?
Requests that cannot pass the filter go back to the requester for more information. This single discipline reduces incoming noise by 50-70% in most teams. The remaining requests are higher quality and easier to compare.
The takeaway
Strategic roadmap frameworks are not bureaucracy. They are the externalization of judgment that lets a team make repeatable decisions. The four questions (who, why, what, when) are the minimum viable framework. Run every roadmap item and every incoming request through them. The conversations get longer; the wrong items get filtered out; the roadmap that emerges defends itself.
