SIMPLIFIED
What Should I Build First?
Features with dependencies and four ratings. Dependencies gate; among the unblocked, a weighted score decides. Change the weights and watch which slots move — those are the real decisions. The rest were made by the graph.
Problem→Understand→Requirements→Constraints→Unknowns→Decomposition→Smallest Step→Model→Experiment→Observe→Debug→Learn→Iterate
The order is two rules, in this priority: a feature cannot come before what it depends on, and among the features that could come next, the one with the best weighted score does. Risk counts positively, because the point is to meet the hard part while there is still time to change course. The first thing out is the first vertical slice; the riskiest thing gets a spike before its slot. Try the chat preset and every weight setting: the order never moves, because the graph left nothing to decide.
Presets
The running example (§81). Nine features, one of them — Payments — an external integration you have never done. Under balanced weights, Products comes first because nothing else can be tested without it and Recommendations comes last because it is worth little until there are orders to learn from.
The features
Rate each 1–5. Tick what it depends on.
| Feature | Risk | Value | Learning | Effort | Depends on | |
|---|---|---|---|---|---|---|
Authentication Known territory; needed before real users, not before the first slice. | ||||||
Products The catalogue. Nothing else in the store can be demonstrated without something to buy. | ||||||
Cart State that must survive a page reload — the first place who owns this state comes up. | ||||||
Checkout Turns a cart into an order. The core workflow; the first vertical slice ends here. | ||||||
Payments Provider integration, webhooks, retries, partial failure. The riskiest thing in the project. | ||||||
Orders Order history and status. A snapshot of what was bought at what price (§37). | ||||||
Inventory Stock levels and the concurrency question — two buyers, one item. | ||||||
Recommendations Needs order data to recommend from; low value until then. | ||||||
Admin A back-office for editing the catalogue. Boring, cheap, and a real requirement. |
The weights
The default position: user value leads, risk is pulled forward, learning and effort are tie-breakers. Choose it when nothing about the project is unusual — a small team, a known domain, a deadline that is real but not brutal.
score = 2·risk + 3·userValue + 1·learningValue − 1·effort
The order
One possible sequence. The because-lines say which rule decided each slot.
reading
Dependencies gated every slot; the weights decided 8 of 9. Change the preset and watch which slots move — those are the real decisions. First vertical slice: Products end to end, front to database, before anything else gets a second feature. Risk to prototype early: Payments (risk 5). Its slot stays where its dependencies put it, but spend a time-boxed spike on its riskiest unknown before then.
- 1Productsscore 17first vertical slice
- — no dependencies — buildable from day one
- — highest user value among unblocked features
- — cheapest of the unblocked features
- — score 17 vs 13 for Authentication, the next candidate
- 2Cartscore 16
- — all dependencies placed (Products)
- — highest user value among unblocked features
- — score 16 vs 13 for Authentication, the next candidate
- 3Checkoutscore 21
- — all dependencies placed (Cart)
- — highest user value among unblocked features
- — highest risk among unblocked features (3) — pulled forward so the hard part is met early
- — most to learn from among unblocked features
- — score 21 vs 13 for Authentication, the next candidate
- 4Paymentsscore 25spike first
- — all dependencies placed (Checkout)
- — highest user value among unblocked features
- — highest risk among unblocked features (5) — pulled forward so the hard part is met early
- — most to learn from among unblocked features
- — score 25 vs 16 for Orders, the next candidate
- — risk 5 — prototype the unknown before this slot: a time-boxed spike that answers one question, thrown away afterwards (§78)
- 5Ordersscore 16
- — all dependencies placed (Checkout)
- — highest user value among unblocked features
- — score 16 vs 13 for Authentication, the next candidate
- 6Authenticationscore 13
- — no dependencies — buildable from day one
- — highest user value among unblocked features
- — score 13 vs 12 for Inventory, the next candidate
- 7Inventoryscore 12
- — all dependencies placed (Products)
- — highest user value among unblocked features
- — score 12 vs 11 for Admin, the next candidate
- 8Adminscore 11
- — all dependencies placed (Products)
- — highest user value among unblocked features
- — cheapest of the unblocked features
- — score 11 vs 10 for Recommendations, the next candidate
- 9Recommendationsscore 10
- — all dependencies placed (Orders)
- — the only unblocked feature — the dependency graph decided this slot, not the weights
Dependency layers — everything in a layer could be built in parallel
layer 0
AuthenticationProducts
layer 1
AdminCartInventory
layer 2
Checkout
layer 3
OrdersPayments
layer 4
Recommendations
How to read this page honestly
What the tool does, and what it deliberately refuses to do.
SIMPLIFIED
The scores are ordinal, not estimates: 21 before 16 says "this before that under these weights", never how much sooner or how much better. The ratings are yours, and the model argues with nothing — rate a familiar login as risk 5 and it will dutifully spike it. No spike is recommended when nothing rates risk 4 or 5, because a project of familiar screens does not need a prototype, and cycles are reported rather than resolved because which edge to cut is a design decision the tool has no business making.