Empathy & Discovery

Users are unreliable forecasters of their own behavior. They will tell you they want a feature they will never use, that they would pay for something they never will, and that they hate a UI they keep returning to. Discovery is the discipline of trusting what users do over what they say. The interview is a tool to reconstruct past behavior, not to predict future behavior.

• Past behavior > stated intent > hypothetical preference, in that order.
• When you must ask hypotheticals, ask about a specific recent moment, not a general future.
• If a user says 'I would definitely pay for this', ask 'how much have you paid for the workaround you use today?'

JTBD is not one thing; there are three overlapping schools. Conflating them is the most common error PMs make. Pick the school that matches your decision and stick with its vocabulary.

• Christensen / Switch (Bob Moesta, Chris Spiek): focuses on the moment of switching from an old solution to a new one. Vocabulary: anxieties, habits, push, pull, the four forces.
• Outcome-Driven Innovation (Tony Ulwick): functional jobs decomposed into measurable desired outcomes scored on importance and current satisfaction. Vocabulary: opportunity score = importance + max(importance - satisfaction, 0).
• Strategyzer (Alex Osterwalder): jobs as the input to value proposition design — functional, emotional, and social jobs paired with pains and gains.

The Switch interview reconstructs the moment a user moved from one solution to another. The framework: push of the current situation, pull of the new solution, anxieties about switching, and habits of the present. Demand exists when push + pull > anxieties + habits. Strong PMs probe each force explicitly.

• Push: what specifically broke about the prior workflow? When? With whom?
• Pull: what about the new option crossed the threshold of 'good enough to try'?
• Anxiety: what worried you about adopting? Cost, risk, social risk, learning curve?
• Habit: what kept you on the old way for so long even after the push appeared?
• If anxieties or habits are larger than push + pull, demand is theoretical, not real.

Most PMs overestimate how good their interviews are. The biggest issues: leading questions, pitching the solution, asking users to design, and accepting articulated reasons at face value. A good interview is structured but not scripted — it reconstructs behavior in vivid detail.

• Open with a recent specific moment: 'walk me through the last time this happened.'
• Probe the timeline minute by minute; don't accept summary statements.
• Listen for energy changes — sighs, accelerations, pauses — and follow them.
• Ask about workarounds before pitching solutions; the workaround is the price of admission.
• Never end an interview without asking 'what didn't I ask that I should have?'
• Record (with consent) and tag transcripts; memory compresses everything within 48 hours.

Teresa Torres's continuous discovery practice replaces the 'discovery phase' with a weekly cadence. Goal: the product trio (PM, design, eng tech-lead) talks to at least one user per week, every week, and updates an Opportunity Solution Tree against a clear desired outcome.

• Recruit a continuous panel; don't restart sourcing every project.
• Hold a weekly trio sync to update the tree, not to ask permission.
• Treat any week without an interview as a discovery debt — name it and pay it down.
• Discovery and delivery interleave; one is not the gate to the other.

An OST visualizes the chain from desired outcome → opportunities (problems / unmet needs surfaced from research) → candidate solutions → assumption tests. Read top-down, you can see why each solution is being considered. Read bottom-up, every test laddered to a real user opportunity tied to the team's outcome.

• One outcome at the root; multiple opportunities; multiple solutions per opportunity; multiple tests per solution.
• Resist solutions that don't ladder to a named opportunity.
• Use the tree to argue with: 'is this opportunity bigger than that one?', 'which solution best targets this opportunity?'
• Refresh weekly with new evidence; prune branches that lose evidence.

Marty Cagan separates four risk types every product idea faces: Value (will users use it?), Usability (can they use it?), Feasibility (can we build it?), and Viability (does it work for the business — legal, sales, support, finance?). Discovery is the practice of identifying which of these risks dominates each idea, then designing the cheapest test that retires that risk.

• Value risk dominates new categories and new audiences.
• Usability risk dominates radical UI changes.
• Feasibility risk dominates technically novel work (ML, real-time, scale).
• Viability risk dominates regulated or pricing-sensitive areas.

Journey maps walk a single user persona through a real workflow over time, capturing actions, thoughts, emotions, and moments of friction. Service blueprints extend the journey to include backstage processes — what the company, systems, and policies have to do for the front-stage moment to work. Most B2B and ops-heavy products fail at the back-stage, not the screen.

• Build the map from a real recorded session, not a workshop guess.
• Mark each step with: action, thought, emotion, friction, time elapsed.
• For service blueprints, add backstage actions, support systems, and SLAs.
• Highlight 'moments of truth' where the experience succeeds or breaks.

Surveys are popular because they scale; they are misused because they're easy. Most product surveys suffer from selection bias (only enthusiasts respond), social desirability bias (respondents tell you what they think you want to hear), and order effects (the question above leaks into the answer below). Surveys are useful as quantification of a hypothesis you've already developed qualitatively — almost never as discovery from scratch.

• Use surveys to size, not to discover.
• Avoid 'would you use' and 'how much would you pay' — both are unreliable.
• Anchor questions to behavior in the last week, not preferences in the abstract.
• Pilot with 10 users before sending; 80% of survey-design errors are caught in the first 5 responses.
• Always include an open-ended question; the verbatims are usually more useful than the rating scales.

Single-source insights are dangerous. Triangulate by combining qualitative interviews (why), quantitative analytics (how big), and market evidence (does the world support this trend?). When all three agree, conviction is high. When they disagree, follow the disagreement — that's where the most useful learning lives.

• Qualitative tells you what's happening and why.
• Quantitative tells you how big and how often.
• Market evidence (competitors, adjacent industries, primary indicators) tells you whether the wind is at your back or in your face.
• Document each source with its confidence level; don't average them, weight them.

Discovery without an artifact decays inside one PM's head. The team needs a shared insight library — tagged interview snippets, opportunities, evidence — that survives PM turnover and accumulates across projects. Even a simple shared doc with consistent tags beats brilliant siloed memory.

• Tag every quote with: persona, job, opportunity, severity, confidence.
• Make the library searchable; if you can't find a tagged quote in 30 seconds, the system has failed.
• Review the top opportunities every quarter as the OST root candidates for the next quarter.