Minimum Viable Product: 5 Steps to Test Your Business Idea

You have an idea for a new service, a product or an app, and someone is ready to quote for building it. Before you approve the work, how do you find out whether customers actually want what you are about to pay for? A minimum viable product can help you make that decision with better evidence.

What this article covers

I write about how better decisions are made in business, combining strategy, behaviour and practical thinking. Here, I explain MVPs in plain English, compare the common terms, and walk you through five steps you can use whether you sell software, physical products or services.

So, what is the smallest test that could change your mind about the idea? Keep that question beside you. It connects the definition to the practical work that follows.

What is a minimum viable product in simple terms?

Think of it as a test drive for your business idea. You choose a route that reveals something useful: can the customer complete the task, does the offer solve a real problem, or will someone pay? A trip around the car park cannot tell you everything about a long journey.

That is why I start with the question being tested. A basic app, a manual service or a prototype may each be suitable. They produce different kinds of evidence.

In Eric Ries’s explanation, learning is the central purpose. Nielsen Norman Group also describes prototype and live-code approaches. Some teams use MVP more narrowly to mean a usable first release. Agree what you mean before commissioning anything.

For this guide, a useful MVP needs three things:

• A defined customer and assumption. You know who the test concerns and what remains uncertain.
• A credible test. The experience is clear and usable enough for the result to mean something.
• A decision attached to the result. You know how the evidence could affect your next commitment.

“Minimum” is a limit on scope. You still need to deliver what you promised. “Viable” does not mean that one small test has proved the whole business will succeed.

VP vs prototype vs PoC: what is the difference?

An MVP tests a risky assumption about a customer and an offer. A prototype explores a proposed experience, while a proof of concept tests technical feasibility. An MMP is a marketable product, and an MMF is a valuable feature. These labels describe different purposes and can overlap.

If you are comparing quotes, these distinctions matter. A developer could deliver a convincing technical demonstration while you believe you have paid to test customer demand. Both parties may be pleased with the meeting. The invoice will be less open to interpretation.

Roman Pichler explains the MVP/MMP distinction, while the Agile Alliance’s MMF definition focuses on customer value. Terminology varies, so use the table to clarify a decision rather than impose a compulsory sequence. You do not need six projects because you have discovered six abbreviations!

What should you test before building an MVP?

Before building an MVP, identify the uncertainty most likely to change your investment decision. You may need to test the problem, the offer, willingness to pay, usability, technical feasibility or delivery cost. Choose a method that can answer that question without taking on unnecessary work.

Suppose you want to launch a booking app for a new service. If you do not know whether anyone wants the service, testing button colours will not help much. If customers already want it but staff cannot deliver it reliably, another interest survey misses the problem.

A concierge MVP means doing the work personally for a few customers. A Wizard of Oz test uses a simple interface with manual work behind it. Be clear about the service being provided; you do not need to mislead customers about automation.

You can also join existing tools together, often called a piecemeal MVP, or test one useful feature. Pick the format because it answers the question, rather than because its name sounds reassuringly entrepreneurial.

How do you build and test an MVP? 5 steps

To build and test a minimum viable product, define the customer and decision, identify the riskiest assumption, choose a small test, recruit relevant customers and review the evidence. Give the experiment a budget, an owner and a review date so that learning leads to a practical next step.

Here is how I would work through those five steps. You can keep the notes in a document or spreadsheet; a complicated system would be an unusual place to start a simplicity exercise.

Step 1. Define the customer, problem and next decision

Write down who has the problem and when it occurs. “Small businesses” is too broad to guide a useful test. “Owners of small offices who lose track of minor maintenance jobs” gives you a clearer starting point.

Then find out what happens today. Ask:

• “Tell me about the last time this happened.”
• “How did you deal with it?”
• “What time, money or inconvenience did it involve?”
• “Who decides whether to pay for a different solution?”

Notice the difference between the person using a service and the person approving its cost. A helpful office administrator may love your idea while the budget holder sees little reason to buy it.

Finish with a decision statement: “We need evidence to decide whether to offer a paid inspection pilot.” That is more useful than “We need to build an app…”

Keep: one customer/problem statement and one decision. Check that the idea supports your wider innovation strategy, rather than becoming another project that everyone is too polite to question.

Step 2. Identify the riskiest assumption and the evidence needed

List the things that must be true for the idea to work. Perhaps customers must care about the problem, accept the price and receive enough value to return. Your team must also be able to deliver it.

Choose the assumption with the most serious consequence if it is wrong. Turn it into a statement you can test: “At least three of twenty suitable prospects will buy this £150 pilot within fourteen days.”

Those numbers are an illustration, not a success formula. Your threshold should reflect your business, the customer buying cycle and the decision at stake.

Set a main measure and a guardrail. In this example, paid pilots are the main measure. A limit on delivery time protects you from winning work that absorbs the whole week.

Set the rules before seeing the result

Write down what would support the idea, what would challenge it and what would make the test inconclusive. Otherwise, a disappointing result can quietly become “exactly what we hoped to learn”. That is a comforting story, but a poor basis for more spending…

Keep: one testable assumption, the measures, the time window and provisional decision rules.

Step 3. Choose the smallest credible test and cap its scope

Use the test chooser above. If a person with a phone, a checklist and a basic report can deliver the promise, you may be able to learn before developing software.

Sort proposed features into three groups:

1. Must test now: necessary for the customer to receive the core value or for you to interpret the result.
2. Can wait: useful later, but unnecessary for this question.
3. Outside this test: unrelated requests, even if someone feels strongly about them.

For an inspection pilot, a clear report is essential. A customer dashboard can wait. A loyalty scheme is probably getting ahead of itself.

Set limits on cash, staff hours and calendar time. Name the person who can approve changes. Agree what customers will receive, what information you need and how problems will be handled.

Keep: a short test plan, a spending/time cap and an explicit list of excluded work.

Step 4. Recruit relevant customers and observe behaviour

Look for people who have the problem now. Existing customers, trade contacts and suitable professional groups can be useful starting points. Check that their needs and buying authority match the offer.

Invite them to a specific action. “We are testing a fixed-scope inspection and report for £150” produces a clearer response than “Would you be interested in a better way to manage maintenance?”

Record who received the offer, who responded, who committed and why others declined. Keep the exact objections where possible. “Too expensive” and “We only review suppliers each March” call for different decisions.

For a prototype, give the person a task and watch before helping. If you explain every button, you may be testing your presentation skills.

The Agile Alliance’s MVP guidance stresses learning from behaviour. Ask what the person did, what it cost them and whether it supports the assumption.

Keep: a simple evidence log with customer context, actions, objections and any problems with the test.

Step 5. Decide whether to continue, change or stop

At the review date, compare the result with your original criteria. First check whether the test worked: did suitable people see the offer, understand it and have a fair chance to respond?

Then choose the next commitment. Continue if the evidence supports it. Change the offer or test if a specific problem explains the result. Stop or pause when the main assumption remains weak and another test is unlikely to justify its cost.

Keep the team involved. Ask the person delivering the service what the headline figures leave out. Make it safe to report awkward evidence; nobody should have to defend your favourite idea to keep the meeting pleasant.

Keep: the decision, the reason, the next action, its owner and a review date. This is leadership through better thinking: making a clear choice, explaining it and following through.

What this looks like in real business

In a service business, an MVP can be a small paid pilot delivered with existing people and simple tools. It tests whether a defined customer values the outcome and whether the business can deliver it. You can investigate demand and delivery before committing to a dedicated platform.

An inspection service before a customer portal

(Illustrative example: the following business, figures and decision rules are hypothetical. They are not a client case or market benchmarks. Pounds are used for illustration; the approach can be adapted to your country and costs.)

Imagine a facilities business considering a monthly inspection-and-reporting service for managers of small commercial buildings. The proposed portal would store photographs, track minor issues and send reminders.

The owner sees a digital product. The customer may simply want fewer forgotten jobs and less chasing. That difference determines what to test.

For the first pilot, a staff member carries out one agreed inspection, sends a short report and discusses the priorities with the customer. An ordinary document and a phone call can deliver the core promise.

The test plan is deliberately limited:

• Audience: twenty relevant prospects with responsibility for building maintenance.
• Offer: one clearly scoped inspection and report for £150, with no recurring commitment assumed.
• Period: fourteen days to seek commitments, with delivery dates agreed before payment.
• Initial positive signal: at least three paid pilots.
• Delivery check: no more than two staff hours per pilot, including travel, reporting and follow-up.
• Experiment cap: £200 of extra cash costs and twelve staff hours across preparation, outreach and pilot delivery.
• Commercial check: the price must leave money after direct delivery costs and a realistic allowance for staff time.

The owner stops accepting work if delivery would breach the cap. More customers would require a fresh decision, rather than quietly turning a small test into an open-ended promise.

Suppose, for illustration, each pilot uses two hours at an internal cost of £25 an hour, plus £15 in travel and other direct expenses. That gives a direct cost of £65 and leaves £85 from the £150 price before sales effort, shared overheads and other costs. Three such pilots would leave £255 on that basis. That is not the profit of the whole experiment.

Now look at the possible decisions:

• People pay and delivery stays manageable: test whether customers want another inspection at a sustainable price. Keep the portal on hold until you understand repeat demand.
• People pay but each job takes five hours: check the scope, process and price. Software may help later, but it should solve an observed bottleneck.
• Nobody pays: review who saw the offer, problem urgency and the reasons given. Adding a dashboard will not automatically address those objections.

In my experience, a promising idea needs to be considered alongside the practical work it creates. That is why I include staff time and capacity in the test, rather than discovering them after the first enthusiastic sales push…

How I read this through the KrisLai Decision Framework™

This connects closely to how I think about decisions more broadly in the KrisLai Decision Framework™. Four questions make the pilot easier to judge:

• Behaviour: how do building managers handle the problem today, and will they commit to the pilot?
• Signals: what do payment, report use, objections and requests for another visit suggest?
• Environment: do buying cycles, travel distances, staffing and budgets support the offer?
• Consequences: what happens to workload, service quality and cash if demand grows?

This approach is part of the KrisLai Decision Framework, a practical method for improving business decisions.

A documented example: Buffer’s early tests

In his account of Buffer’s beginnings, founder Joel Gascoigne describes testing interest with a simple page, then adding pricing choices before building the functioning product. Actual payment came later, after launch.

The useful lesson is the sequence of questions. An email address suggested interest. A pricing click suggested something about price acceptance. A paying customer supplied different evidence again. None of those observations should be silently substituted for another.

How much does an MVP cost, and how long does it take?

An MVP has no single reliable price or timetable. Its cost depends on the question, test format, customer access, delivery effort and technical needs. Set a cash limit, a staff-time limit and a review date, then choose the smallest test that can provide useful evidence within those limits.

I would separate three budgets: preparing and recruiting for the test, delivering what you promise, and running the offer afterwards. A cheap build can still create an expensive service obligation.

Use dates that fit the buying situation. A two-week test cannot settle a purchase that normally needs several months of approval. You can still test an earlier commitment, such as an agreed trial meeting, while being clear about what it means.

Count your own time even when no extra invoice appears. My guide to business acumen explores why revenue, costs, capacity and consequences need to be considered together.

How do you know whether your MVP is working?

Your MVP is working as a test when it produces credible evidence about the assumption you chose. Look at relevant customer actions, successful use, payment, repeat demand and delivery effort. Judge those findings against your original criteria, while checking what the experiment could not reliably establish.

A test can be useful even when the idea performs poorly. Discovering a weak assumption early may save a larger commitment. Equally, a promising result deserves attention without being promoted into certainty.

Use a count and its context. Three purchases from twenty suitable prospects tells you something different from three purchases after thousands of unrelated visits. Note the price, time window and how people were recruited.

Amplitude’s MVP guide discusses behavioural measurement. For a small pilot, you can often begin with a spreadsheet containing the few measures needed for your decision.

If you have signups but no paying customers

Find the point where action stops. Did the offer attract people without the problem? Was the price unclear? Did the first task fail? Did you reach a user who cannot authorise spending?

Investigate the most plausible explanation, then change one important element for the next test. Altering the audience, price, message and product together makes it hard to know which change mattered.

Small samples deserve careful language. Three paid pilots are three paid pilots, rather than proof that fifteen per cent of the market will buy.

What should happen after a promising MVP?

Test the next uncertainty: repeat use, another customer group, a less hands-on delivery process or a sustainable price. A marketable release may follow when the evidence and delivery capability justify it. For product-market fit, you need evidence that enough of the right people keep choosing and getting value from the offer. One encouraging experiment cannot establish that.

Where minimum viable products go wrong

MVPs go wrong when teams build around untested assumptions, mistake encouragement for demand, expand the scope or ignore delivery costs. Results also become unreliable when the wrong customers are recruited or success criteria change afterwards. The remedy is a clear question, a fair test and an honest review.

The idea becomes something to defend

Once you have spent money or announced a launch, awkward findings can feel personal. That is when confirmation bias creeps in: you notice the positive comments and explain away the rest.

Ask a colleague to review the strongest evidence against your preferred answer. Give them permission to question the decision, not a request to approve your enthusiasm.

The pilot succeeds because the owner does everything

What I’ve seen in service work is how closely pricing, staffing and quality affect one another. If the owner handles every exception, the customer may enjoy a service the team cannot repeat.

Log the hidden work: chasing information, fixing errors, arranging visits and answering messages. That effort helps you judge the business behind the pilot.

A small test becomes a small version of everything

Extra features can arrive disguised as reasonable requests. Each one may be useful; together, they can delay the answer you needed.

When a request appears, ask whether leaving it out would prevent the customer receiving the promised value or make the result misleading. If neither applies, put it aside for the review.

There is a Finnish saying: “Ei kannata mennä soitellen sotaan.” Roughly, “do not march into battle playing music”. I take it as a useful reminder to prepare before charging ahead. A confident launch speech is lovely; it cannot do the customer’s buying for them…

Can AI help you build and test an MVP?

AI can help you draft test materials, organise notes, create a prototype or build a limited app. It cannot supply real customer demand or make invented feedback useful. Choose tools around the question you are testing, and check their output before letting it shape customer-facing promises or investment decisions.

I would start with jobs that save preparation time. Ask AI to identify leading interview questions, suggest alternative offer wording or organise anonymised notes into themes. Check each theme against the original notes, including the comments that challenge your idea.

If a prototype or app is needed, keep the choice proportionate:

• An offer page: your existing website and a simple form may be enough. Framer’s AI website tools are an optional way to create and refine a page.
• A task prototype: sketches may answer the first question. Figma Make can help create an interactive prototype when you need people to try a proposed workflow.
• A working app: consider whether a manual process would answer the question first. Bubble’s AI app tools can generate an initial app to review and refine, but you still own the checks, support and ongoing costs.

A generated demo with sample customers is evidence that a demo exists. Real users must still attempt the task. Keep private customer information out of tools unless you have checked that its use is appropriate.

AI and changing search behaviour: check how customers reach the test

A prospect may reach your offer through a conventional search result, an AI answer, a recommendation or a direct invitation. Ask how they found you and what they expected. Those routes can bring people with very different levels of intent.

Make the offer page clear about the customer, problem, outcome, price or next step, and the limits of the pilot. Google’s guidance on AI search features keeps the emphasis on normal search foundations and useful content, rather than special AI markup.

I explore the wider change in how AI is changing search behaviour. For your MVP, the practical question is whether discovery leads to meaningful action, rather than whether a tool can generate an impressive traffic report.

People also ask: three quick questions

Frequently asked questions about MVPs

1. How many users do I need to test an MVP?

There is no universal number of MVP testers. A few suitable participants can uncover problems in a task, while estimating demand needs broader evidence. Choose the sample around your question, customer group and risk. Explain who took part; a small, easily reached group may not represent the market.

2. Should an MVP be free or paid?

An MVP can be free or paid, depending on the assumption being tested. Free access may help investigate use or understanding. A paid pilot tests commitment at stated terms. If you need evidence about willingness to pay, a free trial alone will not answer that question.

3. Can an MVP be a physical product?

A physical product can have an MVP, such as a limited batch used to test a specific customer need. Keep the scope narrow while meeting the safety and quality requirements of the intended use. Measure customer behaviour and production effort before making a much larger commitment.

4. Can an established small business use an MVP?

An established small business can use an MVP to test a new service, product or way of delivering value. Existing customers can help with early access, but loyal buyers may respond differently from a new market. Keep the test focused and protect the service customers already rely on.

5. Can a spreadsheet be an MVP?

A spreadsheet can support an MVP when it helps deliver the promised outcome and test the chosen assumption. For example, a manually prepared reporting service may test demand before software is built. The spreadsheet itself is not validation; the evidence comes from customer use, commitment and delivery.

6. Who should be responsible for an MVP in a small team?

One named person should own the MVP’s learning goal, limits and review decision. Others can handle delivery, customer conversations or technical work. Agree who records evidence and who can approve changes. Small teams need clear responsibility more than a collection of impressive product-management job titles.

7. What is another word for minimum viable product?

Pilot, prototype and proof of concept are related terms, but they are not exact synonyms for minimum viable product. Choose the label that explains the purpose of your test. MVP normally means minimum viable product; “most viable product” and “least viable product” are not its standard meaning.

8. Is an MVP plan the same as a business plan?

An MVP plan describes a focused experiment: the customer, assumption, method, limits, measures and next decision. A business plan covers the wider business and how it will operate. Evidence from the MVP can improve that plan, but one experiment cannot establish every part of the business case.

9. Which book explains minimum viable products?

The Lean Startup by Eric Ries explains MVPs within an approach to learning under uncertainty. It connects assumptions, experiments and decisions about whether to continue or change direction. Read it for the reasoning behind the method, then adapt the test to your own customers and constraints.

What you should actually do: your one-page MVP plan

Before paying for a build, write a one-page MVP plan that connects your customer, riskiest assumption, test and next decision. Include limits on money and time, the evidence you need and who will review it. This makes the experiment easier to run, question and learn from.

You can copy these prompts into a document. An MVP canvas is useful when it makes the choice clearer; filling boxes is not a substitute for speaking to customers.

1. Customer and situation: who has the problem, when does it appear, and who approves spending?
2. Current behaviour: what do they do now, and what does it cost them?
3. Decision: what commitment are we considering, and what are the alternatives?
4. Assumption: what must be true, and what evidence could show we are wrong?
5. Test: what will we offer or observe, and what can this method establish?
6. Scope: what is essential now, and what is excluded?
7. Limits: cash cap, staff hours, customer commitments and review date.
8. Recruitment: how will we reach suitable users and buyers?
9. Evidence: main measure, supporting checks, time window and decision criteria.
10. Review: result, limitations, decision, owner and next action.

Over time, I’ve found that good decisions rarely come from data alone. The figures need to be read alongside the people involved, the conditions they face and the consequences of acting. That is what turns a completed test into useful business judgement.

Research and experience note: this guide combines my practical business perspective with independent research, analysis and synthesis of the sources linked throughout. The inspection pilot is illustrative. Buffer is a documented example, attributed to its founder. The five-step process is my practical synthesis, rather than a claim of guaranteed results.

Your next decision

You now have a way to turn an idea into a focused test, with limits, evidence and a decision at the end. You do not need every answer before starting, but you do need to know what the next experiment is meant to resolve.

Getting started can feel daunting when money and reputation are involved. A small, well-chosen test can make the next commitment easier to judge.

If you enjoy exploring the ideas behind better business decisions, you may find the Business Thinking Hub useful.

I help people make better business decisions through psychology, strategy and practical thinking.

BBC’s “Dragon’s Den” has showcased countless entrepreneurs who have successfully brought their innovations to market after securing investment from the show’s panel of seasoned investors. Many of the businesses featured, like Levi Roots’ Reggae Reggae Sauce and Tangle Teezer, started with a simple concept, much like the Minimum Viable Product (MVP) approach outlined in this article. The key to their success wasn’t just the financial backing but also applying lean startup methodologies, testing their products with real customers, and continuously iterating based on feedback—all crucial elements that we’ve discussed throughout this article.

These entrepreneurs understood the importance of validating their ideas early on, defining core features, and scaling their products smartly. By leveraging the advice and strategies similar to those found in this series—such as building a simple, testable MVP and focusing on real-world feedback—they were able to gain investor confidence and ultimately dominate their respective markets. Their journey reflects the power of applying structured, practical steps in turning innovative ideas into profitable businesses.

👉 Explore ideas connected to better business decisions:

• Digital Transformation for SMEs: 7 Questions Before You Invest
• Cybersecurity for Businesses: 7 Decisions Leaders Must Make
• How AI Is Changing Search Behaviour (And What Businesses Must Do Now)
• 7 Decision-Making Framework Examples for Business Leaders
• Business Decision-Making Framework: The KrisLai Method