How to define a useful first version

When a team discusses a first version, it often starts by removing features. The advanced dashboard can wait. So can the automations. After several rounds of cuts, the result is small, but it is not always something a person can use from beginning to end.

Reducing scope is necessary. The difficulty is deciding what to preserve. A useful first version is not a collection of parts that are easy to build. It is the narrowest way to resolve a real situation and learn something that changes the next decision.

That applies to a digital product, but also to a service, a content platform or a new way of supporting customers.

Start with a specific situation

“Help small businesses get organized” is too broad to define a version. We need to know who is trying to do what, at which moment, and what they use instead.

Imagine a service for creative studios that need to prepare commercial proposals. An initial situation might be: the studio director finishes a first client conversation and needs to turn their notes into a clear proposal without searching through fragments of previous documents.

This does not define the solution yet, but it establishes a boundary. We are not solving the studio’s entire sales operation. We are working with a recognizable moment that has a beginning and a result.

It also gives us a basis for talking to people who experience that situation. If the problem happens once a year or is already handled well with a template, it is worth discovering that before building a platform.

State the question you want to answer

A first version should reduce an important uncertainty. Do people trust a proposal generated from a structure? Can they complete it with the information they have? Does the studio value saving time more than retaining control over every detail?

The question directs the scope. If we want to know whether the structure helps, it may be enough to offer an assisted process with few variations. Building a flexible editor, permissions and automations first would add work without answering that uncertainty any better.

I would avoid framing the question as “Do they like the idea?” It is easy to approve of a possibility without changing any behaviour. I would look for stronger evidence: someone provides real information, completes the journey, uses the result or accepts a condition proportionate to the value promised.

Preserve a complete journey

The version can be simple, but it should let someone reach a result. In our example, the journey might include choosing a proposal type, answering a few questions, reviewing a draft and exporting it. Each step can be limited. Together they form an experience that can be evaluated.

Building only the form because it is the quickest part does not tell us whether the outcome helps. Designing only the final document does not show whether someone can produce it without assistance. The learning exists in the relationship between the parts.

Use manual work deliberately

Not everything that appears automatic needs to be automated on the first day. The team can review data, prepare an output or send a notification manually while learning which rules repeat.

That work should not be hidden if it changes the promise. If the service takes a day because a person reviews the result, people need to know. Nor should an operation that demands hours for every use continue for months under the label of scalability.

Manual intervention is useful when it temporarily replaces technical complexity and makes the process observable. It is not useful when it creates an experience that cannot be maintained or pretends the product has capabilities it does not.

I would record which part the team performs, how long it takes and which decisions it makes. That record can later become a much more precise set of requirements than a list imagined at the beginning.

Define what stays out

A clear scope needs explicit boundaries: who the version is not for yet, which cases it cannot handle, which integrations it does not include and what happens when an exception appears.

In our example, we might support only service proposals in one language, without simultaneous collaboration or an accounting integration. These boundaries are not hidden defects. They are conditions of the test.

I would prioritize what completes the journey, reduces a serious risk or makes the question measurable. I would leave out what serves infrequent cases, improves secondary convenience or anticipates a scale that does not exist yet.

A “later” list keeps ideas from disappearing, but it should not become a promise. Each item will need to demonstrate its priority again when there is new evidence.

Design how you will observe

Publishing a version does not produce learning automatically. The team has to decide what to observe and how to record it.

I would combine behaviour and conversation. I would look at how many people start and finish, where they need help and which parts they correct. Then I would ask what they expected, what caused doubt and what they did with the result. Numbers reveal patterns; conversations help interpret them.

I would also distinguish errors from signals about the proposition. If a button does not work, it needs fixing. If people complete the journey but do not use the document, the outcome may not be valuable enough. Mixing those problems can lead a team to polish an experience nobody needs.

Decide in advance what may happen

It helps to agree on the possible decisions before looking at the results: continue, adjust, change direction or stop the initiative. If the only acceptable conclusion is to build more, the test is not guiding anything.

The criteria do not require a universal number. They may combine several observations: people complete the journey without help, use the result in a real situation and return to do it again. What matters is that the team knows what evidence it considers sufficient and which uncertainty will remain open.

A negative result can also be valuable if it prevents a larger investment. The situation might exist less often than expected. Or people may prefer an assisted service to a standalone tool. That information can change the format of the solution without invalidating the problem.

The next version is not the backlog

After a test, the temptation is to build everything that was left out. I would return to the evidence. What prevented someone from completing the journey? Which manual work repeated often enough to automate? Which new group now makes sense to serve?

The next version should answer those questions, not reward the feature that creates the most excitement inside the team.

A useful first version produces two outcomes: something focused that a person can use and a stronger basis for deciding. If it only delivers software, half of the work is missing.

To explain that version honestly, return to how to plan communication for a startup. When it needs a page, how to explain a product on its website offers a structure.

If you have a broad idea and need to turn it into a scope that can be tested, we can define the situation, journey and evidence together.