Most founders treat a minimum viable product (MVP) as something to ship. A more useful habit is to treat it as a question you put in front of real people. This guide walks through a short discovery cycle you can run in about two weeks: recruit users, observe a task, test a narrow solution and decide what changes. You will also get an experiment log and decision criteria you can use right on this page. Nothing here guarantees growth. The goal is evidence, not applause.
A minimum viable product (MVP) milestone is a learning milestone, not a launch date. In 14 days, recruit 6 to 8 people who match one user definition, watch about 5 of them do a real task, test one narrow solution, and decide using criteria you wrote before the sessions started.
What is minimum viable product (MVP) in practice?
Eric Ries popularized the term in The Lean Startup. He described it as the version of a product that lets a team collect the most validated learning about customers with the least effort. Notice what is missing from that idea: a feature count, a polished design and a launch party.
If you ask what is minimum viable product in plain words, the answer is the smallest thing that can show whether a real person has the problem you think they have, and whether they will change their behavior to solve it. That is why we frame minimum viable product development around milestones of evidence. A feature list tells you what you built. A learning milestone tells you what you now know.
Many early teams run their first rounds by hand: direct messages, a video call, a spreadsheet instead of software. Paul Graham’s essay “Do Things That Don’t Scale” argues that founders often win early users through manual effort. We use that manual style as background for the cycle below. It is a common starting pattern, not proof that it works for every product.
The 14-day discovery cycle for your minimum viable product
Each stage has exactly one output. If a stage produces no output, you are not ready for the next one.
Days 1 to 3: Recruit the right users
Write one sentence that describes who has the problem: their role, their situation and the workaround they use today. Then recruit 6 to 8 people who match it. Good places to start are people you can message directly, online communities where the problem is discussed, and customers of adjacent tools. Avoid friends who will be polite instead of honest. Ask for 30 minutes and say plainly that you are not selling anything.
Output: a list of booked sessions and a one-line user definition.
Days 4 to 6: Observe a task
Steve Blank’s startup advice is to “get out of the building.”
Steve Blank, customer development method
That advice is the heart of this stage. Ask each person to do the task you care about, on their own tools, while you watch. It resembles usability testing, except you are testing the problem before you test a product. Stay quiet. Note where they pause, switch tools, copy data by hand or build a workaround.
Use customer discovery interview questions that look backward, not forward. Good examples: “Walk me through the last time you did this.” “What did you try first?” “What did it cost you in time or money?” “What did you do when it went wrong?” Rob Fitzpatrick’s book The Mom Test makes the case that stories about past behavior are more reliable than opinions about a hypothetical product.
If you are wondering how to conduct user interviews without leading people, follow three rules. Ask open questions. Do not pitch your idea in the first 20 minutes. Write down the exact words people use, because those words become your copy and your feature names later.
Output: a one-page summary of observed steps, workarounds and repeated phrases.
Days 7 to 10: Test a narrow solution
Pick the single most painful moment from your observations and build the smallest thing that addresses it. That could be a shared document, a form with manual follow-up, a clickable prototype or a script you run yourself. This is how to test minimum viable product ideas without building infrastructure first.
Run the same task again with 4 or 5 of the same people. Compare time, effort and errors against their current workaround. Prepare your usability testing questions in advance: “What did you expect to happen here?” “What would you do next?” “What is missing?” Record what people do, then what they say. When the two disagree, trust what they do.
Output: before-and-after notes for each user.
Days 11 to 14: Decide what changes
Gather your team, open the log and apply the decision criteria you wrote before the sessions. Choose one path: build the next narrow slice, change the user or the problem, or stop. Then write down one specific change for the next cycle. Writing the criteria first protects you from reading every result as good news.
Output: a decision and a dated next experiment.
What the sources say and what we propose
We keep these two things apart on purpose. The first column is background from published work. The second column is our own working template, which you should adjust.
Source claims
Ries: an MVP exists to produce validated learning.
Blank: talk to customers, not only to your team.
Graham and Y Combinator: “Make something people want” is the YC motto, and early manual work is common.
Fitzpatrick: ask about past behavior, not opinions.
Our proposal
A 14-day cycle with four outputs.
6 to 8 recruited users, about 5 observed.
Decision criteria written before sessions.
These numbers are starting points. Small samples reveal patterns, not statistics, and no cycle guarantees demand.
Interactive experiment log
An experiment log turns scattered conversations into a record you can review. Add one row per experiment, then copy the log into your notes or a shared document.
Hypothesis
Method
Users
Result
Decision
Build next slice Change user or problem Run another test Stop Add rowCopy logClear
Interactive decision criteria for your MVP
Agree on criteria before you run a single session. The examples below are samples, so edit the numbers to fit your context. Tick each statement that your evidence supports and see the suggested next step.
At least 5 of 8 observed users completed the core task without help.
At least 3 users described the same problem in their own words, unprompted.
At least 2 users took a real action, such as asking to keep using it or booking a follow-up. Compliments do not count.
The narrow solution reduced time or effort compared with the current workaround.
We can name one specific change to make next week.
Tick the statements your evidence supports.
What comes after minimum viable product testing
When people ask what comes after minimum viable product work, the honest answer is another cycle. If the evidence is strong, widen the slice and recruit a slightly different user group. If it is mixed, change one variable and rerun. If it is weak, return to the problem or the user definition before writing more code. Evidence lowers the risk of building the wrong thing. It does not promise that customers will arrive.
Common mistakes in early MVP testing
- Counting compliments as evidence. “Nice idea” costs the speaker nothing. Actions do.
- Moving the goalposts. Changing criteria after you see results defeats the purpose.
- Recruiting too broadly. Mixed user groups produce muddy patterns.
- Building before observing. You end up solving a problem you imagined.
- Skipping the log. Memory rewrites results within days.
FAQ: minimum viable product (MVP) testing
What is minimum viable product (MVP) in simple terms?
It is the smallest version of a product that can teach you whether real people have the problem you think they have and will change behavior to solve it.
How many users do I need to test a minimum viable product?
For a first discovery cycle, 6 to 8 recruited users and about 5 observed sessions is a practical starting point. Small samples show patterns, not statistics.
What comes after minimum viable product testing?
Decide to build the next narrow slice, change the user or problem, or stop. Then schedule the next dated experiment.
Want a second pair of eyes on your discovery cycle?
iAastha works with technical teams on AI and product engineering.
Book a 20-minute call and we will review your user definition and decision criteria with you.
