Test an MVP by putting it in front of 20 to 50 real users from your target segment in the first two weeks, watching what they do before asking what they think, and measuring whether they complete the core journey and come back. Interviews should ask what users did and what they expected, never whether they liked it. Feedback that points at the path to the value means polish. Feedback that says the value itself is not wanted means pivot. Friends, family and other founders are not real users and their feedback is worth nothing.
An MVP that is not tested with real users is a product launched on hope. The testing is not a phase after the build but the reason for the build, and it is cheap to do well and easy to do badly. Done badly it produces compliments, feature requests and false confidence. Done well it tells you, inside a month, whether to keep going. This post covers who to test with, what to measure, how to interview, and how to read what you get.
Who counts as a real user?
Someone who has the problem, is in the segment you are building for, and did not know you before. Friends, family, colleagues and other founders fail at least one of those tests. They want you to succeed, they will use the product to be kind, and their feedback is about you rather than the product. Recruit strangers: from the waiting list, from communities where the problem is discussed, from a small paid campaign, from cold outreach to people who match the profile. Twenty to fifty in the first two weeks is enough to see patterns. Hundreds are needed before percentages are reliable.
What should you watch before you ask?
Behaviour first, opinion second. Before any interview, look at what users actually did:
- Did they reach the core action? The one thing the product is for. The share who do is your activation rate.
- Where did the ones who did not stop? The funnel between sign-up and core action, step by step. The largest drop is your first problem.
- Did they come back? Within a week, unprompted. This is the number that matters most.
- What did they do that you did not design for? Session recordings show users trying to do things the product does not support. Those are feature requests nobody will articulate.
Which metrics to track after launch covers how to set these up. Set them up before the first user arrives, not after.
How do you run an interview that produces evidence?
Thirty minutes, one at a time, ideally while the user shares their screen and uses the product. Ask about what happened, not about what they think:
| Ask this | Not this | Why |
|---|---|---|
| What were you trying to do when you opened it? | Do you like it? | People are polite. They are also honest about their own goals. |
| Walk me through what you did last time you used it. | Would you use this? | Hypothetical use is worthless. Actual use is evidence. |
| What did you expect to happen here? What happened? | Is this confusing? | The gap between expectation and result is the usability finding. |
| What do you do today to solve this without us? | Would you pay for this? | What they pay for now, in money or time, tells you what the problem is worth. |
| What would you miss if this disappeared tomorrow? | What features do you want? | Loss reveals value. Feature lists reveal imagination. |
Interview ten users who came back and ten who did not. The second group is harder to reach and more informative. Record with permission, take notes on what they did and said, and resist explaining the product to them. If they could not work it out, that is the finding.
How do you read the feedback?
Sort everything you hear and see into three piles:
- Path problems. Users want the value and cannot reach it. Confusing sign-up, an unclear first screen, a step that fails. These are polish. Fix the biggest, re-test, repeat.
- Value problems. Users reach the value and do not care, or the problem turns out to be rare, or the people who care are a different segment from the one you built for. These are pivots. No amount of polish fixes them.
- Noise. Feature requests from a single user, opinions about colours, suggestions that would make the product something else. Note them and move on.
The mistake founders make is treating value problems as path problems, because path problems are fixable and value problems are frightening. If activated users do not come back, the path is not the issue. What to do after your MVP launches maps the patterns to the decisions.
How do you test before the MVP exists?
The same methods work earlier and cheaper. A clickable prototype tested with ten target users catches most path problems before anything is built. A concierge version, where you do the job by hand for a few customers, tests the value before you automate it. How to validate a startup idea before writing code covers these, and the best MVP tests are ones where the value was already validated and only the product is in question.
The testing plan
- Analytics on the funnel and on return visits before launch.
- 20 to 50 strangers from the target segment in the first two weeks.
- Session recordings watched, patterns noted.
- Ten interviews with returners, ten with leavers, behaviour questions only.
- Findings sorted into path, value and noise.
- Biggest path problem fixed and re-tested within a week.
How 7L tests MVPs
User testing is built into our process at two points: a clickable prototype tested with target users before development starts, and a structured testing period in the first weeks after launch, with the engineering team watching the recordings alongside the founder. We help recruit, we sit in on the interviews, and we sort the findings with you. Most path problems we see are fixed inside a week. Value problems we flag early, because the sooner a founder hears it the cheaper it is. If you have an MVP live and are unsure what users are telling you, bring us the recordings.
Frequently asked questions
How many users do I need to test an MVP?
Twenty to fifty from the target segment is enough to see patterns in behaviour and to run meaningful interviews. Percentages such as activation and retention become reliable in the hundreds. For B2B, five to ten accounts with real usage are more informative than any number of individual sign-ups.
Should I pay users to test my MVP?
A small incentive for a 30-minute interview is normal and does not bias behaviour questions. Do not pay people to use the product, since paid use tells you nothing about whether they would use it unpaid.
What if users ask for features?
Note them, and ask what they were trying to do when they wanted the feature. The underlying goal is the finding. A feature requested by one user is noise. A goal that several users cannot reach is a path problem worth fixing.
How long should MVP testing last?
The first structured round takes two to four weeks. After that, testing becomes continuous: every release is measured on the same numbers and a few users are interviewed each month. An MVP is never finished testing. It graduates into a product that is tested as a habit.
Can I test an MVP in private before a public launch?
Yes, and it is often better. A closed group of recruited target users for two to four weeks finds the path problems before the public sees them. Make sure the group is strangers from the segment, not your network.