How to define an MVP without wasting the development budget

01Define the learning objective before the feature list

The Lean Startup methodology connects an MVP with learning through a build, measure and adapt cycle. The point is to reduce an important uncertainty, not to produce the cheapest possible collection of screens. Write the uncertainty in language that both business and delivery teams understand.

For the maintenance example, a hypothesis could be that the coordinator can turn a sufficiently clear request into an assigned task without repeated clarification outside the tool. This is an illustrative proposition to test, not a claimed result. It connects the product with a real operating problem.

Name the audience and situation. A small site with one coordinator may need a different first workflow from a multinational operator with complex approval rules. Trying to satisfy both immediately can create a broad platform before either audience has used a complete useful version.

• State the user and the specific problem.
• Define the behavior or outcome the version should enable.
• Identify the uncertain assumption behind that outcome.
• Choose the evidence that could support or contradict it.

Separate desirability, usability, feasibility and business assumptions. A team can prove that a form works while learning little about whether the buyer will adopt it. Conversely, enthusiastic interviews do not establish that the operation can run reliably. Choose which assumption this investment addresses and record the others as unresolved.

Agree who can make the next decision when the evidence arrives. If nobody is allowed to reduce scope or stop spending, the learning objective becomes decorative. The MVP brief should connect the question with an actual choice about continuation, revision or closure.

02Choose an experiment that needs only the necessary software

Eric Ries’s original MVP guide emphasizes learning with limited effort. A demonstration can be appropriate for an interaction question, while a real workflow may be necessary to understand adoption and operating constraints. Avoid treating one experiment format as universally correct.

GOV.UK’s alpha guidance describes testing risky assumptions using prototypes. That is a useful planning principle for a business product, without importing government delivery rules as mandatory practice. A prototype should answer the chosen question rather than accumulate production features by accident.

For the maintenance workflow, an assisted trial might establish which request details the coordinator actually needs. A production slice can then evaluate assignment and completion in routine work. Be clear about which parts are manual and the support available; do not represent simulated automation as a proven production capability.

Keep experiments reversible where practical. If a temporary integration or prototype will be discarded, say so in the brief and budget. Reuse should depend on its suitability for the next release, rather than a desire to justify money already spent.

03Draw one complete usable journey

Map the task from the user’s starting condition to a meaningful outcome. For maintenance requests, that includes submitting enough information, confirming receipt, assigning responsibility and showing completion. A working login page and an unfinished request screen are components, but they do not provide the operation being tested.

Identify necessary supporting work. Permissions, error handling, basic administration and measurement may be less visible than screens, yet the pilot can fail without them. Choose a baseline appropriate to the actual data and consequences. “Minimum” should reduce the supported scope while preserving the controls needed within that scope.

Define exceptional states that would invalidate the trial. A technician may reject an assignment or lose connectivity while recording completion. Decide which situations are supported, which have a clear manual route and which are outside the pilot. An unspecified failure can look like lack of demand when the real problem is an unusable workflow.

Keep the user promise aligned with that boundary. Explain the supported locations, roles and tasks to pilot participants. If the trial omits purchasing or preventive maintenance, people should know before committing to use it. Good scope includes the expectations needed to interpret feedback fairly.

The Scrum Guide describes a usable increment and an explicit quality definition. Those ideas can inform acceptance planning whether or not the team uses Scrum. Do not call an incomplete operation usable simply because its individual implementation tickets were closed.

04Make inclusions and exclusions reviewable

Create a compact scope record around the journey. For each proposed item, state the reason it belongs now, its acceptance condition and its dependencies. An item can be necessary because it produces evidence or protects the supported operation. General future usefulness is insufficient on its own.

Maintain an explicit deferred list with the reason for each decision. A request for native apps, advanced reporting or extensive integrations can return later when evidence supports it. Recording the reason reduces repeated debate without treating every deferred feature as rejected forever.

Review dependencies before accepting a small-looking addition. A status notification can require contact preferences, reliable delivery and support behavior. A new user role can change authorization and testing across the journey. Ask the delivery team what the feature really entails before promising it as a quick extra.

Make one person responsible for scope decisions, with appropriate stakeholder input. The team needs a timely way to resolve trade-offs. Consensus from every participant on every detail can allow a first release to grow while nobody owns its overall learning objective.

05Set spending gates around evidence and risk

Decide what the business can spend on the next uncertainty and what that amount must cover. Include design, implementation, testing, pilot support, infrastructure and evaluation. A development estimate that excludes the effort needed to run and interpret the trial is not the full MVP budget.

Separate the next committed stage from a broad forecast for the future product. Scope discovery can expose an expensive integration or missing operating dependency. Fund enough investigation to assess that risk before treating the whole roadmap as a fixed-price certainty.

1. Authorize a bounded discovery or experiment stage.
2. Review the resulting scope, risks and acceptance conditions.
3. Commit to the usable slice with clear exclusions.
4. Evaluate pilot evidence and operating cost.
5. Decide whether to continue, revise or stop before the next commitment.

Agree review triggers in advance. If a required supplier interface is unavailable, a key assumption fails or delivery effort changes materially, the team should return to the decision owner. The response may be a smaller experiment or a different supported journey, rather than automatically adding budget.

Use estimates with their assumptions and uncertainty visible. Unknown data quality or external approvals can affect effort. Avoid presenting an unqualified number that the team must defend after the underlying conditions change. The decision should explain what is known and which risk the next stage resolves.

Connect the investment with the software ROI framework, while keeping forecast benefits separate from observed results. An MVP can justify another experiment without proving the full business case. Hypothetical savings should not become reported customer outcomes.

06Define pilot evidence that can change the decision

Plan measurement before delivery finishes. For the maintenance product, record whether relevant requests reach assignment, where clarification is needed and whether the participants continue using the supported workflow. Choose definitions that reflect real work and document manual assistance.

Set success, revision and stop conditions with the decision owner. The appropriate thresholds depend on the business and experiment; there is no universal adoption rate or participant count that establishes a successful MVP. Keep the conditions realistic enough to distinguish a useful result from an inconclusive trial.

Combine behavioral evidence with explanation. A coordinator may abandon the tool because a required approval is missing, because the problem is infrequent or because the interface is confusing. These findings imply different decisions. A total login count would conceal the distinction.

Record which users, circumstances and support the evidence covers. A successful assisted pilot at one site does not establish independent operation across every customer. It can still be useful if the conclusion is scoped honestly and the next experiment targets the remaining uncertainty.

Avoid moving the goalposts after seeing the result. If the primary behavior did not occur, do not substitute social engagement or enthusiastic comments as proof that the operation worked. Record unexpected learning separately and decide whether it warrants a revised hypothesis.

07Keep the next roadmap conditional

Review what the first version established and what remains unresolved. The maintenance workflow may reveal that assignment is useful but that request quality requires a different input process. The next release should respond to that finding rather than follow an old feature list mechanically.

Choose between improving the current slice, adding a related journey or stopping the approach. Include operating capacity and support costs in that decision. A feature that requires continuous expert intervention may need process changes before broader deployment.

Keep the implementation maintainable enough for its declared role. A disposable prototype can have a different engineering plan from a live product holding customer records. Document temporary components, technical constraints and the conditions under which they must be replaced.

Close the pilot responsibly if the decision is to stop. Inform participants, provide access to needed records and retire accounts or infrastructure according to the agreed data arrangements. Learning from a failed assumption is useful only when the trial’s remaining obligations are handled.

Update the brief before funding the next stage. Carry forward the evidence, revised user promise, exclusions and decision conditions. This creates continuity without turning every initial assumption into a permanent requirement or every experimental shortcut into a long-term architecture.

08Questions about defining an MVP