MVP User Testing: Getting Real Feedback From Real Users
Most founders ask users what they think of their MVP. The right question is what users do. User testing is not a survey — it is structured observation of real users attempting to complete real tasks in your product. The five-session framework that generates actionable insight in a week.
What Users Say vs What Users Do
MVP user testing is the practice of observing real target users attempting to complete specific tasks in your product without guidance or prompting — watching where they get stuck, what they misunderstand, what they skip over, and what delights them — rather than asking them to describe their experience after the fact. The critical distinction is between what users say (unreliable, biased by social pressure and post-hoc rationalisations) and what users do (reliable, revealing the actual friction points in your product). Five user testing sessions with target users reveal approximately 85% of critical usability issues — a threshold that typically cannot be reached with 50 survey responses.
The most common mistake founders make in user testing is leading the witness: explaining features before the user encounters them, clarifying confusion before the user works through it, and defending design decisions when users criticise them. Every intervention by the founder during a user testing session contaminates the data. The discipline of user testing is to observe, note, and resist the urge to help.
How SA Recommends Founders Structure Their First User Tests
Recruit the right participants
User testing is only valuable if the participants match your target user profile. A B2B SaaS for HR managers tested with friends who are software engineers produces misleading results. Recruit from your waiting list, from communities where your target users are active, or through a screener survey promoted via targeted social posts. Five confirmed sessions with accurate target users are worth more than twenty sessions with convenient but wrong participants.
Define the core task scenario
Define the specific task scenario the participant will attempt: a realistic, contextualised situation that requires them to use the core product flow. Not ‘explore the product and tell me what you think’ — but ‘imagine you have just received a new client brief. Please use the product to set up the project, invite the client to review the proposal, and send them the first progress update.’ The task should mirror a real use case from start to finish.
Run the session: observe without intervening
Record the session with the participant’s consent. Ask the participant to think aloud — to narrate what they are looking for, what they expect to happen, and what surprises them. Your role is to observe, take notes on where they hesitate, where they click incorrectly, and where they express confusion. Do not answer questions about how the product works. If they ask, respond with ‘what would you expect to happen?’ Every moment of confusion is information.
Debrief with five key questions
After the task, ask: (1) What was the most confusing part of that experience? (2) Was there anything you expected to find that you couldn’t locate? (3) On a scale of 1-10, how confident are you that the product did what you wanted? (4) What would need to be different for you to use this regularly? (5) If you were recommending this to a colleague, how would you describe what it does in one sentence?
Synthesise across sessions and prioritise fixes
After five sessions, identify recurring patterns — issues that appeared in three or more sessions are structural problems that will affect most users. Categorise findings by severity: blockers (user could not complete the core task), friction points (completed with significant hesitation), and minor issues (noticed but did not impede progress). Fix blockers before any other development work.
🔗 Related reading on sasolutionspk.com
Using AI to Conduct User Research and Analyse Feedback
How SA uses AI tools to process user testing recordings and feedback at scale.
The Right Testing Focus at Pre-Build, Beta, and Post-Launch
Pre-build: prototype testing
Test with a Figma prototype or clickable wireframe before any development begins. Identify whether the core navigation and information architecture makes sense to users. Changes at this stage cost zero development time — a label change in Figma takes 30 seconds; the same change in a live Bubble.io app takes 10 minutes minimum and may have downstream implications.
Beta launch: flow testing
Test with real users on the live product before public launch. Focus on whether users can complete the core task scenario end-to-end without assistance. This is the stage where blocker issues are found and fixed before they affect a larger user base. Aim for 5-8 sessions at this stage.
Post-launch: retention testing
After 30 days of public availability, test with users who signed up but have not returned after their first session. Understanding why early users did not come back generates the most important product development signal: the gap between the value users expected and the value they experienced.
Q: How do I find users willing to participate in testing for an MVP that is not yet public?
The three most reliable sources are: (1) your MVP landing page waiting list — people who signed up are already interested and the most motivated to help shape the product; (2) relevant online communities where you have been active — members who know your contributions are more likely to agree to a testing session; and (3) LinkedIn outreach to connections who match your target user profile, with a personalised note explaining that you are building something relevant to their role. SA’s experience is that a personal, specific outreach message converts at 15-30% for user testing recruitment.
Q: What if users are too polite to say what is really wrong with my MVP?
Open every session by explicitly telling the participant that you are testing the product, not testing them, and that negative feedback is more useful than positive feedback. The secondary mitigation is observation over questioning — watching what users do is much harder to misrepresent than asking them what they think. A user who says ‘this is really intuitive’ but takes 3 minutes to find the primary navigation button is giving you more useful data through their behaviour than their words.
Q: How many user testing sessions should I run before deciding whether to pivot or continue?
SA recommends a minimum of 5 sessions before making any major product direction decision, and no more than 15 sessions before acting on the findings. Five sessions reveal the most common structural issues; sessions beyond 15 produce diminishing new insight and delay the iteration cycle that actually improves the product. The principle is: test, fix the blockers, test again.
Ready to Build Your MVP?
SA Solutions builds MVPs in weeks using Bubble.io. Start with a free audit or scope your build in 48 hours with a Discovery Sprint.
