What Is Not V1
Deciding what stays out is the same decision as deciding what goes in, made honestly: each excluded feature gets a reason, a trigger for revisiting it, and the assumption it leaves behind in the code.
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.
How do I say "not yet" to a feature in a way that survives the meeting, and what does saying it commit me to?
I have a V1 path and a list of things that are not on it, and every one of them has an owner who thinks it is essential. When I say "not in V1", they hear "never". I need a way to exclude things that does not sound like refusal and that I can actually defend.
Sort the excluded features into "phase 2" and "phase 3" so that everything has a home. It looks like planning, nobody's feature is rejected, and the roadmap slide is full.
Phases are dates without evidence. Nothing about "phase 2" says what would have to be true for coupons to be worth building, so when V1 ships, phase 2 starts by default, whether or not anyone learned anything.
- Phases are dates without evidence. Nothing about "phase 2" says what would have to be true for coupons to be worth building, so when V1 ships, phase 2 starts by default, whether or not anyone learned anything.
- The exclusions leave no trace in the design. "Multi-warehouse is phase 3" is written on a slide, and the V1 code stores stock as a single integer on the product with no comment — so the assumption is discovered later by a bug, not by a reader.
- The list never gets shorter, because nothing on it was ever examined. Some of it is genuinely later; some of it was never needed; some of it turns out to be the actual idea. Phases treat all three the same.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- For each excluded feature, write three things: why it is not on the path that tests the claim, what evidence would bring it back, and what assumption its absence bakes into V1. "Not V1: multi-warehouse. Why: stock location does not change whether a customer buys. Trigger: a second fulfilment location exists. Assumption: stock is one number per product."
- Sort the list by the assumption it leaves behind, not by who asked for it. A feature whose absence bakes in nothing (a wishlist) can be excluded freely; one whose absence bakes in a data shape (single warehouse, single currency) should be excluded with the assumption written next to the code that makes it (The Assumption Register).
- Distinguish three kinds of "not V1": *simplified* (search becomes filter-by-name — the action survives, the mechanism is smaller), *deferred* (coupons — nothing on the path needs them), and *not this product* (recommendations, when the claim is about the shop). Each is a different conversation with its owner.
- Make "not V1" a claim about evidence, not time. "We will build coupons when we have a baseline conversion rate to measure them against" is a statement a stakeholder can hold you to, and one that might be answered by V1 itself.
The exclusion table
The reflex sorts features by phase. The table sorts them by what excluding them does to V1. The last column is the one that matters to the code: it says which assumption is now sitting in the schema and will need to be found later.
| Feature | Kind | Why not on the path | Trigger to revisit | Assumption left in V1 |
|---|---|---|---|---|
| Search | Simplified | Filter-by-name performs "find a product" | Catalog grows or customers fail to find things | Catalog is small enough to filter in one query |
| Coupons | Deferred | No step needs a discount to complete | A conversion baseline exists | Total = sum of lines + shipping, kept in one function |
| Multi-warehouse | Deferred | Stock location does not affect buying | A second fulfilment location | Stock is one integer per product (commented) |
| Multi-currency | Deferred | One market in the claim | A customer in another market | Prices are amounts in one currency; the currency is a constant, not a column |
| Recommendations | Not this product | The claim is the shop, not discovery | The claim changes | None — nothing in V1 depends on their absence |
| Microservices, queue | Not a feature | Nothing on the path is proven by them | A measured bottleneck | Everything runs in one process; boundaries are modules |
Which kind of "not V1" is this?
The three kinds lead to different conversations, and the wrong conversation is what makes exclusions feel like refusals. The decision device names the criteria; the answer for any given feature is the owner's and yours to argue about.
A feature is not on the V1 path. What do I do with it?
when The customer action is on the path and a smaller mechanism performs it — filter instead of search, a fixed fee instead of a shipping calculator.
cost The simpler mechanism may be kept far longer than intended, and its limit should be written down as the trigger.
when No step on the path needs it, and the evidence V1 produces would change how it should be built.
cost An assumption is baked into V1 and must be recorded where the code makes it.
when The feature belongs to a different claim than the one V1 tests.
cost This is the conversation most likely to reveal that the claim was wrong — which is the cheapest possible time to learn it.
The question that makes a stakeholder an ally
The vague form of the exclusion invites a fight about priorities. The best form asks the stakeholder to name the evidence, and the evidence is usually something V1 will produce — which makes them want V1 shipped.
why The best form makes the exclusion a statement about evidence rather than about effort or taste: it names what V1 has to record (order totals, conversion) for coupons to be evaluable later, so the stakeholder is now specifying V1 instead of arguing with it.
How to do it
Most important first.
- Take the full feature list and, next to each item, write the step on the V1 path that needs it. If there is no step, it is not V1, and now you can say why (MVP Thinking).
- For every exclusion, write the assumption it leaves in the data model. Put that sentence as a comment where the assumption lives — on the stock column, the currency field, the shipping fee constant.
- Write the trigger for revisiting, as an observation rather than a date: "when the second warehouse exists", "when we have a month of orders to compare against".
- Show the owner of each excluded feature their three sentences before the meeting. The argument you want is about the reason, not about whether you listened.
- Re-read the list when V1 ships. Some items are now obviously needed, some obviously not, and some were the idea all along (Requirements Emerge During Implementation).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Coupons. Why not V1: no step on browse → cart → pay needs a discount to complete. Trigger: a conversion baseline exists to measure a discount against. Assumption baked in: the order total equals the sum of line prices plus shipping — a formula that will gain a term, so it lives in one function, not in three places.
- Search beyond filter-by-name. Kind: simplified, not deferred. The customer action "find a product" is on the path; a substring match over product names performs it. Trigger: catalog size or customer complaints show that names are not enough. Assumption: the catalog is small enough to filter in one query.
- Multiple warehouses. Why not V1: where stock sits does not change whether the customer buys. Trigger: a second fulfilment location. Assumption:
stockis one integer per product, with a comment saying so, because the change is a schema change and the comment is where the future reader will look (Snapshots vs References). - Personalisation. Kind: not this product, for now — the claim is "people buy from this shop", and there is no order history to personalise from. If the founder objects that personalisation *is* the idea, the V1 path was wrong and this is the moment to find out.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every excluded feature has a reason, a trigger and an assumption, and the owner of the feature has seen all three.
- The V1 code carries comments where the exclusions left assumptions, so a reader finds the single-warehouse decision before a customer does.
- The stakeholder conversation is about triggers — "what would have to be true?" — rather than about dates.
- At least one item has moved from "not V1" to "not this product", or the reverse, after the list was written.
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.
- ?Which step on the V1 path needs this feature — and if none does, what is the reason I will give its owner?
- ?What assumption does leaving this out bake into the data or the code, and where will I write it down?
- ?What observation, rather than what date, would bring this feature back?
- ?Is this feature simplified, deferred, or not this product at all — and which conversation does that mean?
What can go wrong
- The exclusion list becomes a second product spec, with each item designed in detail so it can be "ready". The list exists to record reasons and assumptions, not designs; a deferred feature designed now is designed without the evidence V1 would have given.
- Exclusions with no assumption written down. "Single currency" is invisible in the code until prices are stored as bare numbers in a hundred places, and the trigger — a customer in another country — arrives before the comment does.
- The list is used to say no to everything. Some things arrive on the list because they are on the path and were missed: a way to see an order after paying is not "phase 2", it is the confirmation the claim needs.
- Three sentences per exclusion is real work; on a list of thirty features it is most of a day, spent before anything is built.
- Writing the assumption next to the code invites "why not just do it properly now?" — a fair question, sometimes with the answer yes.
- Triggers stated as evidence are harder to put on a roadmap slide than dates, and some stakeholders need the slide.
- "Not V1 means we design it later." It means you *decide* it later, with evidence. Leaving room for it now — the total in one function, the stock column commented — is not designing it.
- "Everything simplifies." Some features are the claim: a chat app without realtime delivery, a search product with filter-by-name. Those cannot be moved to the list; the lesson before this one is how to tell.
- "Filter-by-name is a placeholder." It is a real feature that performs the real action, and it may be enough forever. Replace it when the trigger fires, not because it feels small.
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.
- GENERALReason, trigger and assumption apply to any excluded requirement in any system, including a library's unsupported cases and a pipeline's unhandled inputs.
- TEAM-SPECIFICA solo builder can keep the three sentences in a file; a team with stakeholders needs them where the stakeholders will read them, and the trigger becomes a shared commitment rather than a note to self.
- ILLUSTRATIVEThe feature list and the store are invented; the number of items and the size of the catalog are for the shape of the argument.
Where the depth lives
This domain asks the question and hands the answer off by name.