What is an MVP, and how do you test a product idea before building it? 

An MVP is the smallest working version of a product that lets real users do the one thing it exists for, so you learn whether they want it before you build the rest. Test the idea with conversations, a landing page or a manual version first, and build only when people have shown they will pay.

What is an MVP, and what is it not?

MVP stands for minimum viable product, and it's the smallest version of a product that works well enough for real people to use it and give you honest feedback.

Two words in that phrase get ignored. Minimum means you cut everything that isn't needed to test the main idea, and viable means whatever remains must actually work. A half-finished product that frustrates users tells you nothing about demand and plenty about bugs, so aim for something small that a user can finish a real task with from start to end without your help.

An MVP is not a cheap, rough version of the final product. It's an experiment that exists to answer one question, like "will a clinic pay to send reminders by message?" or "will a buyer use an app to reorder from a supplier?" Once you have the answer you decide whether to build more, change direction or stop.

Most product ideas come with strong opinions and no evidence. Everyone around your table says customers will love it and nobody has asked a customer. In my opinion the cheapest way to find out is usually not to build at all.

Five ways to test an idea before writing code

These five tests go from the cheapest to the most involved. You do not need all of them, so start at the top and stop when you've learnt enough to make a decision.

Conversations

I'd talk to ten to twenty people who have the problem and ask about the last time it happened, what they did about it, what it cost them and what they use today. Don't pitch your idea, just listen for real pain, real spending and the workarounds people have cobbled together. If people shrug then the problem may not matter enough, but if they describe it with energy and show you the messy sheet they use then you've got something.

A landing page

Write a simple web page that describes your product and its benefit with one clear action like joining the waiting list or booking a call. Send people to it from your network or from a small paid campaign, and the number who take the action tells you whether the promise appeals. Be honest on the page and don't claim features that don't exist. A fair wording is that the product is coming soon and you're collecting names for early access.

A manual version

Deliver the service by hand before you automate it. If your idea is an app that matches buyers to suppliers then do the matching yourself with messages and a sheet. Your customers get the result and you learn which steps matter, where it breaks and what people will pay, and only then do you decide what to automate. This is my favourite of the five because it's cheap and real.

A prototype

A prototype is a set of screens that look and click like your product but have no real system behind them. Simple design tools can make one in a few days and your users can react to something concrete. It's good for testing the flow and the wording, but it doesn't prove that anyone will pay.

A paid pilot

Ask a few customers to pay a small amount to use an early version for a fixed period. Payment is the strongest signal because it costs your customer something real. If you ask me a pilot with five paying users teaches you more than a survey of five hundred people who said it sounds good.

What belongs in the first build

Once the earlier tests suggest real demand, build. Here's what I'd keep in a small and honest first build -

• One user type and one main job, like a clinic receptionist who books and confirms an appointment.
• The steps a user needs to finish that job from start to end, and nothing more.
• A simple and safe way to sign in that keeps each user's data private.
• Basic records of what your users do so you can see what they use and where they stop.
• A way for your users to tell you what went wrong, such as an email address or a button.
• A person who owns the product decisions and speaks to users every week.

What does not belong in the first build

• Extra user types like admin panels for every possible role before your main user is served.
• Settings screens, themes and customisation that nobody asked for.
• Integrations with every tool your user might own, when you can start with the most important one or none.
• Advanced reports and dashboards, because a simple export is often enough.
• Features that a single customer asked for once in passing.
• Polish that doesn't change whether your users complete the main job.

My test for any feature is a simple one. If you left it out, could a real user still do the main job and tell you whether the product is worth having? If yes then leave it out for now, because I would rather see a small build that works than a big one that almost does.

What changes when AI is inside the product

Some products use an AI model to read, write, sort or answer, and that adds a few questions an ordinary app never has to deal with -

• Quality is uneven, so an AI step may be right most of the time and wrong sometimes. Test it with a few hundred real examples from your users and not with three clean ones.
• Decide what a wrong answer actually costs you and your user. If a wrong answer is only annoying then accept it, but if it's harmful then a person must check it.
• Plan the human fallback, because your users need a way to correct or escalate when the AI isn't sure.
• Check the cost per use, since AI services usually charge by use and a popular feature has a running cost that a normal feature does not.
• Keep private data safe by knowing what you send to an outside service and what the provider does with it.

I'd use a manual version here too, because a person can play the AI for your first customers, so you learn what good answers look like before you build anything.

How a stake partner differs from a vendor

A vendor builds what you specify and bills for the work, and whether the product succeeds is your risk. A partner who takes a stake in the product shares that risk, so their interest is in the product working and not in the length of the project. That can change the advice you get, and a partner has a reason to say "don't build yet" or "build less".

Personally, I'd settle the terms early and in writing whichever route you take. You'll want to agree who owns the code, what each side contributes, how decisions get made and what happens if either side wants out.

How do you know whether the test actually worked?

Before each test, decide what result would make you go ahead, what would make you change the idea and what would make you stop. Write it down, because without that people read any result as a success.

Be honest about the strength of each signal. Friends and family tend to be kind, so ask people who have the problem and no reason to please you.

If the result is weak then that's still a good outcome! You spent days or weeks instead of months and you learnt something, so you can change the idea, pick a different customer or move on to a better one.

Frequently asked

Here are short answers to a few common questions.