How do you define the scope of a genuinely useful MVP?

At the start of a project, almost every feature seems essential. You need a user area, a dashboard, notifications, exports, a mobile app, several roles and perhaps an AI feature. As the requirements accumulate, the first release starts to look like the finished product.

An MVP, or minimum viable product, has a more specific purpose: test a value proposition through real use within a limited scope. It is neither a small version of every possible feature nor an excuse to deliver unreliable software quickly.

The right scope answers an important question without requiring you to develop everything that might be useful one day.

Start with a hypothesis that use can support or challenge

“Build a management platform” is an intention. “Let site managers track a maintenance visit without calling our team” describes an observable result.

Take the second case as a fictional example. The hypothesis might be:

If site managers have access to up-to-date information about their maintenance visits, they will check the portal for progress and contact our team by phone less often.

This identifies a user, a situation and an expected change. It also suggests several possible reasons for failure: the information is stale, the statuses are confusing, access is awkward or users prefer their usual contact person.

Choose the main uncertainty. Are you testing user interest, technical feasibility, operational efficiency or willingness to pay? A single test will not necessarily answer all four questions.

If the obstacle is solely the feasibility of an integration, a technical proof of concept may be enough. If you want to test whether people understand a journey, an interactive prototype may be suitable. Building an MVP becomes useful when you need to observe the service operating in practice.

Choose a primary user and one complete journey

Map the path required to achieve the promised result. For the maintenance portal, an initial version could let a site manager:

1. access their account;
2. find their maintenance visits;
3. understand the current status and next step;
4. read a visit report;
5. ask a question when information is missing.

This journey is more useful than a product with ten sections, none of which reaches a complete outcome. It also exposes an often-forgotten requirement: someone needs to update the statuses so that the information is reliable.

The internal team’s work therefore needs to be defined too. How do they update a visit? What happens if the technician has not submitted a report? Who answers the customer’s question? The portal’s value depends on that operating process, not just its interface.

Remove features that do not contribute to the test

For every proposed feature, ask: without it, can we still test the hypothesis under acceptable conditions?

In our example, appropriate access rights and understandable statuses are essential. An advanced analytics dashboard, extensive interface customisation or a native mobile app can wait if a mobile-friendly website supports the journey.

An export may also be secondary if the pilot is about checking progress. It becomes essential if the promised outcome is specifically to produce a supporting document for another department.

Priority therefore depends on the test, not on the feature’s name. Write down what you have deliberately excluded and why. That list will help you resist additions that do not change what you are trying to learn.

Apply the same reasoning to an AI feature. If a structured status or a prepared message is enough, an autonomous agent is not required for the first test. Our guide to AI agents and conventional automation helps you assess that need separately.

Accept manual work, provided it remains visible

Part of the service can be operated manually during the pilot. The team might import the first jobs, check reports or prepare a summary before making it available.

This lets you test the value of the journey without immediately building every integration. There is a limit, though: invisible manual effort can create a misleading impression of profitability or quality.

Record the time spent, the corrections made and the skills needed. A service that users appreciate but that takes two hours of preparation per case has not yet demonstrated its economic viability. That finding is still useful: it shows which part of the process needs simplifying or automating.

Do not pretend that an outcome is available if nobody can actually deliver it. The pilot must provide the promised service, even if the work behind the scenes is still provisional.

Define what “finished” means

“The customer can view their maintenance visits” leaves too much open to interpretation. Precise acceptance criteria make the work verifiable:

• a customer sees only visits for sites they are authorised to access;
• each visit shows its current state and the date it was last updated;
• a missing report is explained rather than presented as an error;
• data persists after the service restarts;
• the team can detect a failed update;
• the main journey works on participants’ phones.

Limiting functionality does not remove the need to protect data and users. Access rights, data recovery and error handling are part of the service’s minimum reliability.

On the other hand, there is no need to build an architecture designed for millions of accounts without a demonstrated requirement. Choose a solution the team can deploy, monitor and evolve at the expected level of usage.

Prepare the pilot before development ends

Identify participants, the situations in which they will use the product and the person who will support them. A delivered application with no users available produces no learning.

The protocol should specify:

1. The baseline: how the work is done today.
2. The observation period: long enough to see the journey happen several times.
3. The measures: what will help you judge the result.
4. Qualitative feedback: why people abandon, hesitate or work around the process.
5. The decision rule: continue, change the journey or drop the hypothesis.

For the portal, track useful visits to the service, phone enquiries about progress and jobs requiring corrections. Relate the results to the number of cases: fewer calls during a quiet week do not prove the product is effective.

A small pilot helps uncover usability problems. On its own, it does not establish that every customer will adopt the service. Record the limits of the sample before generalising from it.

Turn the first review into a decision, not another feature list

After the pilot, group observations by their effect on the hypothesis. If users check the portal but still call because the statuses are too vague, adding a chart is unlikely to solve the problem.

If the portal sees little use, first investigate why: no frequent need, the wrong information at the relevant moment, difficult access or insufficient value. Each cause calls for a different response.

You can then decide to fix the journey, gradually extend the scope or stop investing. Ending a project after a clear test can be a good decision; continuing without understanding the results rarely is.

Before building, also check whether an existing SaaS product or hybrid solution could test the same proposition more simply. An MVP is a way to learn and deliver a service, not an obligation to build everything yourself.

Do you have an idea accompanied by an ever-growing feature list? Let’s discuss the first journey to deliver, the hypothesis it needs to test and the features that can wait.