Almost every failed product traces back to the same root cause: it was built for a customer nobody had actually understood. User research is the discipline that replaces guesswork with evidence, and for a product manager it is the cheapest insurance you can buy. This is the practical sequence to run it well, from framing the question to validating a solution before you build.
Frame the decision before you talk to anyone
Write one sentence: “This research will help us decide ___.” Research with no decision attached becomes a pile of interesting quotes that nobody acts on. The decision is what keeps every question pointed and every finding useful.
If you cannot name the decision yet, that is the first thing to fix, not a reason to start interviewing.
Recruit the right five to eight people
Talk to people who genuinely fit the segment: current users, users who churned, or clear prospects. Avoid friends and colleagues who will be kind, kindness is the enemy of a true finding.
Five to eight well-chosen conversations reliably surface the dominant patterns. You do not need thirty interviews to see the theme; you need the right handful and honest listening.
Ask about behaviour, not hypotheticals
Write open questions anchored in the past: “Tell me about the last time you tried to do X.” People predict their future behaviour badly and remember their real behaviour well, so mine the memory rather than the imagination.
Kill leading questions. “Would you use a feature that…” invites a polite yes that tells you nothing. Let the user describe the problem in their own words before you mention any solution.
Interview for the problem and dig
In the call, your job is to listen for the problem, not to sell your idea. When something interesting surfaces, follow it: “Why did that matter?”, “What did you do next?”, “What made that hard?”
Let silences run. The useful answer usually arrives after the first, more rehearsed one, give it room to appear.
Separate the need from the solution
As you review notes, split what you heard into three buckets: the job the user is trying to get done, the pains in their current way of doing it, and the outcome they actually want.
Users will often hand you a solution (“you should add a button here”). Your skill is recovering the underlying need behind it, the need is stable, the proposed solution is just their first guess.
Synthesise into three evidenced problems
Cluster the notes, an affinity map on sticky notes or a simple spreadsheet is plenty, and name the top three recurring problems. Attach a direct user quote to each one.
If you cannot attach evidence to a problem, it is an opinion, not a finding. Be ruthless about that line; it is what makes your research trustworthy to engineers and executives alike.
Turn insight into a decision, then validate
Convert the top problem into something buildable: a prioritised opportunity, a crisp problem statement, or a one-page spec, and state the metric it should move. This artefact is the proof that the research changed what you did.
Before a full build, test the chosen direction cheaply, a concept, a prototype, or a fake-door, with a few of the same users. Confirming direction before a build cycle is the entire return on the research.
Do this today
- Write the one decision this research will inform
- Recruit 5-8 real users in the segment, not friends
- Draft open, behaviour-based, non-leading questions
- Interview: listen for the problem, dig with “why” and “tell me about the last time…”
- Split findings into jobs, pains and desired outcomes
- Name the top 3 problems, each backed by a real quote
- Turn the top problem into a spec + the metric it should move
- Validate the solution cheaply before you build
Turn advice into a career transformation.
Guides get you oriented. Real work experience and verifiable proof get you hired. That is what UstackSchool is built for.