Value First
When the dependencies permit, build the thing a user could actually use. A store that shows products and takes orders without payment is usable in a way that a perfect cart on top of nothing is not. Contested — against building the riskiest thing first — and this lesson says how.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Several pieces are buildable now and none depends on the others. Which one do you build, and how do you choose between the one a user could use today and the one that would tell you whether the project is feasible?
The skeleton runs. You could build the cart, the admin panel, product search, or the payment integration. The founder wants to show something to a prospective partner on Friday. You want to know whether the payment provider will work at all. Both feel urgent and they point at different pieces.
Build the piece that looks best on Friday. A search box and a polished product page will demo well; payment is invisible in a demo and can be faked. Value, after all, is what the user sees.
The demo shows a store that cannot sell anything, and the partner asks "can I order one?". The polished pieces were visible; the valuable piece — the one that makes it a store — was skipped because it was less visible.
- The demo shows a store that cannot sell anything, and the partner asks "can I order one?". The polished pieces were visible; the valuable piece — the one that makes it a store — was skipped because it was less visible.
- "Value" was measured by what the founder would notice on Friday, not by what a customer could do. Search is valuable once there are enough products to search; on Friday there are nine.
- The payment question is still open, and it is the question that decides whether the project is feasible in its current shape. Every visible piece built before it is built on an unverified assumption about the shape of checkout.
- Nothing about the decision was written down, so on Monday the same argument happens again with the next set of buildable pieces.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Define value as what a user can do after the piece exists that they could not before. Not what a demo shows; not what a stakeholder notices; what an actor in the workflow can complete. A store where a customer can place an order — even unpaid — has more of that than a store with search and no checkout (What Am I Actually Trying to Achieve?).
- Among the pieces the dependencies allow, prefer the one that adds the most of that value, and say why in one sentence. If the sentence is about visibility rather than capability, the choice is a demo choice, which may be legitimate — say so.
- Hold value-first against risk-first honestly. Risk-first says: build the thing most likely to fail, because if it fails, everything else was wasted. Value-first says: build the thing users can use, because usage is the evidence the project needs. They agree more often than not — the riskiest piece is often the most valuable — and when they disagree, the tie-break is what you would lose: an unverified feasibility risk loses the whole project; an unbuilt feature loses a week (Risk-First Development).
- When the two disagree and the risk is large, spike the risk and build the value. A spike is small; it answers the feasibility question without building the integration, and the valuable piece proceeds alongside. The choice is rarely binary (Spikes).
The choice, with both weights visible
The decision below is the Friday choice with the criteria written out. Read the cost column: each option costs something specific, and "polish for the demo" is a legitimate option with an honest cost, not a forbidden one. What the reflex does is choose it without knowing the cost.
The skeleton runs and cart, admin, search and payment are all buildable. What goes into this loop?
when The capability gained — a customer can place an order — is the largest available, and it answers the demo question "can I order one?".
cost Payment is not integrated; the demo order is unpaid and must be explained as such.
when The provider's shape is the dominating risk and a spike cannot answer it — for instance the provider only reveals its flow through a full integration.
cost Nothing a customer can use on Friday; a week of work on an integration that may need to be redone once checkout exists.
when The risk is real but answerable by a test-mode charge and a confirmation handler with no store around them.
cost Two things in one loop; the spike must stay small or it eats the cart.
when The demo is what funds the next month and the partner specifically cares about search.
cost Recorded as a demo choice; the capability gained is small and the risk stays unverified for another week.
The same pieces under different weights
The matrix scores the four options on the axes the decision actually moves. The numbers are ordinal — a three is better than a two on that axis and nothing more — and the caveat says what they cannot express. The point of the matrix is the disagreement it makes visible, not a winner.
| Option | Time | Reliability | Simplicity | Maintainability | Note |
|---|---|---|---|---|---|
| Cart + checkout, no payment | Largest capability gain; leaves the payment risk open unless spiked. | ||||
| Payment integration | Retires the risk; may be rebuilt once checkout exists. | ||||
| Cart + payment spike | Both weights served; depends on the spike staying a spike. | ||||
| Search + polish | Demo value; little capability; risk untouched. |
caveat Time here means "usable capability soonest", and reliability means "how much of the project's feasibility is verified afterwards" — neither is a measurement. The matrix cannot express the founder's deadline or the partner's interest, and on some Fridays those decide.
One order for the loop, and the other
The order below is the lesson's answer for the store as described. The alternative is the risk-first answer, and it is right under the condition named. Both are defensible; the difference is a judgment about what would be lost, and the device carries both so the reader can see the judgment rather than inherit it.
- 1Cart: add, remove, quantity, survive a refresh
because Checkout needs it, and a customer can assemble an order — the first real capability past the skeleton.
- 2Payment spike, in parallel: test-mode charge, confirmation handler, log line
because It answers "who says it is paid?" and whether the provider dictates a flow, without an order existing.
- 3Checkout without payment: validate, total, create the order
because A customer can place an order; the Friday question is answerable.
- 4Payment integration, shaped by the spike's answer
because There is an order to pay for, and the integration is built once, in the shape the provider needs.
How to do it
Most important first.
- List the buildable pieces and, for each, write what a user can newly do once it exists. Strike the ones where the answer is "the same things, more nicely".
- For each, also write what would be lost if it turns out to be infeasible. Where the answer is "the project", that piece needs a spike before or alongside whatever you build.
- Choose the piece with the most new capability, and schedule the spike for the largest feasibility risk in the same loop.
- When a stakeholder's deadline drives the choice, write it as such — "Friday demo: search, because the partner cares about search" — so it is a recorded decision and not a drift (The Decision Journal).
- Revisit after each loop. Value shifts: once orders exist, the most valuable next piece is usually the one that makes them real — payment — not the one that makes them prettier.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Friday, decided. Buildable: cart, admin, search, payment. New capability: cart — a customer can assemble an order; admin — the founder can add products without a script; search — nine products can be found faster than by scrolling; payment — a customer can pay. Feasibility loss: payment could force a hosted flow that reshapes checkout. Decision: build the cart and checkout-without-payment for Friday, because "a customer can place an order" is the demo that answers "can I order one?"; run the payment spike this week alongside. Search waits for a catalog worth searching.
- The disagreement, made explicit. Risk-first said payment integration first; value-first said cart and order first. The resolution was not to pick one: the spike carried the risk (a test-mode charge and a confirmation handler, no store around it) and the cart carried the value. Both were done by Friday; the integration was not, and did not need to be.
- The analytics dashboard. Buildable: the ingestion pipeline, the first chart, user accounts, export to spreadsheet. New capability: the first chart lets an analyst see one metric; ingestion lets data exist; accounts let people log in to nothing; export moves a chart nobody can see yet. Ingestion first by dependency, then the first chart by value; accounts and export wait until there is something to protect and something to export.
- The case where risk wins outright. The file-upload service, where the feasibility question is whether the object store the company mandates supports resumable uploads at all. If it does not, the design changes completely. Nothing has enough value to justify building it on an assumption of that size; the spike is the whole first loop.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every piece under consideration has a one-sentence capability statement, and the chosen one has the strongest.
- The largest feasibility risk has a spike in progress, regardless of which piece is being built.
- Stakeholder-driven choices are written down as such rather than absorbed into "value".
- After each loop, the definition of the most valuable next piece has moved, because the system now does more.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?For each piece I could build now, what can a user do afterwards that they cannot today?
- ?Which piece, if it turned out to be infeasible, would cost the whole project — and does it have a spike?
- ?Is my choice driven by capability, by visibility, or by a deadline, and have I written down which?
- ?Now that this piece exists, has the most valuable next piece changed?
What can go wrong
- Value measured as visibility. Every loop polishes what the founder looks at; the store demos beautifully and cannot be operated. Value is capability in the workflow, not presence in the demo.
- Value-first used to avoid the frightening piece. "Users can use the cart today" is true and is also a reason to postpone payment indefinitely. The spike exists to keep risk from being deferred behind value.
- Risk-first over-corrected into a month of spikes. Every question is answered before any user could do anything; feasibility is established for a product nobody has touched. Spikes are small by definition; when one grows into a build, it has stopped being a spike.
- The tie-break applied to small risks. "What would we lose?" for a search library that might be slow is a day; treating it as a project-level risk and spiking it first is analysis dressed as prudence.
- Building the valuable piece while spiking the risk means two things in one loop, and on a solo project that is a real split of attention.
- Choosing capability over visibility can cost the Friday demo, or the partner's enthusiasm, and sometimes the enthusiasm is what funds the next month.
- Writing the deadline-driven choice down as a deadline-driven choice makes it visible to whoever reviews the notebook, which is uncomfortable and is the point.
- "Value-first means features before infrastructure." Infrastructure that enables a capability — persistence, so that orders survive — is value. Infrastructure that enables nothing yet — a queue with no consumer — is not, and the test is the capability sentence, not the category.
- "Value-first and risk-first are opposites and I have to choose a school." They are two weights on the same decision, and the lab at /thinking/first shows the order changing as the weights do. Most loops satisfy both; the lesson is about the ones that do not.
- "The founder decides value." The founder decides the goal; value is capability toward that goal, and a search box on nine products does not move a goal about orders.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- CONTESTEDRisk-first practitioners hold, with good reason, that value-first is how projects die slowly: that the valuable pieces are the familiar ones, that familiarity is why they feel valuable, and that a team which builds what users can use today will discover in month three that the piece it deferred — the integration, the concurrency, the scale — invalidates the design it built. Their strongest form: any feasibility question that could change the architecture must be answered before the architecture exists, and a spike is not enough when the answer might be "the whole shape is wrong". That view is strongest on projects with one dominating technical risk, and weakest on products whose main risk is that nobody wants them.
- STAGE-SPECIFICOn a greenfield product whose main risk is demand, value-first is nearly always right, because usage is the evidence that matters. On a system being extended, feasibility risks are usually known and value-first is the default; on a research prototype the feasibility question is the product and risk-first governs.
- ILLUSTRATIVEFriday, the partner, the nine products, the dashboard and the resumable-upload question are invented for the shape of the argument; no real project or provider is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The lab at /thinking/first lets you move the weights between risk and value and watch the recommended order change; the honest half of that lab is that the orders differ.