What is an MVP, and what should go in yours?

An MVP, or minimum viable product, is the smallest version of a new product that real customers can use, built to test whether your most important assumption about them is true. It is a tool for learning what to build next, not the first instalment of everything you have planned.

This guide is for founders, and for product owners inside established businesses, who are about to build new software. If you would like a team to do it with you, our MVP development service covers design, build, hosting and support, but everything below works without us.

Where the term comes from

Frank Robinson is credited with coining the term in 2001, according to the Wikipedia entry on the minimum viable product. It was popularised by Eric Ries, first on his blog and then in his 2011 book, The Lean Startup.

In a 2009 post, Ries defined the minimum viable product as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

The word that matters in that definition is learning. In the Lean Startup method, the MVP is the first turn of a loop: build something, measure how people respond, learn from it, then decide whether to change course or carry on.

What an MVP is not

Two misreadings cause most of the trouble.

• It is not a buggy prototype. "Minimum" refers to scope, not quality. If people can't finish the one task the product exists for because it crashes or loses their data, you learn nothing about demand. The parts you do build should work properly.
• It is not a cut-down version of the full plan. Taking a long roadmap and deleting half the features leaves you with a smaller copy of the same untested bet. An MVP starts from the question you need answered, then asks what the least is that you can put in front of people to answer it.

It is also different from a prototype, which shows how something might look or work, or a proof of concept, which shows that something is technically possible. An MVP goes to real users, in real conditions, and asks them to do something that costs them time, attention or money.

How to decide what goes in

Work through these in order, and write the answers down. You will judge the result against them.

The one problem

Name the single problem the product solves, for one kind of person, in one sentence. If the sentence needs "and" twice, you probably have more than one product. Anything that doesn't serve that sentence can wait.

The riskiest assumption

List what has to be true for the product to succeed: that the problem hurts enough, that these people can be reached, that they will pay, that the thing can be built at all. Then pick the one that would sink you if it were wrong and that you have the least evidence for. That is what the MVP tests. For most new products it is demand rather than technology, but if the core is genuinely hard to build, technical risk can come first.

What you need to learn

Turn that assumption into a question with an answer you can observe. "Do people like it?" is too vague. "Will at least ten of the first fifty people who try it pay for a second month?" is a question you can answer. Decide now which result would make you carry on, change direction or stop.

What can be manual behind the scenes

Anything the customer doesn't see can often be done by a person for now: approving accounts, sending reports, matching requests, onboarding, or taking payment through a simple payment link instead of a full subscription system. Build the part the customer experiences as the product, and do the rest by hand until the volume makes that impractical. Manual work is slow, but it is easy to change, and changing things is most of what happens after launch.

The main kinds of MVP

• Concierge MVP. You deliver the service by hand to a small number of customers, and they know a person is doing it. It tests whether the outcome is wanted, and it teaches you the steps before you write any software.
• Wizard of Oz MVP. The customer sees what looks like a working product, but people do the work behind it. Unlike a concierge MVP, the customer doesn't know. It tests whether people will use the product as designed, without building the hardest parts.
• Single-feature MVP. Real software that does one job well. It suits products whose value only shows once the software exists, such as a tool that saves someone a repetitive task.
• Piecemeal MVP. A working service assembled from existing tools, such as forms, spreadsheets, a payment provider and an email service, joined with a little code. Customers get something real, and you avoid building what already exists.
• Landing page or explainer video. A page or short video that describes the product and asks for a sign-up, deposit or pre-order before the product exists. It measures interest, not use, and a sign-up is a weak signal next to a payment. Some people treat this as a test that comes before an MVP rather than an MVP itself.

For software, a single-feature MVP with manual work behind it is often the most useful mix: real enough to test whether people use it, small enough to change quickly.

How to tell whether it worked

Judge it against the question you wrote down before launch, not against a number you choose afterwards.

• Watch behaviour, not opinions. People are polite in interviews. Payments, repeat use and completed tasks are much harder to fake.
• Measure retention as well as sign-ups. A burst of sign-ups shows your message works. People coming back shows the product does.
• Talk to users as well as counting them. Numbers tell you what happened, and conversations tell you why. Speak to people who stayed and to people who left.
• Accept a clear no. An MVP that disproves your assumption has done its job early, while changing course is still affordable. Every result leads to one of three decisions: carry on, change direction or stop.

What usually goes wrong

• The scope grows. Each extra feature seems small and reasonable. Together they turn an MVP into a full first version that takes far longer and teaches you no more.
• There are no success criteria. Without a test written down in advance, every result looks encouraging.
• Polish goes to the wrong places. Time is spent on settings, admin screens and branding, while the core task stays awkward or unreliable.
• Nobody is lined up to try it. Building comes first and finding users comes later. Find the first people who will use it before the build starts.
• It is treated as throwaway. If it works, people will rely on it. Plan for hosting, backups, monitoring and someone to fix it, or you will be rebuilding in a hurry at the moment you most want to be selling.

What our own products suggest

We build and run products of our own. Two are useful here, not for how they began, but for what an established product says about where to start.

Add to CRM is a Chrome extension that adds people from LinkedIn, Gmail and Outlook to a CRM in one click, with a verified email. It works with 29 CRMs and had 276 paying customers on 28 October 2026, a figure taken from Stripe.

• The product fits in one sentence. Add a person to your CRM in one click, with a verified email. If your MVP can't be described that plainly, its scope is probably too wide.
• An established feature list is not a starting point. Twenty-nine CRM integrations is a lot of software to build and keep working. It is the wrong thing to copy into an MVP plan, where one or two integrations that reach the people you are testing with will answer the question.
• Count what the billing system counts. The number we quote for Add to CRM is paying customers, from Stripe. Payment is the hardest signal to argue with, so where you can, make it your MVP's measure too.

4dayweek.io is a job board for four-day-week and other reduced-hours jobs, founded by Phil McParlane in December 2020. It now reads more than 1,300 company job boards and has an AI service that reads job ads.

• Automation is for scale, not for the test. Reading over a thousand job boards automatically is what a large job board needs. An MVP of a similar idea could have a person collect and check a few dozen listings by hand, and learn just as much about whether anyone wants them.
• A narrow audience helps. The board serves people who want reduced hours, not everyone looking for work. A narrow group is easier to find and talk to, and gives you a clearer answer.

If you want a hand

We design, build and run MVPs, then host and look after the ones that work. If you have a product idea to test, start a project and tell us what you need to learn.