Choose one assumption before the interview
Trying to validate the whole product in one conversation makes the notes difficult to interpret. Start by writing the riskiest assumption: whether the problem exists, happens often enough, is poorly served by current alternatives, or belongs to the segment you are reaching. Each interview guide should prioritize one of these.
| Weak assumption | Testable assumption |
|---|---|
| Small businesses struggle with reporting | Operations managers manually collect data from at least 3 sources for a weekly report |
| Users want a faster app | Field staff postpone a record until the end of a shift when the current task takes longer than 2 minutes |
| People will use an AI feature | Users spend at least 2 hours a week manually producing the same output today |
7 questions for validating a product idea
- When did you last experience this problem? Ask for a recent event instead of a general opinion.
- What were you trying to do at the time? Find the context and trigger.
- What steps did you take to solve it? Look for actual behavior rather than a stated need.
- Which tools or workarounds do you use today? Your competitor is often a spreadsheet or manual process, not another app.
- What does this cost you in time, money or missed opportunity? Make the weight of the problem concrete.
- What is the hardest part of the current method? Learn which job the solution should focus on.
- Who else is involved in this process? Understand whether the user, decision-maker and budget owner are the same person.
Questions to avoid
Hypothetical and leading questions produce positive answers but weak evidence for a product decision. People struggle to predict future behavior and often support an idea simply to avoid disappointing the interviewer.
| Avoid | Ask instead |
|---|---|
| Would you use this app? | How did you do this the last time? |
| Would this feature be useful? | Where do you lose the most time in the current method? |
| Would you pay for this? | What do you spend on solving this today? |
| Do you think this is a good idea? | How many times did this problem occur last month? |
Look for evidence in behavior
A participant liking the idea is not evidence of demand. Stronger signals come from past behavior: allocating budget to the problem, building a manual workaround, trying different tools or repeatedly escalating the issue to a teammate.
- The date of the event and how often it recurs
- Current tools and workarounds
- Time, money or opportunity spent
- People involved and approval steps
- The participant's own spontaneous language
Turn notes into insights and insights into decisions
A summary alone is not enough after the interview. Separate every note into observation, interpretation and decision. 'Three participants merge the weekly report in Excel' is an observation; 'an integration is needed' is an interpretation; 'we will test a prototype that combines two data sources' is a verifiable decision.
| Layer | Example | Rule |
|---|---|---|
| Observation | 4 of 5 people enter the same data in two systems | What a participant said or demonstrated |
| Insight | Duplicate entry increases error risk and delay | A pattern that explains several observations |
| Decision | Test a single-entry synchronization prototype | Has an owner and a defined next step |
How many interviews are enough?
No fixed number is right for every study. For a first round within one user segment, 5-8 interviews are often enough to spot recurring patterns and improve the interview guide. You may be approaching saturation when new interviews stop producing new behaviors or objections. Treat different user roles as separate segments.
One interview generates an idea; a recurring behavior pattern starts to support a decision. Research strength comes less from participant count than from the right segment and concrete behavioral evidence.