Define what your MVP needs to prove, choose between a prototype and a working product, and agree what evidence should guide your next investment.

An MVP can launch on time, contain every agreed feature and still leave the important question unanswered. People can log in and click through the screens, but the team is no clearer about whether the product solves a problem worth investing in.

A minimum viable product needs a clear learning objective as well as a delivery scope. Before deciding what belongs in the first build, agree which uncertainty it should resolve and what evidence would change your next decision.

Start with the assumption that could undo the idea

A feature list describes what software will do. It does not explain why those features are worth building.

Begin with the assumptions behind the idea. Perhaps customers will complete a task themselves instead of calling your team. Perhaps staff will adopt a shared workflow instead of maintaining individual records. Perhaps the value depends on connecting to a system you do not control.

Choose the assumption that combines significant uncertainty with a serious consequence if it proves wrong. A polished dashboard will not help much if the underlying data cannot be accessed, and a technically impressive platform may have little value if people have no reason to use it.

Write the learning objective plainly. For a customer portal, it might be whether customers can submit a complete request without staff guiding every step. That gives the team something specific to investigate.

If you are still deciding whether a bespoke product is justified, our guide to when to build custom software helps establish the case before you commit to a first release.

Choose the smallest way to get credible evidence

The right starting point depends on the question. A prototype, a technical proof of concept and a working MVP produce different kinds of evidence, and they should not be treated as interchangeable.

A prototype for understanding and usability

A clickable prototype can help you explore whether people understand a proposed journey, find the right actions and interpret the information correctly. It is useful while screens and steps are still easy to change.

It cannot demonstrate production reliability or show that customers will keep using the product. A positive reaction to a demonstration also does not establish willingness to pay.

A proof of concept for a technical uncertainty

A small technical build can investigate whether an essential integration, calculation or data flow is feasible. Keep it focused on the constraint that needs resolving.

The result may be deliberately unsuitable for release. If it becomes part of the eventual product, allow for the work needed to make it secure, maintainable and dependable.

A working MVP for real use

A working MVP lets a defined group complete a useful task and gives you evidence from actual behaviour. That might include whether they finish the journey, where they need help and whether they return when the same need arises.

Our MVP development work starts by choosing what needs proving, so the first investment goes towards the right form of evidence.

Build one complete journey with clear boundaries

A first release should have a beginning, an outcome and enough support between them for the chosen users to succeed. Several disconnected features rarely provide the same learning value as one complete journey.

For a request portal, that could mean a customer submits the required information, the team receives it, and both sides can understand its status. Advanced reporting, extensive customisation and extra user groups may be able to wait.

Write down the boundaries alongside the inclusions. Who can use this version? Which types of request does it support? What happens when information is missing? Which exceptions will a person handle?

Some manual work behind the scenes can be reasonable during an early release, provided the responsibility is explicit and the arrangement can be operated safely. It should not hide the effort required to deliver the service when you review the results.

A smaller scope still needs appropriate access controls, data handling, recovery arrangements and support. Limit the breadth of the product while taking care of the people and information involved.

Agree how you will judge the result

Define the decision criteria before the first demonstration. Otherwise, enthusiasm for a finished screen can quietly replace the original purpose of the work.

A short learning brief should answer five questions:

• Which assumption are we investigating?
• Who needs to use the product for the evidence to be relevant?
• What behaviour or result would support the idea?
• What would make us change direction or stop?
• When will we review the evidence, and who will decide?

Choose measures that fit the task. For an internal tool, useful signals might include completion time, missing information and the amount of staff assistance required. For a customer product, you may need to understand completion, repeat use and whether people will make the commitment the service depends on.

Set realistic thresholds for your context. There is no universal number of users or successful sessions that proves an idea. A small pilot can expose problems and guide decisions, but it cannot automatically establish wider demand.

Combine observation with conversation. Find out why someone abandoned a step, asked for help or used a workaround. The explanation often tells you what to change next.

Let the evidence shape the next investment

The next step might be a wider pilot, an improved journey, more technical investigation or a decision to pause. Each can be a useful outcome if it reduces uncertainty before a larger commitment.

Avoid turning every suggestion into the next release. Prioritise changes that address an observed barrier or investigate the next important assumption. Keep preferences and possible future features separate from work supported by evidence.

Before expanding, review the operational demands too: support effort, hosting, data quality, integration reliability and who will own the product. A successful first journey should leave you better informed about the work required to sustain it.

The most useful MVP gives you a clearer decision. When the learning objective, scope and review criteria are agreed from the start, the first build can guide what deserves further investment and what still needs to be understood.