The First Version That Teaches You Something
The quarter-size version that answers the same question as the full feature — found by naming the question first, and proposed by you before scope gets cut for you.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
What is the smallest thing we could ship that would answer the same question the whole feature is asking?
The PM opens planning with: "Customers drop off at the shipping step. We want a delivery-slot picker in checkout — calendar, two-hour windows, per-warehouse capacity, paid evening slots. It is the big bet for the quarter."
Take the spec as the unit of work. Estimate it honestly, split it into tickets along the natural layers — capacity model, slot API, calendar component, pricing — and deliver the whole thing at the end of the quarter, well built.
The first real customer sees the picker in week eleven. If the drop-off at shipping was never about choosing a date — if it was the shipping price — the team finds out after a quarter of work, with a capacity system nobody needs.
- The first real customer sees the picker in week eleven. If the drop-off at shipping was never about choosing a date — if it was the shipping price — the team finds out after a quarter of work, with a capacity system nobody needs.
- Every week the plan gets harder to change, because each layer was built for the layers above it. By week six, "maybe we do not need slots" is no longer a product question; it is a sunk-cost argument.
- When the quarter slips — it usually does with four layers and two integrations — scope gets cut by whoever is under the most pressure, in the last three weeks, and what survives is whatever was easiest to finish rather than whatever would have told us something.
- Finance was promised paid evening slots as revenue. The picker ships late without them, and the launch conversation is about the missing piece rather than whether the picker moved drop-off at all.
What is really going on
- Every feature is a bet on a question. The slot picker is betting on "Do customers abandon at shipping because they cannot see or control when the order arrives?" The spec is one answer to that question; it is not the question.
- The first version is defined by the question it answers, not by a fraction of the spec. "Arrives Thursday or Friday" printed on the shipping step, computed from the warehouse and carrier cut-off, answers most of the question in a week. It does not test paid slots; it does test whether seeing the date changes anything.
- A first version has to be real: real customers, real orders, real traffic, measured. A clickable prototype in a user test answers "do people understand it"; it does not answer "do fewer people leave". Both are useful; only one is a first version.
- Quarter-size is a heuristic, not a rule. The point is that the first version costs a fraction of the full feature and still produces the signal that decides whether to build the rest. If no such version exists, that is itself worth saying out loud.
- The first version is also the cheapest way to learn what the full feature should be. Whatever customers do with "Arrives Thursday" — ignore it, complain it is wrong, ask for Saturday — rewrites the spec for the second version with evidence instead of guesses.
Every feature is a bet on a question
The slot-picker spec reads like a list of things to build. Underneath it is a sentence nobody wrote down: customers leave at shipping because they cannot see or control when the order will arrive. That sentence is the bet. The calendar, the windows, the capacity model and the evening pricing are one way to cash it in.
Once the question is on the table, the first version is whatever answers it most cheaply with real customers. Here that is a delivery estimate on the shipping step. It answers the visibility half of the question in a week and tells you, from real behaviour, whether the control half is worth a quarter.
Quarter-size, same question
The tempting way to shrink a feature is to take its first phase: the calendar without capacity, the picker without pricing. That produces something a quarter of the size that answers no question on its own — a calendar with no capacity behind it promises slots the warehouse cannot keep.
The useful way is to shrink the answer, not the spec. Ask what the smallest honest version of the whole idea is: something a real customer meets on a real order, which would make the same number move if the bet is right.
Calendar UI with fixed two-hour windows, no warehouse capacity, no pricing. Six weeks. Slots are not guaranteed, so it launches as "preferred delivery time" and support fields the complaints.
Estimated delivery date on the shipping step, from warehouse cut-off and carrier transit times. One week. Shown to a share of customers behind a flag; drop-off at shipping compared with the rest.
Phase 1 costs most of the risk and cannot tell you whether choosing a slot matters. The estimate costs a week and tells you whether knowing the date matters — which decides whether phase 1 is worth building at all.
Proposing it
The first version is easiest to land when you propose it yourself, early, as a plan to get the big feature right — not late, as a way to fit the date. Proposed in planning, it reads as protecting the quarter. Proposed in week nine, it reads as an excuse.
Bring it with the question, the signal and both outcomes written down. A PM can say yes to a plan with a decision point in three weeks far more easily than to "can we do less?".
The PM has just presented the slot picker as the quarter's big bet. The estimate round is about to start.
"This is huge — capacity alone is six weeks. Could we drop the paid slots and the per-warehouse part and just do a basic calendar?"
"Before we estimate — the bet is that people leave at shipping because they cannot see or control when it arrives, right? We could test the 'see' half in a week by showing an estimated date on the shipping step. If drop-off moves, we build slots with real data on which days people want. If it does not, we look at shipping price before spending the quarter."
Write it down in five lines
A first-version proposal does not need a document. It needs five lines that someone else can read in a minute and that you can hold yourself to when the result comes in (The One-Pager).
1**Question:** Do customers leave at shipping because they cannot see when the order arrives?2**First version:** "Arrives Thu–Fri" on the shipping step, behind a flag, 20% of customers.3**Signal:** drop-off between shipping step and payment step, flag vs no flag, 3 weeks.4**If it moves:** build slot picker next; use estimate logic as its base (foundation, not throwaway).5**If it does not:** test shipping-price display before any slot work.The two "if" lines are the part people skip and the part that matters: they commit the team to a reading of the result before the result exists.
When there is no smaller version
Sometimes the honest answer is that the feature is indivisible: a payment method that either works end to end or cannot be offered, a legal requirement with a fixed shape. Saying so is part of the job too. "I looked for a smaller version and there is not one; here is why" is a useful sentence in planning, and it makes your next proposal for a smaller version more credible.
Even then, the question-first step is not wasted. Writing down what the feature is betting on tells you what to measure after launch, and that is the part indivisible features most often skip (Outcome vs Output).
How to do it
Most important first.
- Write the question the feature is betting on in one sentence, before looking at the spec. If the PM and you write different sentences, stop there — that disagreement is the most valuable output of the week (Problem Before Solution).
- List the parts of the full feature and mark the ones the question actually needs. Anything that only matters if the answer is "yes" belongs to the second version (Cutting Scope by the Question, Not the Difficulty).
- Name the signal before you build: which number, measured how, against what baseline, and how long you will wait (Picking a Metric That Moves When the Product Gets Better, Instrumentation First).
- Propose it as an option with both outcomes spelled out: "If drop-off at shipping falls, we build slots next and we will know which days people want. If it does not, we saved the quarter and look at price." (Options, Not Answers)
- Ship it to real customers behind a flag, so the first version is also reversible (Feature Flags as Product Tools).
- Decide up front whether the first version is throwaway or foundation, and say which. Both are fine; pretending a throwaway is foundation is how prototypes end up in production for four years.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with the question, not the cut: "The slot picker is betting that people leave at shipping because they cannot control when the order arrives. I want to find out if that is true before we build the capacity system."
- Offer the smaller thing as a way to get the big thing right: "Showing an estimated delivery date is about a week. If drop-off moves, we build slots knowing which days and windows people want — that is a better spec than the one we have."
- Say what it will not tell you: "This does not test paid evening slots. If finance needs that answer this quarter, it is a separate, smaller test, and I would rather run it on its own than bundle it."
- Put both outcomes on the table before the result exists, so nobody reinterprets it afterwards: "If it moves, next is slots. If it does not, next is shipping price. Either way we decide in three weeks, not twelve."
- "We already know customers want slots — every competitor has them." Maybe. The first version costs a week and tells us which slots. If we are right, we lose a week; if we are wrong, we save a quarter.
- "Two launches will confuse customers." One of them is a line of text on the shipping step. Customers will experience it as the date appearing, and later as being able to choose it.
- "Finance planned revenue from evening slots." Then the question is whether customers will pay for them, and that deserves its own small test rather than riding on the back of the picker.
What can go wrong
- The first version answers a different question. "Arrives Thursday" tested visibility, and the team reads a flat result as "customers do not care about delivery" when the real hypothesis was control.
- Too small to be fair: a date shown only on desktop, for one warehouse, to a sliver of traffic, for three days. Nothing moves, and the full feature is killed on evidence that could not have shown anything (Reading an Experiment Honestly).
- The first version becomes the last version. It worked well enough, the team moved on, and the thing built to be thrown away is now load-bearing with no owner (Tech Debt Is a Product Decision).
- Proposing it as a counter-offer rather than a plan. "Can we just do less?" sounds like an engineer avoiding work; "here is how we find out in two weeks" sounds like someone protecting the quarter.
- Skipping the one part that makes it usable. A delivery date with no explanation when it turns out wrong generates support tickets that drown out the signal.
- "First version means lower quality." It means less scope at full quality. A buggy first version answers "do people tolerate bugs", which nobody asked.
- "First version means MVP, so we ship the minimum and see." The minimum is measured against a question. Without the question it is just less, and there is nothing in particular to see.
- "If the first version fails, the idea was wrong." It means that version did not move that number. Sometimes the idea is right and the version tested the wrong half of it — which is why you write the question down first.
Knowing whether it worked
- The first version reaches real customers in a small fraction of the time the full feature was estimated at, and the team has a number to discuss by then.
- The second-version spec changes because of what the first version showed — windows narrowed, a day added, a part dropped. If the spec did not change, either you guessed right or you did not look.
- The PM starts asking "what is the first version?" in planning before you do.
- Fewer quarter-long projects end with a scramble to cut scope in the last three weeks, because the cut happened at the start, on purpose.
- At a small store with one warehouse, the first version and the full feature are close together and it may be cheaper to build the whole thing. The habit earns its keep when the full feature has integrations, capacity or money in it.
- At 10x traffic the first version answers faster: a week of shipping-step data at scale is decisive where a small store would need a month. The question-first habit does not change; the time box shrinks.
- At 10x team size, the first version is also a coordination tool: it gives design, finance and support something concrete to react to early, instead of a spec they each read differently.
- Some work is done twice. The estimate logic behind "Arrives Thursday" may be rewritten for slots. That is the price of finding out early, and it is usually smaller than a quarter spent on the wrong thing.
- It delays the full feature if the answer is yes. A team that was right about the slot picker all along spends a few weeks proving it.
- It is harder to sell. "The big bet for the quarter" is a better story in a planning deck than "a date on the shipping step", and you will have to carry that conversation.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- STAGE-SPECIFICPre-product-market-fit nearly everything is a first version and the hard part is picking the question. In a mature store with steady traffic the first version is an experiment inside a working product, and what is at risk is the shipping step, not the company.
- PRODUCT-SPECIFICIn B2C checkout a real first version reaches customers in days. In regulated or contract-bound products — a payments change a bank must certify, a B2B feature named in a contract — a partial version may not be shippable at all, and the first version becomes an internal pilot or a single design partner instead.
- GENERALNaming the question a feature is betting on before scoping it holds everywhere, including in the cases where the first version turns out to be the whole feature.