THE FOUNDRA TAKE

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.

FOUNDRA EXPLAINS

A decision-led roadmap

01

Outcome

What should change for the customer?

02

Assumption

Why do we think this will help?

03

Smallest test

What is the least costly useful version?

04

Review

What did the evidence actually show?

Foundra analysis: an explanatory decision framework, not measured company results.

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.

Laptop on desk book stacks (Unsplash)
Laptop on desk book stacks (Unsplash) · freddie marriage fredmarriage · CC0 · Context image

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

  1. Y Combinator — source and reference material ↗ Y Combinator · Primary source

Have additional information? Request a correction.