Use Case Priority Matrix

Priority → Dependencies → Focus

all commercialall marketing

likelihood discounts shared demand eco risk compounds

Use cases

Ranked by priority. P = (L/10) × (w·m + (1−w)·c) × 100 · C is re-centred on 5, so a loss leader subtracts.
Tick Committed to treat one as decided — everything else is then re-costed against what it already pays for.

#	Committed	Use case	L	C	M	Needs	Avail	P	Sprints	P/sprint

ID Name L C M Notes

Building

Engineering work we do. Sprints are work remaining — 0 means it exists already, blank means not yet estimated.
Only leaves carry a number; a parent shows the sum of its leaves.

Deliverable	Sprints	Demand	Depends on

ID Label Under Sprints

Eco-System

Third parties and partnerships. Sprints are elapsed time to have it in place, not engineering effort.
If an integration is really about exposure rather than capability, give it a use case — that is what scores the marketing value.

Deliverable	Sprints	Likely	Demand	Depends on

ID Label Under Sprints Likely

Matrix

■ needed □ implied by a parent or a dependency · click a cell to toggle

Focus

A use case delivers nothing until everything it needs exists, so the question is not what is most wanted but what is cheapest to finish

Use case	P	Marginal	P/sprint	Still missing

Deliverables by ROI — demand per sprint. Things that already exist carry no ROI: they are not work.

Deliverable	Demand	Sprints	ROI	Blocked by

Sensitivity

Priority as the marketing weight moves 0 → 1. Crossovers are the arguments actually worth having.

How this works

Every formula, and what each number you type actually does

Priority

How good is each use case? One score, from three numbers you set and one slider.

Dependencies

What does it need, and what does that imply we build? Demand flows to deliverables.

Focus

What do we work on next? The cheapest thing to finish, not the most wanted part.

1 · Priority

You set three numbers per use case. Everything else is derived.

m = M / 10 → 0.1 .. 1.0 marketing, normalised c = (C − 5) / 5 → −0.8 .. 1.0 commercial, re-centred on breakeven V = w·m + (1 − w)·c blended value, w is the slider P = (L/10) × V × 100 × A → −80 .. 100 priority

Two things about this shape are deliberate, and worth understanding before arguing with a score:

Commercial is re-centred on 5. The scale says 5 is breakeven, so 5 must contribute zero and anything below it must subtract. Otherwise a loss leader still scores positively on the commercial axis, which is nonsense.
Likelihood multiplies — it is not a third weighted term. It is a probability, not a kind of value. A huge deal that will not happen is worth nothing. It also keeps the slider doing exactly one job: trading marketing against commercial.

A is availability — third-party risk, covered in section 4. With nothing at risk it is 1 and has no effect.

What each field does

Field	Range	Effect on the score
L Likelihood	1–10	Multiplies everything. 10 = signed contract. Halve L, halve the score.
C Commercial	1–10	5 = breakeven. Above adds, below subtracts. C 1 is a heavy loss leader.
M Marketing	1–10	Exposure. Strategic value — regulatory positioning, ecosystem lock-in — folds in here.
Needs	—	No effect on P. Drives cost, demand, and the whole Focus tab.

A negative P means likely, loses money, and buys no exposure. The page shows it rather than hiding it.

2 · Dependencies and demand

D(i) = Σ max(P(u), 0) over every use case u that needs i

Demand is the summed priority of whatever wants a thing. Two consequences:

Negative use cases clamp to zero when propagating. A bad idea cannot reduce apparent demand for a component that good use cases also need.
Demand inherits through dependencies. If a use case needs B2.1, and B2.1.3 depends on E2, then E2 inherits that demand even though no use case names it. This is the mechanism that surfaces dependencies nobody wrote down — it is how the IDP question appeared in the first place.

Zero demand is a finding, not a gap. If nothing needs a deliverable, either a use case is missing or the scope is speculative and should be deliberately killed. The Matrix tab calls these out rather than letting them sit quietly in the list.

Sprints

Effort is sprints remaining — two-week sprints, halves allowed. It is the only state a deliverable carries, and it is remaining work, not total size. Half-built goes 2 → 1.

0 — it exists already, ours or off the shelf. Drops out of the build list but still shows as a satisfied dependency.
blank — not estimated yet. Totals including it are a floor, flagged +?.
Only leaves carry a number. A parent is the sum of its leaves, so “needs B2.1” costs the right amount without double-counting.

There is no status field. One number, updated as work lands.

3 · Focus — the number that decides things

A use case delivers nothing until every deliverable it needs exists. So the sharp question is not “which component is most wanted” but “which use case is cheapest to finish”.

remaining(u) = Σ sprints(i) over everything u needs marginal(u) = Σ sprints(i) only what committed work does NOT already cover marginalROI(u) = P(u) / marginal(u) ← rank on this ROI(i) = D(i) / sprints(i) per deliverable; excludes things that exist

Tick Committed on a use case and everything it needs becomes already-paid-for. Every other use case is then re-costed against only what is left over. Marginal ROI, not raw priority, is what belongs at the top of the Focus view.

4 · Eco-system risk

Building work is within your control; its uncertainty is schedule, which sprints already carries. A partnership is not — it might simply never land. So eco-system items carry their own likelihood, and it multiplies exactly as a use case’s own L does.

A(u) = Π L(i)/10 over eco-system items u depends on

Shared risk does not reorder anything — if two use cases lean on the same partners, both are discounted equally. Only differential exposure changes the ranking, which is exactly when it should.

Any-of groups. Mark a parent any when the children are alternatives rather than a checklist. Cost becomes the cheapest option instead of the sum, and risk inverts: a second option reduces risk. Two options at 60% give 84% as any-of, versus 36% as a checklist.

The two toggles

Both are genuinely arguable modelling choices, so they are switches to be settled against the live model rather than decisions buried in code. Neither changes a raw score; both change the ranking.

Toggle	On	Off
Likelihood discounts shared demand	An unlikely use case pulls proportionally less on shared components.	Shared components get full weight — defensible if you would build it either way.
Eco risk compounds	Probabilities multiply. Two 50% dependencies → 25%.	Weakest link only. Two 50% dependencies → 50%.

Worked example, from the numbers currently on the board

…

Two places to be careful

Sequencing granularity is unresolved. Applying ROI = demand ÷ sprints at leaf level ranks B2.1.1 joint-best on the whole board — full demand for a single sprint. Costing B2.1 as one 4-sprint unit buries it in seventh. Both views are shown in Focus. Which granularity should drive the build order is still an open decision.

A use case is all-or-nothing. Partial completion delivers zero value, so “80% done” is worth the same as “not started” for ranking. That is why marginal cost matters more than raw size, and why a 3-sprint tail that finishes something can beat a 1-sprint task that does not.

Where the data lives

Everything is stored server-side and saves automatically as you type. Export writes the whole matrix as JSON in the same shape as the seed file, so it can be committed to git and reviewed as a diff. Every write also snapshots the previous state with its author, so nothing is silently overwritten.