Product DevelopmentHafsteinn Runarsson · AI Konsulent07 Oct 2026 · 15 min

What Is a Minimum Viable Product (MVP)? A Practical Guide

A minimum viable product (MVP) is the smallest complete version of a product that gives a specific group of users enough value to test an important assumption in real use. It should be small, but it still has to work. If nobody can use it to achieve a meaningful outcome, you may have built a prototype rather than an MVP.

A good MVP answers three questions:

1. Who are we building for?
2. What problem must the first version solve?
3. What decision will we make after people use it?

The third question matters most. Without a decision in mind, “MVP” can become another name for a small development project instead of a way to learn before committing more time and money.

What is a minimum viable product?

A minimum viable product is a coherent product version that lets real users complete one important job while the team tests a clear hypothesis. Its purpose is not to launch every planned feature. Its purpose is to produce credible evidence about whether the product creates value.

Eric Ries’s original explanation puts validated learning at the centre of an MVP rather than treating it as a merely small product. Agile Alliance adds a useful test: offer something real enough to observe what people actually do, not only what they say they would do.

An MVP may be a simple digital service, one tightly scoped workflow inside a larger system, or a partly manual service with a digital interface. The right form depends on the uncertainty you need to reduce.

A useful MVP usually has:

• one clearly defined first user group
• one prioritised problem
• one complete core journey
• enough quality, security and reliability for the intended use
• measurements linked to the hypothesis
• a plan for acting on the results

“Minimum” means that anything unnecessary for learning, safety or the core journey can wait. “Viable” means users still need a real reason to try the product.

Why build an MVP?

An MVP reduces risk by turning assumptions into observable behaviour before a team invests in a broader product. It gives users something complete enough to use and gives the team evidence that can shape the next decision.

The main benefits are practical:

• Faster learning: You can test the riskiest assumption without finishing the full roadmap.
• Lower waste: Work that does not contribute to the core journey can stay out of the first release.
• Earlier feedback: Real use reveals problems that interviews and internal discussions may miss.
• Clearer priorities: A defined hypothesis makes it easier to decide what belongs now and what can wait.
• Safer investment decisions: The team can continue, change direction or stop based on evidence rather than momentum.

An MVP does not remove uncertainty. It creates a controlled way to learn from it.

MVP vs prototype, proof of concept, pilot and beta

An MVP tests whether a limited product creates value in real use. A prototype, proof of concept, pilot and beta answer different questions, even though one initiative may pass through several of these forms.

Prototype

A prototype tests understanding, flow or interaction. It can be a sketch, a clickable screen or a simulation. People can show where they become confused, but the prototype does not need to process real data or deliver the actual service.

Use a prototype when the question is: Do users understand this idea or workflow?

Proof of concept

A proof of concept, often shortened to PoC, tests technical feasibility. It may explore an integration, model, data source or architecture without becoming a usable product.

Use a proof of concept when the question is: Can the uncertain technical part work well enough?

Minimum viable product

An MVP tests whether a specific solution creates value for a specific group in practice. It needs a working core journey and a way to observe what users actually do.

Use an MVP when the question is: Will this group use the product to solve the problem?

Pilot

A pilot is a controlled rollout. The product may be more mature than an MVP, but it is introduced to a limited team, customer group or location. The goal may be to understand adoption, operations, training or organisational impact.

Use a pilot when the question is: How does the product perform in a limited production environment?

Beta

A beta usually describes a release stage before general availability. It may be feature-rich but still limited to selected users while the team improves reliability, usability and support.

Use a beta when the question is: Is this broader product ready for a wider release?

A product can be both an MVP and a beta, but the labels describe different things. MVP describes a learning strategy; beta describes a stage of release.

Start with the hypothesis, not the feature list

The fastest route to a useful MVP is to define what you need to learn before deciding what to build. A long feature list often hides the fact that the team has not chosen its most important assumption.

Use this simple hypothesis format:

For [user group] experiencing [problem], we believe [limited solution] will enable [desired behaviour]. We will evaluate that belief using [observable signal] during [test period].

For example:

For finance staff who spend too much time sorting incoming requests, we believe a tool that suggests a category and next action will make triage easier. We will observe whether users complete the workflow, override suggestions and choose to use the tool again.

This is more useful than “build an AI assistant for finance.” It identifies the user, the problem, the expected behaviour and the evidence that will influence the next decision.

A strong MVP hypothesis should be:

• specific enough to be disproved
• focused on behaviour rather than opinions alone
• tied to one important uncertainty
• measurable with signals the team can actually collect
• connected to a decision the team is prepared to make

How to define the minimum viable scope

Define the smallest scope by mapping one complete journey from a concrete starting point to a meaningful result. Then challenge every proposed feature against that journey.

Ask five questions for each feature:

1. Is it required for the user to complete the core journey?
2. Is it required for the test to produce credible learning?
3. Is it required to make the product safe and responsible?
4. Does it produce a signal that can change the next decision?
5. Could the need be handled manually or more simply in the first release?

Sort the answers into three groups.

Must have

These elements make the core journey complete, safe and measurable. If you remove them, the user cannot reach the intended outcome or the team cannot interpret the test.

Should have

These elements improve the experience, but the hypothesis can still be tested without them. Include them only when the cost and risk are low.

Later

These are secondary workflows, advanced reporting, broad administration and variations that do not affect the first decision. Keep them visible in the roadmap, but do not build them “while you are there.”

A reliable rule is to remove side journeys before reducing the quality of the core journey. One complete experience produces better evidence than five unfinished ones.

A practical MVP example

Consider a company that wants to test an AI-assisted tool for handling internal requests. The MVP should support one operational team and one complete decision journey rather than every department and request type.

The core journey could be:

1. An employee submits a request.
2. The system suggests a category and next action.
3. A responsible person approves, edits or rejects the suggestion.
4. The decision is recorded and communicated to the requester.
5. The team can see when suggestions are accepted or overridden.

The first version may need only one submission channel, one request type and a simple role model. Multiple integrations, self-service administration, support for every department and an advanced analytics dashboard can wait.

This example also shows why an AI product should not be evaluated only on whether a model can generate an answer. Human review, error handling and traceability belong in the core journey when a suggestion influences a real decision.

Which MVP format should you choose?

The right MVP format is the cheapest responsible way to test your most important uncertainty. It is not automatically the smallest piece of software.

Common formats include:

• Single-feature product: Build one complete digital journey when you need to learn whether users can solve the problem with the product itself.
• Concierge service: Deliver the outcome manually while you learn the workflow, exceptions and language users understand.
• Manual-behind-the-scenes service: Let users interact with a simple interface while people perform uncertain steps behind it. Agile Alliance notes that an actual MVP can be a landing page or a service that appears automated while the work behind it is manual.
• Landing page or sign-up test: Test whether a clearly described offer attracts the intended audience before building the service. This can measure interest, but not whether the product creates value in use.
• Limited pilot: Use a controlled rollout when the product exists and the main uncertainty concerns adoption, operations or training in a real environment.

Choose the format by the question you need to answer:

1. To test whether people understand a workflow, use a prototype.
2. To test demand for a clear offer, use a landing page or sign-up test.
3. To test whether users receive value, deliver a real outcome through a product or service.
4. To test rollout in context, use a pilot.

Do not call every cheap test an MVP. The method is useful only when the test produces evidence for a defined product decision.

Quality you should not cut

An MVP can omit many future features, but it still needs enough quality to generate trustworthy results. If avoidable bugs, confusing access rules or unreliable data dominate the experience, you cannot tell whether users rejected the idea or the implementation.

Review at least:

• access and user roles
• invalid or missing data
• understandable error messages
• logging of critical events
• privacy and data retention
• the complete end-to-end journey
• recovery or rollback for important failures
• ownership after launch

The standard should match the risk. An internal planning tool has different requirements from a product that handles payments, health information or other sensitive data. The point is not to use one checklist everywhere. It is to make a deliberate risk decision.

Cut scope, not essential safety, privacy or operational quality.

How to build an MVP step by step

A useful MVP process moves from uncertainty to evidence in six steps. Each step should narrow the next one instead of creating a fixed plan too early.

1. Choose the first user group. Define the people whose behaviour matters for this test. “Small businesses” is usually too broad; a specific role in a specific situation is more useful.
2. Describe the problem and current alternative. Understand what users do today, what it costs them and why existing options are insufficient.
3. Write the hypothesis and decision criteria. Agree what behaviour would support the idea, what would challenge it and who will decide what happens next.
4. Test the biggest risks cheaply. Use interviews, a prototype or a proof of concept when those methods can answer a question before production work begins.
5. Build one vertical core journey. Connect the necessary interface, logic, data and operations so users can reach a real outcome.
6. Release, observe and decide. Introduce the product to the chosen group, combine usage signals with conversations, and decide whether to continue, change direction or stop.

The process is iterative, but iteration should not mean adding features by default. Each cycle should be driven by what the previous one taught you.

MVPs for AI products need an evaluation track

An AI MVP needs explicit evaluation because model outputs can vary even when the surrounding workflow stays the same. The first release should therefore test both the AI behaviour and the complete user journey.

Before launch, define:

• which tasks the AI feature should and should not handle
• examples that represent real use
• what counts as a good, acceptable and unacceptable result
• which errors require human review
• when a user must be able to override the system
• which data may appear in requests and logs
• how quality, response time and cost will be monitored

Create a small representative test set from important use cases. Include difficult, incomplete and ambiguous examples rather than only polished demonstrations. Run it again when instructions, models, data sources or tools change.

Evaluate the full workflow as well. A model can perform well on isolated examples while the product still creates friction or fails to help the user reach an outcome. Usage data, overrides, error patterns and short user conversations reveal different parts of the picture.

How to estimate MVP time and cost

There is no universal price or timetable for an MVP because the smallest responsible scope depends on the product. A simple interface can hide difficult integrations, data preparation or access controls. A larger-looking workflow may be straightforward when its dependencies are already understood.

Estimate the work in separate packages:

• problem definition and user research
• prototype and workflow testing
• technical investigation of the largest uncertainties
• implementation of the vertical core journey
• security, quality and production preparation
• controlled release and the first learning cycle

For each package, document assumptions, exclusions and decisions that could change the estimate. Ask what is explicitly outside the scope as well as what is included.

Treat the plan as phases, not a promise:

1. Define the user, problem, hypothesis and decision criteria.
2. Test the workflow and investigate the biggest technical risk.
3. Build one vertical journey through the interface, logic and data.
4. Test failures, access, measurement and operations.
5. Release to a limited group and follow usage closely.
6. Review the evidence and choose the next direction.

The duration of each phase depends on integrations, data quality, safety requirements, access to users and the availability of decision-makers.

How to measure an MVP

Measure signals that can change the product decision, not the metrics that are easiest to make look positive. Page views, registrations or demo reactions may be useful context, but they rarely prove that the product solved the intended problem.

Useful signals may include:

• whether the target group starts and completes the core task
• where users stop in the journey
• whether they return without being prompted
• which recommendations or actions they override
• which errors and support needs recur
• whether they want to keep using the product in the relevant workflow

Define the signals before release. Otherwise, the team may choose whichever metric looks most encouraging after the fact.

Combine behavioural data with conversations. Usage shows what happened. A conversation may explain why, but it should not replace observation of real behaviour.

Distribution is part of the MVP

An MVP cannot produce useful learning if the intended users never try it. Distribution therefore belongs in the scope alongside the product features.

Decide:

• who the first users are
• how they will be invited or recruited
• what introduction they need
• where they can report problems and ask questions
• who will follow up on their experience
• when the team will review the results

For a B2B product, the first group might be one customer team or one internal department. For a consumer product, it might be a deliberately limited waiting list or acquisition channel. The group must be relevant to the hypothesis, not simply easy to reach.

A landing page can be enough when you are testing interest in a clearly described offer. It cannot prove that people receive value from a product they have not used.

Decide whether to continue, pivot or stop

Agree on the possible outcomes before you see the results. This reduces the risk of treating every signal as a reason to keep building.

Continue

Continue in the same direction when the target group uses the core journey as expected, the value is visible and the major risks appear manageable. Improve the same core before expanding broadly.

Pivot

Change the user group, problem, workflow or solution when part of the hypothesis holds and part does not. A pivot should state what the team learned and which new assumption it will test. It is not simply a different feature list.

Stop

Stop or pause when the intended group does not show the expected behaviour, the problem is not important enough, or the risk and effort cannot be justified. A stop can be a successful outcome when the test prevents a larger investment in the wrong direction.

Do not make a large decision from a few random reactions. First check that the test reached the right users, that the core journey worked and that people had a fair chance to experience the value.

Common MVP mistakes

Most MVP failures come from unclear learning goals, excessive scope or quality cuts that make the evidence unreliable.

Trying to serve everyone

Multiple user groups, roles and side journeys increase the work and make user behaviour harder to interpret. Choose one first group and one core journey.

Treating “minimum” as permission for poor quality

Weak access controls, avoidable errors and confusing design create noise. Reduce scope instead of removing the quality required for a valid test.

Measuring activity instead of learning

Registrations and screen views can rise without showing that users solved the problem. Measure completed behaviour and repeat use when they are relevant to the hypothesis.

Launching without an owner

If nobody follows up on onboarding, questions and failures, low usage may be mistaken for low demand. Give one person responsibility for the first user group and the learning plan.

Sending a prototype into production

A clickable or technical demonstration often lacks operations, security, measurement and error handling. Review what is missing before connecting real users and data.

Leaving the MVP in permanent limbo

A temporary solution can accumulate additions without ever producing a product decision. Set the review date and decision owner before launch.

MVP checklist before you build

You should be able to answer these questions clearly:

1. Who is the first user group?
2. What specific problem are we solving?
3. What is the most important hypothesis?
4. What is the complete core journey?
5. What are we deliberately leaving out?
6. Which quality, security and privacy requirements cannot be cut?
7. Which technical uncertainties should be tested separately?
8. How will we reach the first users?
9. Which signals will make us continue, pivot or stop?
10. Who makes the decision after the test?

If the answers are unclear, resolving them is usually cheaper than starting full development.

How long does it take to build an MVP?

The timeline depends on the core journey, integrations, data, risk and how quickly the team can reach users and make decisions. Ask for a phased plan with clear assumptions instead of relying on a generic estimate.

How much does an MVP cost?

Cost depends on scope, team, integrations, data, security, platforms and the production quality the use case requires. A useful estimate shows what is included, what is excluded and which assumptions could change the price.

Can a landing page be an MVP?

Yes, when the hypothesis concerns interest in a clearly defined offer. A landing page does not test whether the product itself creates value in use, so match the test format to the question you need answered.

Does an MVP need real users?

Yes, when the goal is to learn about real product use. Colleagues can find obvious problems, but they do not replace the intended user group.

Is an MVP the same as a beta?

No. A beta usually describes a release stage before general availability. An MVP describes a strategy for learning with the smallest responsible product scope. A product can be both, but the terms answer different questions.

Should MVP code be thrown away?

It depends on what you built. A technical experiment may be disposable. A production-oriented MVP can be extended when its architecture, security and operations were chosen for that purpose. Decide this before development so a temporary demonstration does not become a long-term foundation by accident.

Build small enough to learn, complete enough to use

An MVP is a decision-making tool. The first version should be small enough to change, but complete enough for the target group to experience its central value.

Start with the hypothesis. Build one complete core journey. Plan distribution and measurement before release. Then agree what evidence will make you continue, change direction or stop.

Want to discuss a deliberately scoped first product release? Start a conversation.