Product Discovery & User Research

The Problem

Most product failures are discovery failures

The CB Insights post-mortem database shows that 42% of startups fail because there was no market need. Not poor execution. Wrong problem. Product discovery exists to close this gap: understand the problem deeply before committing to a solution.

Build-first approach

PM writes specs based on stakeholder requests
Team builds for 3 months without user input
Launch reveals users wanted something different
Pivots require throwing away completed work
Discovery happens after launch, expensively

The team was busy. The product was wrong. The cost was months of wasted engineering.

Discovery-first approach

PM interviews 10 users before writing a spec
Hypotheses tested with prototypes in week 2
Launch validates assumptions made with real data
Pivots happen on paper, not in production code
Engineering effort is applied to validated problems

The team moved slower initially. The product was right. The cost of learning was interviews and prototypes.

The Process

How discovery works

Product discovery is a continuous process, not a phase that ends before development begins. Teresa Torres's "Continuous Discovery Habits" framework suggests weekly touchpoints with users, not quarterly research sprints.

01

Define the problem space

Start with the Opportunity Space: what outcomes does the business need? What outcomes do users need? Where do these intersect? Use the Opportunity Solution Tree (OST) to map the problem space before jumping to solutions. A well-defined problem already contains most of the solution.

02

Recruit and interview users

5–8 interviews are enough to identify recurring themes (saturation point). Recruit participants who match your target persona, not colleagues, friends, or the most vocal users. Focus interviews on behaviour and context ("tell me about the last time you…"), not on opinions about your solution ("would you use a feature that…").

03

Synthesise patterns into insights

An observation is "3 users mentioned switching between two apps." An insight is "users need a unified workflow because context-switching breaks their concentration during time-sensitive tasks." Insights are generalisable, actionable, and grounded in evidence; they drive decisions, not just add colour.

04

Generate and prioritise hypotheses

From the insights, generate multiple solution hypotheses, not one. For each hypothesis, write a testable assumption: "We believe [user type] will [do/feel this] because [insight]. We'll know this is true when [measurable outcome]." Prioritise by potential impact × confidence × effort to test.

05

Test with the cheapest possible artefact

The goal is to invalidate assumptions cheaply. A paper prototype takes 2 hours; a coded feature takes 2 weeks. Use the minimum fidelity needed to generate a decision. Landing pages test demand. Clickable prototypes test usability. Wizard-of-Oz tests test feasibility. Build only when a hypothesis survives enough testing.

User Interviews

How to run interviews that actually surface truth

Bad interviews confirm what the team already believes. Good interviews reveal what the team didn't know it didn't know. The difference is almost entirely in the questions.

Before the interview

Prepare, but stay flexible. Write a discussion guide with 5–8 open questions, ordered from broad (tell me about your workflow) to specific (what happens when X fails). Share no brief in advance; you want unprimed responses. Record with consent. Have a note-taker present so the interviewer can focus on listening, not transcribing.

During the interview

Listen more than you speak. Ask about specific past behaviour, not hypothetical future behaviour. "Would you use this?" tells you nothing. "Walk me through the last time you tried to solve this problem" tells you everything. Follow threads: when something interesting comes up, ask "tell me more about that." Silence is productive. Don't fill it.

After the interview

Debrief immediately, synthesise across sessions. Write a 3-bullet debrief within 30 minutes of each interview: the most surprising thing, the most common thing, and what you'd test next. After all interviews, affinity map the observations, clustering related themes and elevating clusters into insights. Avoid interpretation until you have at least 5 sessions.

User Models

Personas and Empathy Maps

Personas and empathy maps are communication tools; they make research findings sticky and actionable for teams that didn't conduct the research themselves. The danger is creating them from assumption rather than evidence.

Evidence-based personas

A persona is a composite of real users, not an invented character. It should include: demographics (relevant ones only), primary goals, key frustrations, current tools and workflows, and a quote that captures their mindset. Personas built from interviews drive decisions; personas built from assumptions collect dust.

Empathy Map

Maps what a user thinks, feels, says, and does, across four quadrants. The power is in the gaps: what they say ("this is fine") vs. what they feel (frustrated but polite). Empathy maps are built collaboratively in workshops using sticky notes; the process of building them is as valuable as the artefact.

Customer Journey Map

Plots the user's experience across all touchpoints, from awareness through purchase through advocacy. Each stage shows what the user is doing, thinking, and feeling, plus their pain points and opportunities. Journey maps reveal the moments where experience breaks down and where intervention has the most leverage.

JTBD

Jobs-to-be-Done: a different way to see users

Jobs-to-be-Done (JTBD), developed by Clayton Christensen, reframes user research from "who is the user?" to "what job is the user hiring this product to do?" It explains why people switch products, what makes them loyal, and where real competition comes from.

The classic example: "People don't want a quarter-inch drill. They want a quarter-inch hole." And often they don't want the hole either; they want a shelf on the wall. And they don't want the shelf; they want their books organised. JTBD asks: what's the outcome the user is ultimately trying to achieve?

Functional jobs

The practical task to be completed. The surface-level job: "Send money to my family in another country quickly." "Find a reliable plumber in my area before Saturday." "Create a professional invoice without an accounting background." Functional jobs define the minimum viable scope of a solution.

Emotional jobs

How the user wants to feel. The same user who hires Airbnb for "a place to sleep" is also hiring it for "feeling like a local" and "not feeling like a tourist in a hotel." Emotional jobs drive differentiation: two products can fulfil the same functional job while failing completely at the emotional one.

Social jobs

How the user wants to be perceived. Using a premium product signals status. Using a sustainable brand signals values. Using the "industry-standard" tool signals professionalism. Social jobs explain why "good enough" products get displaced by more expensive ones with equivalent functionality: the social signal is the product.

Validation

Validating hypotheses before building

Validation is the discipline of being wrong cheaply. Every hypothesis has an assumption underneath it, and assumptions can be tested without code, without design, and often without even telling the user what you're building.

Qualitative validation

5-minute concept tests with paper prototypes
Fake door tests (button that doesn't exist yet)
Wizard-of-Oz: human performs the "AI" manually
Concierge MVP: manually deliver the service first
Stakeholder interviews to stress-test assumptions

Fast, cheap, directional. Tells you if you're solving the right problem. Low sample size, not statistically representative.

Quantitative validation

Landing page with waitlist sign-up (demand signal)
A/B test of value propositions on homepage
Smoke test: paid ad to gauge click-through rates
Beta cohort tracking (activation, retention)
Survey to size the target segment

Slower, requires more setup, statistically meaningful. Tells you how many people have the problem, not just whether it exists.

Pitfalls

Discovery mistakes that lead to building the wrong thing

Watch out for these

Asking about hypothetical future behaviour: "Would you use a feature that…?" always gets a "yes" from polite users who don't want to hurt your feelings. Past behaviour is the only reliable predictor of future behaviour. Ask what they've done, not what they'd do.

Talking only to power users: Your most engaged users are atypical. They've already adapted to your product's quirks, found workarounds for broken flows, and forgiven errors that new users would abandon over. Research your target persona, the user you're trying to acquire, not the user who's already stuck with you.

Conducting research to justify, not discover: The most dangerous form of user research is asking questions designed to validate a decision that's already been made. This produces confirmation bias at scale. If the team goes into research knowing what they want to hear, they'll hear it. Frame interviews around understanding, not validation.

Stopping discovery after launch: Discovery is continuous. The launch is not the end. It's the beginning of a feedback loop. User behaviour post-launch is the richest source of insight you'll ever have. Teams that stop researching after launch lose situational awareness and start building based on internal opinion again.

Takeaway

The best PMs are obsessive learners

Talk to users weekly

Not quarterly. Not before launch. Every week. Even one 30-minute interview per week compounds into a level of user intuition that no amount of analytics can replicate. The goal is to never be surprised by what users do with your product.

Fall in love with the problem

Attachment to solutions is the root cause of most product failures. Teams that fall in love with their solution ignore evidence that the problem is different. Teams that fall in love with the problem are free to discover whatever solution actually works.

Test cheap, build confident

Every week of engineering time spent on an unvalidated hypothesis is a week of risk. Prototype, test, and invalidate hypotheses at the lowest possible fidelity. When the assumptions survive testing, build with confidence, not hope.

ProductDiscovery &User Research