The Smallest Executable Thing
Create Product → Store Product → Display Product: three steps that together are the smallest thing a store can do that is worth watching. Find it, build it, watch it run, then grow it — because every grown step is tested against something that already works.
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.
Among everything the system must eventually do, what is the smallest sequence you could execute today and learn something from — and how do you grow from there without losing the ability to run it?
The skeleton walks. You have a tree with forty leaves and a plan with six slices, and you are about to start the product page slice — when the founder mentions that the admin needs to create products, and images are important, and stock must show. Suddenly the "first slice" has four parts and no clear edge.
Build the product slice completely: creation, images, stock, display. Half a product page is embarrassing; if you are touching the product feature anyway, finish it, so it does not have to be reopened.
"Complete" has no edge either. Images need upload, upload needs storage, storage needs a decision about where; stock needs a decrement rule, the rule needs checkout to exist. The product slice becomes a quarter of the store.
- "Complete" has no edge either. Images need upload, upload needs storage, storage needs a decision about where; stock needs a decrement rule, the rule needs checkout to exist. The product slice becomes a quarter of the store.
- Nothing is executable until all of it is, so the feedback that a running slice would have given — the founder saying "the price needs a currency" on day two — arrives on day twelve.
- Each part is tested only against the others, all new, so a failure in display might be in creation, storage or the image path, and there is no working baseline to bisect against.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Find the smallest sequence of steps that produces something observable and involves a real write and a real read. For products it is three: create a product, store it, display it. Not images, not stock, not editing. That sequence is executable and it teaches something — that the shape of a product survives a round trip.
- Build exactly that and run it. Watch it work. The watching is not ceremony; it is the moment you learn the price arrives as a number and the page wants a string.
- Grow by one step at a time, each step tested against the running thing: add stock to create-store-display; then an image; then editing. Every addition has a working baseline behind it, so a failure is in the addition.
- Choose each next step by what it would teach or unblock, not by what is nearest (What to Build First).
Three verbs, through the stack
Create, store, display — as a slice. It is one step wider than the skeleton (a real write from a real form) and no wider. The doesNotProve line is the growth plan.
- Admin pageA form with name and price; posts to the create endpoint; nothing else.
- API
POST /productsinserting the row;GET /products/{id}returning it. - LogicPrice is parsed as a decimal with a fixed precision — the first decision the slice forced.
- DatabaseProducts table: id, name, price. No stock, no image yet.
- Product pageFetches by id and shows name and price, formatted.
Growing it, one step at a time
The growth order is chosen by what each step teaches or unblocks, and the alternative says when a different order is right. Every step leaves the thing runnable.
- 1Stock: a field on create, a number on display
because Cart and checkout will need it; adding it now makes the next slices possible and costs one column.
- 2Image as a URL field
because Display gets the visual the founder cares about without the upload path; the upload path is a stub, written down.
- 3Edit: the same form, pre-filled
because Surfaces the price-change question — does a past order keep its price? — before orders exist to get it wrong.
- 4Validation: empty name, negative price
because Now that the shape is stable, the bad inputs are enumerable.
- 5Image upload replacing the URL
because Introduces object storage — a new boundary — once everything else is proven.
Asking for the smallest thing
The question that finds the smallest executable thing is not "what is the MVP?" — that is about users. It is narrower, and the ladder shows it sharpening.
why The best form has a stopping rule (the sequence ends at the first observable thing) and a purpose (what it teaches), so the answer is three verbs and a lesson; the middle form invites a list of features and has no edge; the vague form is the reflex.
How to do it
Most important first.
- Write the candidate slice as a sequence of verbs. Strike every verb that could be removed and still leave something observable with a write and a read. What remains is the smallest executable thing.
- Build it with the ugliest adequate inputs: a form with two fields, a page with two lines. Polish is a later step, and it is a step.
- Run it and write down one thing you learned. If you learned nothing, the slice was too small or you were not watching.
- Grow one step; run again; learn again. Keep the runnable thing runnable at every step (Iterative Development).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Products, reduced: create (a form with name and price posting to an endpoint), store (an insert), display (the product page shows the name and price of the product just created). Three verbs, one afternoon. What it taught: the price needs a currency and a precision decision, discovered when the page showed
19.989999. That decision would have been made silently in a complete product slice; here it was made on purpose on day one (What Must Be True?). - Growth, one step at a time: stock (create gains a field, display shows it); then image (a URL field first, upload later — a deliberate stub); then edit (the same form, pre-filled). Each step ran against the previous three and failed only in itself. Editing found that changing a price should not change a past order's price — a requirement that surfaced because the running thing made the question concrete (Snapshots vs References).
- The file-upload service, for contrast: upload a file, store it, download it. Three verbs. Not size limits, not resumable upload, not virus scanning — those are grown steps, each against a working upload.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Something runs before the day is over, and you can say what it taught you.
- Each growth step is small enough that a failure is obviously in the step.
- The stubs — image as URL, no auth — are listed, each with the step that will replace it.
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.
- ?What is the shortest sequence of verbs that ends in something I can see and includes a real write and a real read?
- ?What did running it teach me that I would otherwise have decided silently?
- ?What is the one next step, and what would it teach or unblock?
- ?Is the thing still runnable after this step — and if not, what did I add that broke it?
What can go wrong
- Too small to teach: "insert a row" with no display is a write without a read; it proves the database works, which the skeleton already did.
- Growing several steps at once because each seems trivial, and losing the bisectable baseline.
- Never growing: the smallest thing ships as the product, and "the smallest executable thing" is quoted to defend a product page without stock.
- One step at a time is more runs and more small commits than building a feature whole, and on a feature you have built ten times the extra runs teach nothing.
- The ugliest adequate input is shown to stakeholders, who react to the ugliness; the reaction has to be managed.
- "Smallest means trivial." Smallest means the shortest sequence that still teaches something; create-store-display is small and it surfaced two real decisions.
- "This is the same as the walking skeleton." The skeleton crosses boundaries with fake content; the smallest executable thing does a real, if narrow, piece of the product with real content. The skeleton comes first; this is what grows on it (The Walking Skeleton).
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.
- GENERALA shortest write-and-read sequence exists for any feature in any system; what differs is what "observable" means — a rendered page, a log line, an output file.
- CONTESTEDSome practitioners argue that growing one step at a time optimises for local learning at the cost of global shape: ten small steps on products produce a product model shaped by the order the steps happened to come in, where a single considered design of the product feature would have produced a cleaner one. Their strongest point: incremental growth accumulates the accidents of its own history, and refactoring is not free. The reply here is that the considered design is made from imagination and the incremental one from evidence, and the refactoring cost is the price of the evidence.
- ILLUSTRATIVEThe afternoon, the
19.989999and the growth order are invented for the running example; a real product feature would surface its own decisions.
Where the depth lives
This domain asks the question and hands the answer off by name.