Introduction
Version one exists to learn. Not to impress. Not to scale. Not to satisfy every stakeholder.
Most startups build version three before launching version one. That delays learning and increases risk. A smaller version usually creates better feedback, not because the team is lazy, but because the feedback is the point.
This framework helps you decide what stays in v1, what becomes v2 and what disappears from the roadmap entirely.
What it solves
What a sharp v1 delivers
-
A clear learning signal
A narrow v1 produces a clear signal: customers either find the value or they do not. A broad v1 produces a muddled signal where multiple features dilute every observation.
-
A shippable date
Smaller scope ships sooner. Sooner shipping means earlier feedback, faster iteration and lower cost of being wrong. Most v1 timelines compress dramatically once the scope is honest.
-
Lower change cost
Removing two features after launch is normal. Removing fifteen is a rewrite. The smaller v1 keeps the cost of changing direction inside the budget you have.
-
Faster team learning
Teams learn product, customers and operations by running a live product. The longer v1 takes to ship, the longer the team waits to learn, and pre-launch knowledge is almost always wrong in specific ways the team cannot yet name.
-
A defensible story
A v1 that does one thing well is easier to position, demo and recommend than a v1 that does ten things badly. The story you can tell about v1 sets the expectations everyone holds about v2.
What it does not solve
What a small v1 will not fix
-
An unclear hypothesis
A small v1 still requires knowing what you are testing. Without a hypothesis, smaller scope produces smaller noise, not stronger signal.
-
Missing distribution
Whatever ships in v1 still needs to reach customers. A perfect minimal v1 with nobody to show it to is a closed-circuit experiment.
-
Founder indecision
V1 scope tends to balloon when the founder cannot decide what is core. Smaller scope without the underlying decision just delays the decision into the launch week.
-
Operational immaturity
A small v1 still needs monitoring, support and a way to fix incidents. Small does not mean careless, it means deliberate.
-
Stakeholder politics
Every stakeholder has a feature they consider essential. A small v1 forces those conversations earlier, not later. Without political clarity, the v1 negotiation never ends.
Decision tree
Six questions for sizing v1
Run every candidate feature through these questions. The 'no's are what keep v1 shippable and the learning signal strong.
- Question 01
What is the core customer problem?
No → Name it before scoping. A v1 without a named problem is a v1 that will never end.Yes → Confirm with a customer who described the problem in their own words. If you cannot find one, the problem is not yet specific enough. - Question 02
What is the minimum workflow?
No → Map the workflow end to end. Every step that is not strictly required is a candidate for removal.Yes → Confirm the workflow has a clean start, a clean end and produces a single outcome. Multiple outcomes mean multiple workflows, and multiple workflows mean multiple v1s. - Question 03
What can be removed?
No → Try harder. Every v1 contains more than it needs; removing is the work.Yes → Move it to a 'not in v1' list, with a date for revisiting. Lists with dates beat lists without. - Question 04
What can be manual?
No → Automate the smallest thing you must. Everything else can be a human in the loop for the first weeks.Yes → Keep it manual. Manual operations teach you what to automate; automation hides what you need to learn. - Question 05
What can wait until version two?
No → Define v2 explicitly. A v2 list shrinks v1 because everything aspirational can move there.Yes → Confirm by reading the v1 scope back and checking each feature against the v2 list. Anything that fits in v2 belongs there. - Question 06
What must exist to prove value?
No → Define proof concretely. 'Customers like it' is not proof; a customer signing, paying, returning or recommending is.Yes → Confirm the proof is observable in the first 30 days after launch. Proof that takes a quarter is too slow to inform v1.
Common mistakes
Five common mistakes founders make
- 01
Building future features
Founders add features for the customer they hope to have in eighteen months. Those features rarely matter to the customer in front of them, and they delay the launch that would teach you whether the future customer is real. Build for today; the future customer is not yet voting.
- 02
Building scalability too early
A v1 designed for 100,000 users on day one is a v1 that will not ship for the first 100. Scalability is the right problem at the wrong stage; build for the customers you have, scale when you have to.
- 03
Building admin tools too early
Admin panels, role systems, audit logs and elaborate dashboards are real work. At v1, most of that work can be done in a database client or a spreadsheet, and the operational learning is more valuable than the polish.
- 04
Over-automating
Automation before you understand the workflow encodes the wrong rules. Manual processes are slow, informative and easy to change. Automate after the rules are clear, not before.
- 05
Trying to impress investors
An impressive v1 is rarely a learnable v1. Investors who matter prefer evidence of customer learning to evidence of engineering effort. Build for customer signal; the investor story follows.
Alternatives
Practical patterns for v1
Four patterns that ship a v1 that learns fast without sacrificing quality.
-
Single-workflow v1
Pick one customer workflow, build it well, ignore everything else. Even very small v1s produce strong signal when the workflow is sharp. The right default for almost every early-stage product.
-
Concierge v1
Deliver the value as a service before automating it. Slow, small, but it teaches you the operational reality of the product, and what customers actually need automated.
-
Spreadsheet v1
Run the early product in a shared spreadsheet for the first ten customers. Many companies have validated their core value this way without writing a line of production code.
-
Wizard-of-Oz v1
Real-looking interface, humans running the back end. Customers experience the product; the team experiences the operational cost, and learns what to automate first.
Ronald's rule of thumb
Version one should prove value, not prove ambition.
Ambition belongs in v3, v5 and the deck. V1 has a different job: produce the smallest possible product that lets customers feel value and the team see whether that value is real. Confuse the two and v1 becomes a v3 that takes three times as long and teaches a third as much.
, Ronald · YourStartup.Expert
Summary
Summary
V1 is a learning artefact. The six questions above turn 'what should we build first?' into a decision the team can defend: the core problem, the minimum workflow, the cuts, the manual parts, the v2 list and the proof point. Anything that does not contribute to that learning signal belongs elsewhere, usually on a list, sometimes in the bin.
Most v1 timelines collapse once the scope is honest. The team that ships a sharp v1 in eight weeks learns more in the next quarter than the team that ships a sprawling v1 in twenty. Smaller is not a compromise; it is the design choice that makes everything after v1 cheaper.
Common questions
Version one, answered.
The questions founders ask before they freeze the v1 scope.
- What belongs in version one?
- Whatever is required to deliver the core customer value through a single workflow, plus the absolute minimum infrastructure to run that workflow live, basic monitoring, a way to fix issues, a way to collect feedback. Everything else belongs on a v2 list, in a parking lot for future revisits, or in the bin. The test: if a feature could be removed without destroying the core value, it does not belong in v1.
- How small should version one be?
- Small enough to ship in eight to twelve weeks, small enough to change end-to-end in a single sprint after launch, and small enough that the team can describe it in one sentence without using the word 'and'. If your v1 takes longer than three months or has more than one core workflow, it is a v3 dressed up as a v1, and the team will pay the price in delayed learning and increased rework.
- Should version one scale?
- No. V1 should be reliable, not scalable. Reliability means the workflow works for the first 50 customers; scalability means it works for the first 50,000. The 50,000-customer problem can be solved with rebuilds, refactors and infrastructure changes once the product earns the right; the 50-customer problem cannot be solved with anything except a working v1.
- Can version one contain manual work?
- Absolutely. Manual operations are one of the fastest ways to learn what a product really needs. The concierge pattern, Wizard-of-Oz interfaces and spreadsheet-driven workflows all let a v1 ship before the automation arrives, and the manual experience teaches the team what to automate first. Manual is not a shortcut; it is a learning instrument.
- When should version two start?
- When v1 has produced clear customer signal, retention, repeat usage, willingness to pay, or specific feature requests grounded in real workflows. V2 should be designed against that signal, not against the v1 backlog of cut features. Many features on the original 'v2 list' turn out not to matter once real customers are using the product. Let evidence shape v2; do not pre-decide it.