A score is not a priority until something loses
Prioritization scores make options comparable, but they do not make the trade-off. Use a decision note that names the winner, the displaced work, and what evidence could change the call.
On this page 5 sections
- Use scores to expose assumptions, not to outsource the decision.
- Name the strongest rejected option and the cost of deferring it.
- Record what new evidence would change the ranking.
A roadmap can be full of ranked work and still avoid prioritization. The numbers look decisive, the top item gets a slot, and nobody says what the team is choosing not to do. That omission matters most when the rejected option has a real customer, a deadline, or a person waiting on it.
A score is useful because it makes assumptions visible. It is not a substitute for the decision those assumptions inform.
A ranking hides the cost of the winner#
Suppose two projects compete for the same engineering capacity. Project A improves a common workflow for many users. Project B resolves a smaller but time-sensitive reliability risk. A scoring model can rank A first if its reach and impact estimates are higher. That result does not mean B is unimportant; it means the model’s inputs give more weight to A under the chosen formula.
The actual decision includes a third option: what happens if neither is chosen now? A ranking table usually compares A and B, not A, B, and the cost of waiting. It can make a delay look like an empty cell instead of a decision with consequences.
For each candidate, write the counterfactual in one sentence: “If we do not take this now, ___ continues until ___.” The blank should describe an observable state, not a vague concern. “Support keeps manually reconciling the same records through the next release” is more useful than “users may be frustrated.”
Separate measurement from judgment#
A score combines evidence and value judgments. Keep them distinguishable.
| Field | What to record |
|---|---|
| Evidence | What was observed, from which users or system |
| Estimate | The uncertain number or range inferred from that evidence |
| Weight | Why this factor matters relative to the others |
| Constraint | Deadline, dependency, risk, or capacity limit |
| Decision | What will be done, and what will wait |
This avoids treating a decimal as if it came directly from reality. If reach is an estimate from a small set of interviews, say so. If impact is weighted highly because a commitment expires, write that down. When the evidence is weak, the score should make uncertainty easier to see, not bury it under precision.
A useful review question is: “If we changed this one assumption, would the order change?” If yes, that assumption deserves a check before the team treats the order as stable. If no, the ranking may be robust enough to act on while learning continues.
A quick sensitivity check is often enough. Nudge the largest uncertain input up and down by a plausible amount, then see whether the winner changes. If it does, the team has found a decision hinge: either collect evidence about that input, or accept that it is choosing under uncertainty. If the winner stays the same, further debate over a decimal is unlikely to improve the decision.
Name the displaced work#
If the score is sensitive to a small change in one estimate, do not average away the disagreement. Ask which evidence would be cheapest to gather this week and whether that delay is cheaper than choosing incorrectly. Sometimes the right move is a small reversible test rather than a full commitment. That is still a prioritization decision: the team is paying for information before paying for the larger build.
A priority becomes legible when the team can name its loser. The rejected item need not be listed as a permanent “no.” It may be deferred, narrowed, or handled with a temporary workaround. But the cost should have an owner and a review point.
Use a short decision record:
- Choose: the item being started and the outcome it should change.
- Defer: the strongest option not being started.
- Cost: what continues or becomes harder because of the delay.
- Evidence: what would change the choice, and how it will be gathered.
- Review point: the date or event that brings the trade-off back.
For example: “Choose the onboarding repair for this cycle. Defer the reporting export. The operations team will keep preparing the export manually for two weeks. Revisit if the manual process exceeds the agreed turnaround or if the onboarding change fails its activation check.” The particulars will vary; the structure prevents a quiet, indefinite deferral.
Do not confuse a commitment with a forecast#
A roadmap date can mean several different things: a target, a promise, a dependency, or a guess. If the team uses the same visual marker for all four, stakeholders will reasonably read uncertainty as commitment.
Pair a priority with its confidence and trigger. “Next in line, subject to the security review” is a different statement from “committed for the next release.” If a new deadline enters the picture, make the constraint explicit and rerun the trade-off. Do not just change the score until the desired project wins.
This is also why a roadmap should preserve the reason behind an order. A list of titles can be rearranged without anyone noticing what changed. A short record of the assumption, displaced item, and trigger makes the revision explainable.
A decision review that takes ten minutes#
Before a planning decision closes, ask:
- What observed evidence supports the top item’s reach and impact?
- Which estimate or weight is doing the most work in the ranking?
- What is the strongest option we are not choosing?
- What concrete cost continues while it waits?
- What evidence or event would reopen the decision?
If the team cannot answer questions three and four, it has a ranked list, not a priority. Keep the score as an input; write down the trade-off as the decision.