The first version of a product has an awkward job. It must be small enough to build before the money and patience run out, but complete enough for someone to use and judge honestly.
Most version-one plans fail on one side of that balance. Some try to carry the whole vision into the first release. The schedule grows, the team spends months building, and nobody learns whether the central idea is useful. Others cut so hard that they ship a shell: a polished screen with too little behind it to tell anyone what the real product could become.
The answer is not simply “build less.” It is to decide what the first release needs to prove.
Start with the decision after launch
Before discussing features, write down the decision you expect to make once version one is in people’s hands.
For example:
- Will operations teams trust an automated reconciliation step enough to use it every day?
- Will customers finish a purchase when identity verification happens inside the product?
- Can an AI support agent resolve a narrow class of requests without creating more review work than it saves?
- Will suppliers maintain provenance records when the process is added to their existing workflow?
These are useful questions because the answers can change what you do next. A positive answer may justify a larger build. A negative one may point to a different workflow, market, or product. Either way, the first release has done its job.
“Can we build the platform?” is not a useful version-one question. With enough time and money, the answer is usually yes. It says nothing about whether the platform should exist.
Keep the complete path, narrow the breadth
A good first release usually contains one complete journey rather than many partial ones.
Imagine a marketplace for specialist equipment. The long-term plan includes seller verification, listings, search, quotes, payments, delivery tracking, reviews, returns, analytics, and a mobile app. Trying to include a thin version of every area creates a broad product in which no journey works properly.
A better first release might support one kind of seller, one equipment category, and one transaction path from listing to confirmed order. The scope is narrow, but the experience is real. A buyer can complete the job. The team can observe where trust breaks down, which information matters, and whether the commercial model holds.
This distinction matters:
- A narrow product solves one real problem for a defined group.
- An incomplete product exposes pieces of several problems without solving any of them.
The first is useful. The second produces feedback about missing features, which the team already knew were missing.
Four things version one usually needs
Every product is different, but four categories are difficult to postpone.
The central user journey
The person the product is for must be able to reach the promised outcome. If the product helps a finance team reconcile payments, version one needs to reconcile a real payment set — not merely import a file and display it.
Enough operational support to run it
Early products often need manual work behind the scenes. That is fine. What matters is making the manual work visible and manageable. Someone needs a way to review exceptions, correct data, answer users, and see when the system has failed.
An internal page used by two operators may matter more than a customer-facing preference screen used by nobody.
Measurement tied to the first decision
General traffic numbers will not tell you whether the product works. Measure the behavior connected to the question you started with: completed reconciliations, successful verifications, cases resolved without intervention, or suppliers who return to add a second record.
Instrumentation belongs in the first release because lost evidence cannot always be reconstructed later.
A safe way to change the product
Version one will change. Deployment, logs, backups, access control, and a basic rollback path are not “scale work.” They are what allow a small team to learn without turning every release into a risky event.
The architecture does not need to support ten million users on day one. It does need to let the team find a problem, fix it, and release the fix without fear.
What can usually wait
The easiest items to defer are those that improve range or polish without helping answer the first question.
That often includes:
- several roles when one role covers the first users;
- a full reporting suite before the core events are understood;
- extensive preferences and customization;
- native applications when a responsive web product can test the workflow;
- complex automation for a process that can be handled manually at low volume;
- architecture designed around traffic the product does not yet have.
This is not an argument for poor quality. Security, data integrity, accessibility, and recoverability do not become optional because a product is young. The cut should remove breadth, not care.
Watch for disguised assumptions
Feature discussions often hide unresolved business decisions.
“We need team permissions” may mean nobody has decided who owns the account. “We need flexible pricing” may mean the commercial model is still unsettled. “We need an AI assistant” may mean the underlying workflow is not clear enough to describe.
Code cannot settle those questions. Building around them too early makes the uncertainty harder and more expensive to unwind.
When a feature keeps expanding, ask what decision has not been made. Often the fastest route is a short product or operational decision, not another sprint.
Do not make version one disposable
There is a difference between accepting manual work and accepting careless foundations.
Manual review can be a sensible way to learn before automating. Hard-coded credentials, missing audit records, undocumented deployments, and data models nobody understands are not learning tools. They are debt with no information value.
Version one should be modest, but it should still be owned. The team should know how it works, how to run it, and where the deliberate shortcuts are. If the idea proves itself, the next version should extend the product rather than rescue it.
A useful final test
Read the proposed scope and ask three questions:
- What specific decision will this release help us make?
- Can a real user complete the central journey without pretending unfinished parts exist?
- If the answer is positive, can we build on this version without starting again?
If the team cannot answer the first question, the scope has no purpose. If the answer to the second is no, the release is too thin. If the answer to the third is no, speed has been bought by moving cost into the near future.
The right version one is not the smallest product you can release. It is the smallest product that gives you trustworthy evidence and leaves you able to act on it.