Product strategy
People agreeing with the idea isn't evidence they'll change their behaviour.
The short answer
Useful product research tests a specific uncertainty with evidence from behaviour, not general enthusiasm. Start with the decision the research must inform, recruit people who face the problem, observe how they handle it now, compare the alternatives they already use and turn the findings into changes to scope or sequence.
A friendly interview can make a weak idea sound inevitable. People want to be helpful, imagined behaviour is easy to overstate and the person asking the question usually wants the answer to be yes. Research becomes useful when it is designed to disprove an assumption and connected to a decision the team is prepared to change.
Write the decision before you write the interview guide.
Research starts with a choice the team cannot make responsibly yet. Which user should the first release serve? Is the slow part the work itself or the handoff around it? Does the buyer need a new product, a clearer service or a connection between tools they already have? A broad goal such as understand the market gives you interesting notes and no decision.
Turn the choice into assumptions. Name what you believe about the user, the problem, the current alternative, the buying decision and the conditions that would make the idea fail. Rank those assumptions by how damaging it would be to learn they are wrong after the build.
The first research activity should attack the riskiest assumption. It does not need to describe the whole market. It needs to reduce the uncertainty that changes what you do next.
Research the work people do now, including the workaround.
People are better at showing you yesterday than predicting next year. Ask for the last time the problem happened. Follow the documents, messages, approvals and delays. Notice where they leave the official tool, who they call when the process breaks and what they have already paid to avoid.
The workaround is evidence of both need and constraint. A spreadsheet may look primitive while carrying ten years of exceptions the proposed product has not considered. A coordinator may look like avoidable manual effort while actually protecting the business from incomplete information. Research should make that role visible before a feature promises to remove it.
1. Choose the uncertain decision
State what will change depending on the answer. If no finding could alter the first release, the research question is too broad or the decision has already been made.
2. Recruit for behaviour
Find people who recently faced the problem, own its consequences or decide what replaces the current approach. Job titles alone are weak criteria. Recent experience gives them something concrete to show rather than something hypothetical to imagine.
3. Ask for the last real example
Walk through what triggered the work, what happened next, where information moved and where somebody intervened. Avoid asking whether they would use the proposed feature until you understand what they already do.
4. Inspect the alternatives
Look at direct competitors, internal workarounds, outsourced labour and doing nothing. The strongest competitor is often a tolerated process with no purchasing event, not another software product.
5. Turn patterns into product decisions
Separate repeated evidence from memorable anecdotes. Record which assumption each finding supports or weakens, what changes in scope and what still needs to be tested through use rather than another conversation.
Use the lightest method that can change the decision.
More research is not automatically safer. The method should match the uncertainty. Interviews explain context and language. Observation exposes the real sequence and the hidden work. A prototype shows whether a person can complete a task. Market analysis shows how the category is framed and where buyers already spend. None of them answers every question.
| Uncertainty | Useful method | What it cannot prove alone |
|---|---|---|
| How the work happens today | Context interview and observation | That somebody will adopt a new workflow |
| Whether the proposed flow is understandable | Task-based prototype test | That the underlying problem is important enough to buy |
| How buyers describe the category | Sales-call review and market analysis | That a new position will convert without testing it |
| Which problem deserves the first release | Pattern synthesis across interviews, operations and usage | The exact demand for a product that does not exist yet |
| Whether behaviour changed after release | Product usage and follow-up interviews | Why the change happened without qualitative context |
The finding has to change the plan or it is just a report.
We organise findings around decisions, not around a transcript summary. Each meaningful pattern points to a scope change, a sequence change, a positioning change, a test for later or a reason to stop. Contradictory evidence stays visible rather than being averaged into a vague theme.
The team responsible for designing and building the product reads the source material. Important context is not handed across as three bullets after the research is finished. That keeps a technical constraint from being mistaken for user resistance, and keeps a familiar implementation idea from being mistaken for a user need.
We also say what the research did not prove. Five thoughtful conversations can reveal a workflow and sharpen a prototype. They cannot establish a market size or guarantee adoption. Confidence should grow in proportion to the evidence, not to the polish of the deck.
Stop interviewing when the next uncertainty needs a real product.
Research reaches a natural limit. Once the team understands the current behaviour, the important exceptions and the first task worth improving, another interview often produces familiar language rather than a new decision. The next useful evidence may be somebody using a narrow release in real work.
Write down what must be learned after launch and how the product will expose it. That may mean an event, an adoption threshold, a manual review or a follow-up with the first group of users. A good research phase does not pretend uncertainty is gone. It decides which uncertainty is cheap enough to carry into the release.
Worth knowing before you start
Ask about the last real occurrence of the problem before asking for opinions about a proposed feature.
Recruit the person who handles the exception, not only the person who owns the budget. They often see different failures.
Keep a decision log beside the research notes. If a finding changes nothing, say why it did not earn a change.
Separate evidence about the problem from evidence about the interface. A usable screen does not prove the task matters, and a real problem does not prove your proposed screen works.
Further reading
Common questions
There is no responsible fixed number for every product. Start with enough recent, relevant experiences to expose repeated patterns and meaningful differences, then stop when additional conversations no longer change the decision. Recruitment quality and the specificity of the question matter more than hitting a round count.
Usually both, for different reasons. Current customers can show the real work, constraints and trust you already have. Prospective users reveal whether those patterns exist outside the current relationship and how the category is understood before anyone knows your proposed answer.
Not by themselves. People can describe pain and say a product sounds useful without changing a budget or behaviour. Treat payment intent as a separate uncertainty. Look for existing spend, authority to buy, an active replacement decision or a real commitment attached to the next test.
You should receive the assumptions tested, who was included, the evidence patterns, contradictions, source notes, the decisions that changed and the questions that remain. For product work, the useful output also shows how the findings alter the first-release scope, flows or sequence.
Industry experience gives you better questions and helps you recognise exceptions. It does not remove the need to check how this buyer frames the problem, what they already use and why they have tolerated it. Familiarity can create blind spots as easily as it creates insight.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.