Prioritisation improves when a team compares the decisions a project enables, not only the features it ships.
Name the expected change
For every proposed project, write the customer behaviour or business result that should change. A new dashboard might help an operator spot a problem earlier; a new integration might remove a repeated onboarding delay. If the team cannot describe the intended change, the project is not ready to be prioritised merely because several people have requested it.
Expose the assumption
State why the team believes the project will produce that result and what evidence is missing. A hypothetical integration request might come from three prospects, but none may have confirmed that the integration is the reason they have not bought. A short discovery effort can be more valuable than immediately committing engineering time. The roadmap should make this uncertainty visible rather than conceal it behind a delivery date.
A decision-led roadmap
Outcome
What should change for the customer?
Assumption
Why do we think this will help?
Smallest test
What is the least costly useful version?
Review
What did the evidence actually show?
Compare cost and reversibility
Estimate the smallest useful version of the work and the commitments it creates. A reversible interface experiment differs from a new data architecture or a contractual promise. Consider support, maintenance and migration costs as well as development time. A feature that takes a week to build can create years of obligations if customers make it central to their workflow.

Review outcomes after release
At the agreed review point, compare the intended change with observed behaviour. Keep the result short and specific, including when the evidence is inconclusive. This closes the loop between product decisions and learning. A roadmap becomes more credible when the team can explain what previous work taught it. Shipping remains necessary, but the purpose is to make better subsequent choices rather than accumulate a longer list of completed features.
Sources
- Y Combinator — source and reference material ↗ Y Combinator · Primary source
Have additional information? Request a correction.



