Testing a SaaS MVP with real users is not the same as quality assurance. QA checks whether the software works as specified. User testing checks whether the specification itself matches what people actually need and can use. The two activities serve different purposes, and conflating them is a common source of wasted time and misleading confidence.
The core objective at this stage is learning, not selling. You are not looking for validation that your idea is brilliant. You are looking for honest signals about whether the core workflow makes sense to someone who has never seen the product before, whether the value is apparent quickly enough, and where people get stuck, confused or abandon the task.
What counts as a "real user" matters. Internal team members, friends, family and existing contacts who feel obliged to be polite are not useful test participants. A real user is someone who matches the profile of the person who would pay for the product, who has the problem you are trying to solve, and who has no prior relationship with you that would skew their feedback.
Before arranging any test sessions, you need a clear hypothesis. Not a vague hope that "people will like it", but a specific, falsifiable statement such as: "A compliance manager in a firm of 50 to 200 staff can complete a full audit workflow within 15 minutes without training, and can identify where to find the resulting report without being prompted." That level of specificity tells you exactly what to observe and what would count as a pass or a fail.
Timing is also important. Testing too early, when core flows are broken or data does not persist, wastes everyone's time and erodes trust with participants. Testing too late, after you have already committed significant budget to polishing features, means you may discover fundamental problems when changing direction is expensive. The right moment is when a user can complete the primary workflow end to end, even if the surrounding experience is rough.
Recruiting participants
Where you find participants depends on your target market. For a vertical SaaS product aimed at a specific profession, trade bodies, industry forums and LinkedIn outreach to people in relevant roles can work. For a broader tool, customer research panels and user-testing platforms are options, though you should screen carefully to ensure participants genuinely match your user profile rather than just ticking demographic boxes.
How many people you need depends on what you are testing. If you are looking for obvious usability barriers in a core workflow, five to eight participants will typically surface the major issues. If you are testing nuanced value perception across different segments, you may need more. The point is not statistical significance but pattern recognition: when three or more unrelated people hit the same wall, you have found a real problem.
Structuring a test session
A useful session follows a consistent structure. Begin by setting expectations: you are testing the product, not the person, and honest negative feedback is more helpful than polite positive feedback. Give a realistic scenario, not a product tour. Instead of saying "here is the dashboard, what do you think?", say "you have just received a new client and need to set up their account and send an onboarding email. Show me how you would do that."
Ask participants to think aloud as they work. What you are listening for is not whether they eventually succeed, but the path they take. Hesitation, backtracking, scanning the screen aimlessly and clicking the wrong thing are all data points. Note where they expect to find something that is located elsewhere, and where they use language that does not match your interface labels.
Resist the urge to help. When a participant is stuck, your instinct will be to guide them. Instead, wait. Note how long they struggle, what they try, and whether they give up. If you intervene, you have destroyed the data point for that moment. You can offer help after they have made a genuine attempt or abandoned the task, and note what it took to get them back on track.
Moderated versus unmoderated testing
Moderated sessions, where you observe in real time and can ask follow-up questions, are more valuable for early MVP testing because you can probe unexpected behaviour. Unmoderated testing, where participants complete tasks on their own and the session is recorded, can be useful for broader validation once you have already addressed the major issues found in moderated sessions. Each approach has a place, but relying solely on unmoderated testing for a first round of user feedback often means you see what people did without understanding why.
What to do with the results
After each session, write up what happened while it is fresh. Group findings into categories: critical blockers that prevent task completion, significant friction that slows people down or causes confusion, and minor irritations. Then prioritise. Not everything needs fixing before the next round of testing. Focus on the issues that prevent users from reaching the value of the product. A confusing label on a secondary setting can wait; a workflow that leads people into a dead end cannot.
Decide in advance what would trigger a fundamental change in direction versus an iteration. If most participants complete the core task but struggle with one step, that is an iteration. If most participants do not understand what the product is for or cannot see why they would use it rather than their current approach, that may indicate a problem with the value proposition itself, not just the interface.
Leading questions and confirmation bias
The most common mistake in user testing is asking questions that steer participants towards the answer you want. "Did you find that easy to use?" is a leading question. "Walk me through what you just did and tell me where it felt straightforward or confusing" is not. Similarly, interpreting ambiguous feedback positively because you are invested in the product is a risk you need to actively guard against. If a participant says "that's interesting", that is not an endorsement. Probe further.
Confusing stated intent with behaviour
What people say they will do and what they actually do are often different. A participant might say "I would definitely use this" in a test setting because the social context encourages politeness. Behavioural signals, such as whether they complete the task without prompting, how long it takes, and whether they explore beyond the minimum required steps, are more reliable indicators than verbal reassurance.
Treating all feedback as equal
One participant's offhand comment about wanting a particular feature does not carry the same weight as three participants independently failing at the same point in the workflow. Feedback from someone who closely matches your ideal customer profile matters more than feedback from someone who was a loose fit. Distinguish between requests that align with your core value proposition and requests that would pull the product in a different direction.
Testing with the wrong environment
If your SaaS product will be used in a busy office on a standard laptop, testing it in a quiet room on a large monitor gives a false picture. Replicate the real context as closely as you can. If your users will be interrupted, multitasking, or working on smaller screens, those conditions affect usability and should be part of the test.
Limitations to acknowledge
User testing an MVP has inherent limitations. The sample size is small, so you cannot draw statistical conclusions. The artificial nature of a test session, where someone is dedicating focused attention to a product they have just been introduced to, does not perfectly replicate the gradual, self-motivated adoption process of real SaaS usage. Test participants may not have the same urgency or domain knowledge as actual users who have chosen to seek out a solution. These limitations do not make testing worthless, but they mean you should treat findings as strong directional signals rather than definitive proof.
Key checks before, during and after
Before testing: confirm the core workflow is complete enough to test, write your hypothesis, prepare realistic scenarios, and ensure your recording and note-taking approach is ready. During testing: stick to your script, avoid leading, resist helping, and note both what happens and what participants say. After testing: categorise findings by severity, decide what to act on before the next round, and revisit your hypothesis to see whether it held or needs revision. Then test again with a fresh set of participants to confirm whether your changes resolved the problems you identified.