Your First Version Does Not Need to Do Everything—It Needs to Solve One Thing Completely

A first version commonly fails in two opposite ways. It can include so many features that it arrives too late, or it can be reduced until the user never reaches a useful outcome. Both teach the team very little: the first consumes too much investment before feedback, while the second tests disconnected pieces rather than a real experience. The challenge is not to do less as a principle. It is to choose one small promise and fulfill it from end to end.

My argument is that a first version should be narrow in the number of cases it supports but complete for the case it chooses. A specific person must be able to move from need to outcome, while the business observes cost, behavior, and friction. Everything else can wait except the security, accessibility, and operational foundations required for that evidence to be trustworthy.

One complete promise is worth more than many features

A strong first version lets someone move through the essential cycle from start to finish. In a marketplace, that might mean publishing an offer, finding it, requesting it, and arranging delivery, even if matching happens manually. In a B2B tool, it might mean importing a file, detecting a problem, and exporting a recommendation before automated integrations exist. A complete journey for one narrow case is better than many disconnected screens: only the former reveals whether real value is created and where the experience breaks.

Consider a studio that wants to offer online booking. A version full of profiles, promotions, and reports is not useful if every appointment still needs confirmation through messages. A complete journey can be much smaller: show real availability, reserve a slot, take a deposit, and confirm it. Advanced administration can remain manual. The customer receives the promised result, and the business learns whether the channel reduces work, creates bookings, and fits daily operations.

Scope begins with the decision that comes next

Before prioritizing features, write down the decision you expect to make after people use this version. For example: “If enough people in this segment complete the process without help and return within two weeks, we will invest in automating operations.” That sentence forces you to define the user, behavior, time frame, and consequence. It also separates different questions: desirability, usability, technical feasibility, and operational sustainability. One version does not need to answer all of them, but it must declare which one comes first.

First, a specific promise for a recognizable segment. Second, one complete primary journey with a clear beginning and outcome. Third, the minimum operational support needed to keep that promise, even if some work is manual. Fourth, enough instrumentation to know what happened: critical events, errors, and a feedback channel. Fifth, a decision rule agreed before launch: continue, change, or stop. Together, these parts turn delivery into a learning system. Separately, they often produce an attractive mockup, a brittle application, or data with no interpretation.

The list stops being a catalog when every part has a causal role. The promise attracts the user; the journey fulfills it; operational support prevents failure; measurement shows what happened; and the decision rule turns the result into action. A feature that does not support that chain is not rejected forever. It stays outside this investment until evidence shows it has become the next important constraint.

Measure value, not movement

Visits, registrations, and time on screen can describe activity without proving value. Choose a signal close to the hypothesis: task completion, time to first outcome, repeat use, acceptance of a recommendation, or operating cost per case. Google Research’s HEART framework maps product goals to user-centered signals and metrics. For a first version, one or two well-defined metrics, supported by interviews or usability sessions, usually teach more than a dashboard crowded with indicators.

Define who will produce the signal and how long you will observe them. A convenient group—friends, colleagues, or unusually motivated customers—may tolerate problems the target audience would reject. Recruit people who genuinely face the problem and record their context: what alternative they use today, how often the need occurs, and the cost of leaving it unresolved. An early sample does not need to support a statistical market projection; it should reveal patterns, contradictions, and better questions. Pair behavioral data with a short follow-up conversation. What people did shows friction or interest; what they explain helps shape the next test without turning one opinion into market certainty. Set a window long enough for the expected behavior to occur, and do not extend it merely to reach the outcome you hoped for.

Minimum quality is part of the experiment

Advanced filters, personalization, secondary integrations, and expensive automation can wait. Anything that invalidates learning or harms people should not: basic security, privacy, error recovery, operational traceability, and accessibility across the tested journey. W3C recommends involving people with disabilities early to understand real barriers and design more effective solutions. An exclusionary test produces a biased signal; an unsafe test creates a risk that no learning can justify.

The NIST Secure Software Development Framework recommends integrating security practices into any development lifecycle rather than treating them as a later phase. For a first version, that does not mean building unnecessary enterprise controls. It means protecting data, access, and components according to actual risk, recording failures, and being able to respond. If a test compromises trust or privacy, the learning comes at too high a price.

Cutting scope requires a rule, not intuition

For every feature, ask three questions: Is it required to complete the journey? Does it reduce a critical risk? Does it produce or protect the signal we need? If the answer is no, leave it out for now. Keep an explicit “not in this version” list with reasons, not a limitless backlog. When a new request arrives, require it to replace comparable scope or show why it changes the hypothesis. This makes opportunity cost visible and stops quiet expansion.

How I build a first version with a client

I begin by agreeing who needs which outcome and what decision we will make after observing it. I design a complete journey for the priority case, mark operations that can remain manual, and separate essential work from desirable improvements. Then I define metrics, events, risks, and an investment limit. During development, I demonstrate usable slices and adjust scope with evidence rather than excitement about new features. The client can test a real proposition without committing the entire budget or receiving a disposable technical foundation.

The first version ends when it enables a decision

Before launch, decide when results will be reviewed, who will decide, and what evidence enables each path. If the behavior appears but operations do not scale, automate the bottleneck. If people understand the promise but do not return, revisit frequency or recurring value. If they cannot complete the journey, investigate the experience before adding features. The success of a first version is not looking finished. It is reducing one important uncertainty at the lowest responsible cost and leaving the team better prepared to choose what to build next.