Essay / Product & Entrepreneurship
The First Version of a Product Should Answer a Question
Scope a first product around the assumption you need to test. Choose evidence, participants and decision rules before turning a hypothesis into a backlog.
A first release can contain registration, a dashboard, billing and a settings page while answering almost nothing about whether the product should exist. Those features make the software resemble a business. They do not necessarily test the assumption on which the business depends.
The more useful starting point is a question whose answer changes the next investment decision. Will a particular group trust this workflow with real work? Does the proposed result solve a costly problem? Can the team reach the people who experience that problem? Each question suggests a different first version.
The smallest useful product is the smallest one that can change what you believe.
Name the belief carrying the project
Every early product contains assumptions about the problem, audience, solution, distribution and operating model. A team can be wrong about several of them at once. The first task is to identify which uncertainty makes the rest of the plan fragile.
Suppose a proposed tool helps small teams reconcile supplier catalogues. The team might assume that reconciliation is frequent, that current workarounds are costly, that operators can share representative files and that a generated report would be trusted. Building a polished dashboard does not directly test all four.
Write the assumptions separately. Then ask which one, if false, would make the planned implementation difficult to justify. This is a practical prioritization exercise rather than a precise calculation. The answer may change after a few conversations or an examination of the existing workflow.
The GOV.UK discovery guidance emphasizes understanding the problem and its constraints before committing to a solution. That principle is useful beyond public services: discovery should produce a better decision about what to build, including the possibility of not building the proposed thing.
Choose evidence that could disagree
A question becomes useful when the team can describe evidence that would change its mind. “Do people like the idea?” is weak because polite interest can coexist with no willingness to alter an existing workflow. “Will an operator use a sample reconciliation report to resolve an actual discrepancy?” is more connected to behavior.
The evidence need not be quantitative at the beginning. Observing how someone handles a recent exception can reveal a missing constraint. A small, clearly bounded pilot can show whether the proposed output fits the job. Neither establishes market-wide demand, but both can challenge a specific assumption.
Define the limits of the evidence. A participant recruited through a personal network may be unusually patient. A manually prepared result may be better than an automated one. A test using synthetic data may omit the messiness that makes the real task difficult.
Recording those limits prevents a successful small experiment from becoming an inflated claim. The purpose is to reduce uncertainty enough to choose the next step, not to declare the product validated in every respect.
Scope around the question
If the question is whether a report supports a useful decision, the first version might be a manually assisted report with a clear delivery process. Authentication, billing and self-service onboarding may be unnecessary for that particular test. They become relevant when the question changes to repeated independent use or sustainable delivery.
This does not mean quality can be ignored. The test must still protect data, represent the offer honestly and deliver the promised experience. A broken prototype can produce negative evidence about implementation quality while leaving the product hypothesis unresolved.
The distinction is between necessary fidelity and familiar completeness. Necessary fidelity includes the parts that make the experiment credible. Familiar completeness includes features people expect software products to have even when those features do not help answer the current question.
A useful scope review asks of every proposed feature: what uncertainty does this help resolve, or what essential condition does it protect? If neither answer is clear, the feature may belong after the first learning cycle.
Keep the existing alternative in view
A new product competes with the current way of getting the job done, including spreadsheets, email and tolerating the problem. The relevant comparison is not always another software product with a pricing page.
For catalogue reconciliation, the current workflow may be slow but flexible. An experienced operator may handle exceptions using contextual knowledge that a new tool does not possess. A faster automated result can still be less useful if it makes those exceptions difficult to investigate.
Observe what users would lose by switching. They may lose a familiar audit trail, the ability to annotate an unusual case or control over when a change becomes public. These costs can explain hesitation more accurately than a generic claim that people resist change.
The problem-solution fit essay develops this relationship between a real problem and a proposed intervention. A first version should make that relationship testable rather than assume that a visibly better interface is enough.
Decide before interpreting the result
Before running the test, write the plausible next decisions. Continue with the current direction, narrow the audience, revise the workflow, investigate a specific failure or stop. This helps prevent every result from being interpreted as encouragement to build more.
The decision rule should fit the evidence available. A small qualitative study cannot support a precise conversion estimate. It can still reveal that the workflow depends on data participants cannot provide, which may be enough to change the product design.
An experiment needs a next decision, not just a place to collect observations.
When the evidence is ambiguous, say what remains unresolved. The next iteration should target that uncertainty. Repeating the same test with a slightly nicer interface may produce more activity without materially improving the decision.
It is also useful to record what would justify stopping. Teams often define the attractive path in detail while leaving the stopping path emotionally and operationally vague. Naming it in advance makes a negative result easier to use responsibly.
Avoid measuring the easiest event
Clicks and sign-ups are convenient because software can count them. Their usefulness depends on the question. A sign-up can show interest in an offer while revealing little about whether the person can complete the intended task or will return when the novelty fades.
Choose observations close to the assumption. If the product promises to help an operator resolve discrepancies, observe whether the operator can identify and act on a discrepancy using the result. If the risk is trust, investigate what evidence the operator needs before accepting a suggestion.
Do not discard lightweight signals. They can help diagnose the path to a more meaningful action. The mistake is treating an upstream event as proof of a downstream outcome without examining the gap between them.
For each measurement, write what it establishes and what it does not. That small discipline makes a launch report more useful and reduces the temptation to build a persuasive story from whichever metric happened to move.
Let the second version follow the evidence
A first version organized around a question produces a different backlog from one organized around a product category. If participants understand the report but cannot supply compatible input, the next work may be an import boundary. If they can supply input but cannot trust the mapping, the next work may be provenance and review.
Neither result automatically calls for more dashboard features. The next investment should follow the observed obstacle. This keeps the product’s shape connected to evidence rather than to the team’s initial picture of a complete application.
Preserve the learning in a short decision record: the question, the test, the observations, the limitations and the resulting choice. Future work can then build on what was learned without turning an early experiment into an unquestioned legend.
The first release has done its job when the team can make a better decision than it could before. Sometimes that decision is to build more. Sometimes it is to build something smaller, serve a different audience or stop. A useful first version makes those outcomes possible instead of treating continued implementation as the only acceptable result.