We’ve seen this happen so many times.
A team does a bunch of user interviews, takes great notes, and makes a big board of insights.
But then? They just build exactly what they planned from the start.
The issue is that the research has no clear goal. People look for answers without knowing what decision they're actually trying to make. They collect data but don't decide ahead of time what would cause them to change their plans. Research shouldn't just be a step you check off at the beginning, but a tool to help you make better choices. If it doesn't lead to a real decision, it’s a waste of time.
This playbook covers the whole process: knowing when you actually need research, how to do it right, and, most importantly, how to use what you learn to change things for the better.
First, do you even need research right now?
Before jumping into any research methodology, there's a more fundamental question that most teams skip: should we be doing research at all at this point?
Not every moment on an initiative calls for research. It’s valuable for checking if a problem is real or if a solution works before you commit to building it. But if you already have a clear, proven path, stopping to research is just a waste of time.
We see three situations where research is needed:
1. You're about to make a high-stakes decision with low confidence.
Some examples:
- Choosing between two problems to solve
- Deciding whether to invest a full quarter in a direction
- Commit significant resources into a new initiative
If the cost of being wrong is high and your confidence is low, that's the signal.
2. You realise you're operating on untested beliefs. Someone on the team says "users want X" or "the market is moving toward Y", and when you ask how they know, the answer is intuition, a single anecdote, or "everyone knows that." Those are assumptions pretending to be facts and deserve further investigation.
3. You're stuck and don't know why. The team doesn't share a common understanding of the problem, and research is the fastest way to build one, even if it feels like moving backwards at first.
On the other hand, research is not needed when the decision is already made (be honest about this), when the cost of being wrong is low enough to just ship and learn (as long as you put things in place to really learn), or when you're doing it "to be sure" without a specific question in mind.
💡 The trigger question: "What decision will this research inform, and what would we do differently depending on the outcome?" If you can't answer both parts, you're not ready to research.
Let’s dig in.
Step 1: Name the decision before you name the method
Once you've established that research is needed, resist the urge to jump to a method. Before you think about interviews, surveys, or analytics, answer one question: what specific decision will this research inform?
Most teams jump to "we should do some user research" without specifying what they'll decide differently based on what they learn, risking producing interesting findings that change nothing.
Good decisions to name: go/no-go on an initiative, reframing the problem, reprioritising the backlog, choosing between solution approaches, and validating whether a problem is worth solving at all.
A useful test: what would we do differently depending on the outcome? If the answer is "nothing, we'd build it anyway," you don't need research; you need honesty about the fact that the decision is already made.
What if your hands are tied?
This playbook assumes your organisation will act on what it learns. In reality, many PMs have limited power to influence decisions, and research findings often get shelved. That is more common than most product literature admits. If that is your context, the goal of research shifts: rather than trying to change one decision, use research to build an evidence base over time, sharing findings with stakeholders gradually until the weight of it becomes harder to ignore.
For example, frame a key pattern as a business risk in a steering committee, not as a product recommendation in a backlog review. Create the conditions where the next decision is shaped by what you have collectively learned. Start with what you can influence.
Step 2: Surface your riskiest assumptions
Every initiative rests on assumptions: beliefs that may or may not be true.
The discipline of assumption identification starts with one question: What must be true for this problem or solution to succeed?
We've written extensively about how to do this well, including the assumption mapping technique that helps you surface, categorise, and prioritise these beliefs. Rather than repeating the methodology here, we suggest you take a look at our detailed guide to assumption mapping in product discovery. What matters for this playbook is what you do after you've surfaced your assumptions.
A quick example of vague vs. sharp assumptions:
- Vague: "Users want self-service."
- Sharp: "First-time users will complete the onboarding wizard without guidance at least 70% of the time if we remove jargon from Step 3."
Notice the difference? The sharp version is specific enough that you could actually test it.
💡 Reflection prompt for your team: For each assumption you've named, ask: Could I say this more specifically? What would change about how I'd test it if I got it sharper?
One big thing teams often forget to ask is: Do we actually have the power to change things based on what we find?
If the answer is no, don't stop. Just change how you define success for now. Even if you can’t change a decision right away, good research creates a record that helps shift how your stakeholders think. It might not change what you do tomorrow, but it will definitely impact the next big choice.
Step 3: Prioritise by knowledge and importance
Not all assumptions deserve research. You need a filter.
We use two dimensions: how much do you know (is this well-understood or genuinely unknown?) and how much does it matter (what's the impact if this assumption is false?).
The "Investigate" quadrant is your research priority list. These are the assumptions where you don't know enough, and the cost of being wrong is high.
A common mistake: teams research what's easy to research rather than what's important to research. The comfortable assumptions get tested; the uncomfortable ones get avoided. That's exactly backwards, and this is where you should add the most value as a Product Manager.
Step 4: Translate your top assumption into a research plan
Now that you've found your biggest risk, it's time to build a plan around it.
You just need three simple pieces:
- Research goal: What decision or risk are we addressing? This links directly back to Step 1. Example: "We need to decide whether to invest in self-service onboarding or guided onboarding."
- Research questions: What do you actually need to find out? Instead of asking "Do they like us?", ask "Where exactly are they getting stuck in the sign-up process?”
- Hypothesis: Make a specific prediction. Try this format: "We believe [this group of people] struggles with [this problem] at least [this often]. For example: "We believe that first-time users abandon the configuration wizard before completing it at least 40% of the time, primarily because they don't understand the terminology used in step 3."
Writing this down before you start is key. It stops you from only seeing what you want to see and forces you to be honest about whether your idea is actually working or not.
Step 5: Pick the right research method for your situation
The real question isn't "qualitative or quantitative?" It's: “What are we actually confused about, and what can we realistically do right now?”
Start with your uncertainty type.
- If you are exploring unknowns, you do not yet know what you do not know. Qualitative methods like interviews, observation, and diary studies work better here. They are flexible, surface surprises, and do not require you to have all the right questions upfront.
- If you are measuring something you already understand, qualitative methods like surveys, analytics, and A/B tests work better. But they only work if you already know what to measure.
- If you are facing both, understand first, then size. Use qualitative research to find the patterns, then use quantitative to measure how widespread they are.
Then look at your context.
Not every team can run quantitative research. A small user base, no analytics setup, limited access to users in B2B, or an early-stage product all make it harder or impossible. That is not a failure. It just means qualitative methods become your primary tool, and you measure impact after the fact instead.
💡 Reflection prompt if you're qualitative-only. Five interviews don't prove a pattern is universal. Watch for:
- selection bias: reachable users may differ from typical users
- social desirability bias: interviewees tell you what they think you want to hear
- confirmation bias in analysis: noticing supporting evidence while discounting contradicting signals
- anecdote elevation: one vivid story outweighing three quieter contradictions).
Before you call synthesis done, have someone on the team specifically look for evidence that disproves your idea. Finally, instead of saying you "proved" something, say "our findings suggest." It’s more honest and keeps you open to new info.
Step 6: Figure out who you need to talk to
Not all users are equally valuable research subjects for a given question. Specify, for each research question, which persona or user type you're targeting.
- Who actually experiences the problem? Not who reports it, who lives with it daily.
- Who feels the pain vs. who just complains? Sometimes the loudest voices aren't the most affected.
- Who has adapted so much they no longer notice? These users have the richest workaround stories and often reveal the real depth of a problem.
If you work in B2B, you usually have to go through Sales or Customer Success to reach users. Three moves make that conversation more productive.
- Brief the gatekeepers on who you actually need. Left to their own judgment, they will send you their happiest customers. Those users have adapted to your product and forgotten what the original pain felt like. Be specific: "users who churned in the last six months," "admins managing more than 50 seats," "customers who tried the feature and stopped." The more precise your target profile, the less likely you are to end up with a panel that tells you everything is fine.
- Agree on rules of engagement upfront. Research is not a sales call. No upsell, no roadmap commitments, findings shared back to the account team. If this is not explicit, interviews drift. Putting these rules in writing, even a short email, protects both the research and the customer relationship.
- Treat the gatekeepers as a research source. Account managers and customer success teams absorb enormous amounts of signal that never reach product. Before you talk to a single user, ask them what complaints recur, where they firefight, what patterns they see. They are often the most underused panel in the building.
Step 7: Know when to stop
One of the hardest judgements in product research: when to stop. We use four criteria that usually go hand in hand:
- Are we hearing the same patterns repeatedly? If three consecutive interviews produce no new themes, you're approaching saturation.
- Has the key assumption been confirmed or disproven? Confirmation is not just "participants said they have this problem." It means your hypothesis threshold has been met: e.g., the friction point you predicted appears in more than 70% of sessions. Disconfirmation is equally specific: your hypothesis doesn't hold, or a different, more critical pattern has emerged consistently instead.
- Would more research change the decision? A practical way to test this: ask the team "if the next three interviews all say the same thing as the last one, will we do anything differently?" If the answer is no, stop. The direction is clear regardless of additional data.
- Is the cost of more research greater than the marginal learning? Time spent researching is time not spent building. When patterns are stabilising, the incremental insight per interview decreases. At some point the trade-off flips, the right move is to act on what you know and instrument for learning in production.
Just remember: for qualitative research to be reliable, you should aim for at least five similar occurrences before you trust the pattern.
Step 8: Interpret results through your assumptions
You've collected data. Now comes the step that separates productive research from busywork. Four questions to ask your team:
- What surprised us? Surprises highlight blind spots. They reveal assumptions you didn't even know you were making. Pay close attention to them; they often contain the most valuable insights.
- What contradicted our expectations? Contradictions are uncomfortable, which is exactly why they're valuable. If your hypothesis was wrong, that's not a failure; it's the research doing its job.
- What does it mean for our key assumptions? Go back to the assumptions you identified in Step 2. For each one: confirmed, disproven, or still uncertain? Be specific. "We learned a lot" is not an interpretation.
- What new questions emerged? Research rarely closes every door. It usually opens new ones. Capture these because they feed your next research cycle.
Step 9: Close the loop, rewrite what changed, and share it
Most teams skip this step, but it’s where your work actually pays off. Don’t just summarize what happened, but use it to rewrite your plans. Go back to your project docs and update:
- Problem statement: has the problem changed shape? Is it bigger, smaller, or different than you thought?
- Target user: are you solving for the right people?
- Prioritised assumptions: which have been resolved? Which new ones appeared?
- Success metrics: do your metrics still measure the right thing?
- Research backlog: what should you investigate next?
If your research was good, something should change. If nothing changes, either the research confirms your direction (great, document that!) or you're not being honest about what you learned.
Share what you learned beyond your team
Research findings belong to the whole organisation, not just the product team.
When you update your problem statement or surface a key insight, share it with the people who need to know: commercial leads, engineering, adjacent product lines, leadership. How you share matters as much as what you share. Pre-align with key stakeholders before broad circulation and choose the right venue for the right audience.
Done well, this builds trust, creates a feedback loop where stakeholders start bringing you information in return, and turns research into an organisational habit rather than a product-team ritual.
When research surfaces a strategic problem
Sometimes closing the loop reveals that the strategy, not just the tactic, needs to change. Do not bury it. If your findings show you are solving the wrong problem entirely, escalate it. That is how research drives real systemic change, not just incremental product improvements.
Common pitfalls to watch for
If you run this tomorrow
Pick just one project your team is working on right now and be honest with yourself:
Do we really need more research, or have we already made up our minds? If the decision is already made, how sure are you that it’s actually going to work?
If you decide research is needed, name the exact choice it will help you make. Then, list three things that have to be true for this project to be a success. Pick the one that feels the riskiest and write a simple prediction (a hypothesis) for it. That’s your first research loop.
You don’t need to change your whole process overnight. Just try this one loop. You’ll see the difference between just "doing research" and using research to actually guide your choices.
For team leads and managers: Your job is to make this way of thinking a habit. Coach your team to identify the decision they’re facing before they start looking for answers. Help them spot their assumptions early and make sure they share what they learn with the rest of the company.
Key takeaways
1. Not every moment on an initiative calls for research. The trigger is a high-stakes decision with low confidence, untested beliefs driving the direction, or a team stuck without shared understanding.
2. Every research activity should trace back to a specific decision. If you can't name the decision and what you'd do differently, don't start the research.
3. Assumptions are beliefs that must be true for your initiative to succeed. Prioritise them by how much you know and how much it matters if you're wrong.
4. A strong hypothesis is falsifiable. "We believe that [user] experiences [problem] at least [frequency/severity]."
5. Match the method to the uncertainty and to what's feasible. If you're exploring unknowns, qualitative methods are better. If you want to size a problem, go for the quantitative methods. When facing mixed uncertainty: understand first, then size.
6. Research creates value when you share it. Go back and rewrite your problem statement, target user, and priorities based on what you learned. Then share your findings with the stakeholders who need to know, in the right order and the right format. A discovery that stays in your Notion page hasn't done its full job.
Building a research practice takes more than one playbook. If your team needs hands-on guidance to move from ad hoc research to a sustainable discovery habit, dualoop runs discovery coaching and training programmes designed for exactly that, from assumption-mapping workshops to full research capability building.
