Guide
User Research for Early Stage
Five research methods — when to use each, what questions to ask, and how to turn raw conversations into product decisions. Written for founders and PMs who do not have a dedicated research team.
Separate discovery from validation
Discovery finds unknown problems. Validation tests known hypotheses. Using the wrong method for the wrong phase produces misleading data.
Behavior over opinion
What users do is more reliable than what they say they would do. Design your research to observe behavior where possible, not to collect predictions.
Five users, one week
You do not need 50 interviews to find a pattern. Five interviews conducted and synthesized in a week produces faster, more actionable insight than a month-long research project.
Research is a team sport
The best research outcomes come when engineers and designers observe sessions directly, not just read a report. Bring the team into the room whenever possible.
User Interviews
Use when
Pre-build, pre-PMF, or when you have a metric that moved but do not understand why
Not for
Testing UI, validating feature design, or getting statistically significant data
How to do it well
Recruit the right person
Someone who has the problem you are investigating, not someone who is willing to talk. The best recruits come from your existing users, churned users, or the communities where your ICP congregates.
Ask about the past, not the hypothetical
The Mom Test principle: ask about specific past behavior, not what they would do in the future. 'Tell me about the last time you dealt with this' produces truth. 'Would you use a product that...' produces politeness.
Follow the emotion
When someone uses a word like 'frustrating,' 'annoying,' or 'finally' — slow down and go deeper. The emotion is the signal. The feature request is the surface.
Shut up after you ask a question
Silence feels uncomfortable. Resist the urge to fill it. The best insights come from the pause after the first answer, not the first answer itself.
When you have enough signal
You have enough signal when you hear the same problem described three times by three different people without prompting.
Most common mistake
Asking 'would you use this?' or 'do you think this is a good idea?' Both produce optimistic bias. People want to be helpful and will say yes to almost anything you show them.
Surveys
Use when
You have a hypothesis you want to validate at scale, or you need quantitative signal to complement qualitative findings
Not for
Discovering unknown problems, understanding WHY something is happening, or getting actionable product direction
How to do it well
Start with one open question
The most valuable survey question is often: 'What is the one thing you wish this product did that it currently does not?' The pattern across answers is more valuable than any closed question you write.
Keep it under 5 minutes
Every additional question reduces completion rate and increases satisficing — the tendency to give fast, low-effort answers. Pick the five most important questions and cut the rest.
Never ask about intent
'Would you pay for X?' consistently overestimates willingness to pay. Behavior questions ('How often do you currently use Y?') are more reliable than intent questions.
Segment before you analyze
Survey results averaged across all users hide the insight. Always cut the data by user segment, tenure, or behavior before drawing conclusions.
When you have enough signal
Surveys produce signal when they confirm or contradict a hypothesis you already formed from interviews. On their own, they rarely surface new hypotheses.
Most common mistake
Running a survey before doing interviews. Surveys are for validation, not discovery. If you do not know what to ask, you will get answers that are not useful.
Usability Testing
Use when
You have a prototype or live product and want to know whether users can complete a specific task without friction
Not for
Validating whether users want the product, understanding the problem space, or measuring sentiment
How to do it well
Give a task, not instructions
Say 'Imagine you want to invite a colleague to your workspace. Show me how you would do that.' Do not say 'Click the Invite button.' The task should mirror a real goal, not a UI step.
Ask them to think aloud
Encourage participants to narrate their thought process as they work through the task. The narration surfaces confusion that behavior alone would not show.
Note where they pause
A pause followed by a scan of the screen means the user lost orientation. That specific moment is where the UI has failed. Count pauses per task as your usability metric.
Do not help
When a user gets stuck, resist the urge to guide them. The difficulty they experience is the data. Helping them defeats the purpose of the test.
When you have enough signal
5 users are enough to surface most major usability issues. If the same friction point appears in 3 of 5 sessions, it is a real problem worth fixing before the next launch.
Most common mistake
Running usability testing on a problem you have not validated exists. If nobody wants the product, smooth UI will not fix it. Validate desirability before testing usability.
Behavioral Analytics
Use when
You have a product in market and want to understand what users are actually doing versus what they say they do
Not for
Understanding why users do what they do, discovering unknown problems, or replacing qualitative research
How to do it well
Instrument before you ship
Every feature should launch with events already tracked. Adding analytics after the fact means you are always analyzing the past without the data you needed.
Start with funnels
Map the critical path from sign-up to activation. Track completion at each step. The step with the highest drop-off is the first thing to investigate.
Build cohort views
Compare the behavior of users who retained at Day 30 with those who churned. The actions taken in the first session that differ between these groups are your activation signal.
Combine with qualitative
Analytics tells you what happened. It cannot tell you why. When you find a significant drop-off or behavior pattern, follow it with 5 user interviews to understand the cause.
When you have enough signal
A useful analytics insight is one that changes what you build next. If the data is interesting but not actionable, you are looking at the wrong metric.
Most common mistake
Tracking everything and analyzing nothing. A Mixpanel dashboard with 200 events and no clear question being answered produces noise, not insight. Start with the question, then track what answers it.
Five-Act Interview
Use when
You want to understand the full context of a user's experience — their setup, their workflow, their pain, and what they have already tried
Not for
Quick validation, large sample sizes, or situations where you need quantitative data
How to do it well
Act 1: Welcome and context (5 min)
Set expectations. Explain this is a research session, not a sales call. Ask them to narrate their thinking as they go.
Act 2: Open questions about their world (10 min)
Ask about their role, their day, the workflows that are relevant to your product space. Listen for the language they use, not just the content.
Act 3: Introduction to the product (15 min)
Show the prototype or live product. Give them a task. Watch and listen. Do not guide.
Act 4: Deep dive questions (10 min)
Return to the moments where they hesitated, expressed confusion, or said something interesting. Ask them to explain what they were thinking.
Act 5: Debrief (5 min)
Ask what they would tell a colleague about what they just saw. Ask what would make them come back. Ask what you should have asked but did not.
When you have enough signal
The five-act format produces the richest qualitative data of any research method. The tradeoff is that it takes time and requires a skilled facilitator. Use it sparingly for the highest-stakes product questions.
Most common mistake
Running the five-act with a sample that does not match your ICP. The depth of insight only converts to product direction if the participant represents the customer you are actually trying to serve.
Template
User Interview Guide
Framework
Five Whys for Root Cause
Article
First 10 customers without a sales team
Have a research approach worth sharing?
The most useful research insights come from practitioners who have adapted methods to real constraints. Expert Perspectives is where that kind of first-hand thinking gets published.