The First Version Should Answer a Business Question

A first version is often scoped by shrinking everything. The full product has several audiences, so the MVP gives each audience a limited area. The roadmap contains many features, so the MVP includes a basic version of each one. The final platform needs automation, so the MVP contains a partly automated workflow that nobody fully trusts.

The result is broad but incomplete. It takes significant effort to build and still does not answer the most important question about the product. A stronger first version begins with uncertainty.

An MVP is not a compressed final product

The first release should not attempt to prove that the team can build a smaller version of every future feature. It should help the business make a decision.

That decision may be whether a particular user will complete a new workflow, whether a service can be delivered reliably, whether teams will replace an existing process, or whether a proposed interaction removes enough friction to be useful. This changes how scope is discussed.

Instead of asking “Which features can we fit?” ask:

• What do we currently believe?
• Which belief creates the greatest product risk?
• What would we need to observe to become more confident?
• What is the smallest dependable experience that can produce that evidence?
• What will we decide after seeing the result?

The first version now has a purpose beyond launch.

Name the uncertainty

Teams often write goals that sound specific but cannot guide scope: validate the idea, test the market, improve efficiency, or launch quickly. Turn the goal into a clear uncertainty.

• Will the intended user complete this task without personal guidance?
• Can the operation fulfil the request using the information collected?
• Will a team move one important workflow out of its spreadsheet?
• Can users understand the offer well enough to choose the right path?
• Can the business support the promised experience without hidden manual work?

These questions are useful because they connect product behavior to a decision. They also reveal different MVPs. A product testing user comprehension may need realistic content and onboarding more than advanced account settings. A product testing an operational workflow may need permissions and status history before it needs a polished analytics page.

Define the evidence needed for a decision

A launch is an event. Evidence is what makes the event useful. Before development, describe what the team needs to learn and how it will recognize the relevant behavior. This does not require inventing impressive targets. It requires deciding what will be observed.

Evidence might include:

• Whether users complete the central journey
• Where they stop or request help
• Which information they misunderstand
• Whether the operation can process requests consistently
• Which exceptions appear repeatedly
• What work still happens outside the product
• Whether users return to complete the same task again
• Which assumptions require a direct conversation rather than analytics

Combine product data with observation and feedback. Numbers can show where something happened. A conversation or support request can explain why. Also define the next decision. If the journey works, what will be expanded? If it does not, what assumption will be reconsidered? If the evidence is unclear, what smaller question should be tested next? Without that decision, teams collect activity rather than learn.

Choose one complete journey

A narrow, complete journey is more valuable than several partial ones. A complete journey has a recognizable beginning, a useful outcome, and the states required between them. The user should not reach a polished dead end where a team member has to explain that the next part is not built.

For a service product, the slice might begin when someone selects a service and end when the request is accepted and clearly confirmed. For an internal tool, it might begin with creating a record and end when the responsible role completes its first meaningful state change. For a SaaS product, it might begin with account creation and end with the first useful output.

Include what makes that journey dependable:

• A clear entry and exit
• Necessary authentication and appropriate permissions
• Validation
• Loading and error feedback
• Empty states
• Confirmation
• A way to recover or ask for help
• Enough operational support to fulfil the promise

This is not extra polish. It is what makes the test credible.

Cut scope by learning value

Once the journey is defined, every requested feature can be evaluated against the business question. Keep a feature when it is necessary to complete the journey, protect the user or business, or interpret the result.

Defer it when it mainly improves a later workflow, serves a secondary audience, automates something that can be handled safely during a small initial release, or adds flexibility before the core behavior is understood.

The word “safely” matters. Manual work can be a useful temporary learning tool, but it must have an owner and a manageable boundary. Hidden manual processes create unreliable experiences and misleading product feedback.

It helps to maintain three scope groups:

• Required for the first complete journey
• Valuable after the journey is proven
• Unclear until evidence is collected

This is more honest than calling every idea “phase one” while expecting all of it to launch.

Build enough foundation, not every foundation

A focused MVP does not mean disposable engineering. The first version still handles real users, business information, and operational responsibility. It needs appropriate security, validation, accessibility, error handling, backups where relevant, and a deployment process the team understands.

At the same time, the architecture does not need to predict every future variation. Design around what is known:

• Separate important responsibilities
• Keep core business rules explicit
• Create stable boundaries around external services
• Avoid duplicating shared meaning
• Make important states observable
• Document decisions that future work will depend on
• Choose technology the delivery team can operate confidently

Delay abstractions that only support hypothetical products, roles, or scale. They consume time now and may encode assumptions that evidence later disproves. Maintainability is the ability to change the product clearly, not the ability to anticipate every change.

Plan the feedback loop before launch

Feedback should not begin after deployment. Decide who will review it, where it will be recorded, and how it will become a product decision. Identify the moments where the team may need direct observation or a conversation.

The feedback loop can include:

1. Product behavior from the central journey
2. Operational notes from the people fulfilling it
3. Support questions and recurring confusion
4. Short conversations with relevant users
5. Technical errors and performance signals
6. A regular review of what was learned
7. One prioritized change or next question

Not every request should become a feature. Look for the problem beneath the request. A user asking for more filters may actually struggle with unclear defaults. A team requesting an export may be completing a missing approval process elsewhere. A request for notifications may reveal that ownership is unclear.

Good iteration solves the underlying problem without rebuilding the whole roadmap around the loudest comment.

A readiness checklist

Before calling a first version ready, I want to know:

• What business question should this release answer?
• Which assumption creates the most risk?
• Who is the specific user in the first journey?
• What useful outcome can they reach?
• Can they complete it without a hidden dead end?
• Can the operation fulfil what the product promises?
• Which evidence will the team observe?
• What decision will that evidence inform?
• Which manual work is intentional and owned?
• Which security, accessibility, and reliability requirements cannot be deferred?
• Who reviews feedback and chooses the next iteration?

The best first version is not the one with the fewest features. It is the one with the clearest reason for existing. Build enough to answer the question well. Then let the answer shape what comes next.