共情与用户发现
通过持续的、以证据为导向的用户发现,把真实需求与表达出来的愿望区分开,从而赢得开发的资格。
Explainer
Discovery 是赢得「构建权」的工作。大多数产品失败并非执行失败,而是被已发布功能伪装起来的需求失败。强 discovery 拒绝那些舒适的捷径 —— 没有行为支撑的问卷、焦点小组、用于「验证」的巡回演示 —— 用一个紧密的循环替代它们:访谈、观察、分析,并把定性证据与定量信号交叉验证,直到团队诚实地比上周少错一些。
陈述偏好 vs 已揭示的行为
用户是自身行为的不可靠预测者。他们会告诉你他们想要一个永远不会用到的功能,会为某样他们永远不会买单的东西付费,讨厌一个他们却又一再回到的界面。Discovery 的纪律是相信用户做的,而不是用户说的。访谈是用来重建过去行为的工具,而不是用来预测未来行为的。
- 过去行为 > 陈述意向 > 假设性偏好,顺序如此。
- 当不得不问假设性问题时,锚定一个具体的近期时刻,而不是一个泛化的未来。
- 如果用户说「我一定会为这个付费」,问:「你今天用的那个 workaround,你已经付了多少钱?」
Jobs-to-be-Done — 三大流派
JTBD 不是单一事物;有三个互相重叠的流派。把它们混在一起是 PM 最常犯的错误。选择契合你决策的流派,坚持使用它的词汇。
- Christensen / Switch(Bob Moesta、Chris Spiek):聚焦于从旧方案切换到新方案的那一刻。词汇:焦虑、习惯、push、pull、四种力。
- Outcome-Driven Innovation(Tony Ulwick):把功能性 job 拆解为可度量的期望结果,并按重要性与当前满意度评分。词汇:opportunity score = 重要性 + max(重要性 − 满意度, 0)。
- Strategyzer(Alex Osterwalder):把 jobs 当作价值主张设计的输入 —— 功能、情感与社会性 jobs,与 pains 和 gains 配对。
Switch 访谈与四种力
Switch 访谈重建用户从一种方案切换到另一种的那个时刻。框架:当前情境的 push、新方案的 pull、对切换的焦虑、当前的习惯。当 push + pull > 焦虑 + 习惯,需求才存在。强 PM 会显式探查每一种力。
- Push:之前工作流具体是什么坏掉了?什么时候?跟谁一起?
- Pull:新选项的什么跨过了「值得一试」的门槛?
- 焦虑:采用时担心什么?成本、风险、社会风险、学习曲线?
- 习惯:即使 push 出现后,什么让你在旧方式上停留这么久?
- 如果焦虑或习惯大于 push + pull,需求是理论上的,不是真实的。
用户访谈机制
大多数 PM 高估自己访谈的质量。最大问题:诱导性提问、推销解决方案、让用户做设计、把用户表面上说的理由当真。好的访谈是有结构但不死板 —— 它以鲜活的细节重建行为。
- 用一个具体的近期时刻开场:「带我走一遍你上次发生这件事的过程。」
- 逐分钟探查时间线;不要接受总结性陈述。
- 听能量的变化 —— 叹息、加速、停顿 —— 并跟随它们。
- 在提出方案之前,先问 workaround;workaround 是入场费。
- 永远不要在没有问「我没问到的、应该问的是什么?」之前结束访谈。
- (经同意后)录音并标注转录;48 小时内记忆会压缩一切。
把持续 discovery 当作每周习惯
Teresa Torres 的持续 discovery 实践用每周节奏取代「discovery 阶段」。目标:产品三人组(PM、设计、工程负责人)每周至少与一位用户交谈,并以一个清晰的期望结果为目标更新 Opportunity Solution Tree。
- 建立一个持续的用户面板;不要每个项目都重启招募。
- 三人组每周做一次 sync,用来更新树,而不是请求许可。
- 把任何没有访谈的一周视为 discovery 债 —— 命名并偿还。
- discovery 与 delivery 交错进行;一个不是另一个的关卡。
Opportunity Solution Tree
OST 把链条可视化:期望结果 → 机会(从研究中浮现的问题/未满足需求)→ 候选方案 → 假设测试。自上而下读,你能看见每个方案为什么被考虑;自下而上读,每一个测试都连接到一个真实的用户机会,绑定团队的结果。
- 根节点是一个结果;多个机会;每个机会下多个方案;每个方案下多个测试。
- 拒绝那些无法连接到具名机会的方案。
- 用这棵树来辩论:「这个机会比那个大吗?」「哪个方案最贴合这个机会?」
- 每周用新证据刷新;剪掉失去证据的分支。
风险-假设映射
Marty Cagan 把每个产品想法面对的四种风险分开:价值(用户会用吗?)、可用性(他们能用吗?)、可实现性(我们能做出来吗?)、商业可行性(对业务行得通吗 —— 法务、销售、支持、财务?)。Discovery 是识别哪种风险主导每个想法、并设计最便宜的实验来消除该风险的实践。
- 在新品类与新受众中,价值风险占主导。
- 在激进的 UI 变更中,可用性风险占主导。
- 在技术新颖的工作(ML、实时、规模)中,可实现性风险占主导。
- 在受监管或对价格敏感的领域,商业可行性风险占主导。
用户旅程图与服务蓝图
旅程图沿时间维度跟随单一用户人物角色走过一个真实工作流,捕捉行动、想法、情绪与摩擦时刻。服务蓝图把旅程延伸到后台流程 —— 公司、系统与政策必须做什么,前台时刻才能正常运转。多数 B2B 和重运营的产品在后台失败,而不是在屏幕上。
- 从真实录制的会话构建图,而不是从工作坊里的猜测。
- 用以下要素标记每一步:行动、想法、情绪、摩擦、所用时间。
- 做服务蓝图时,加上后台行动、支持系统与 SLA。
- 突出体验成功或破裂的「真相时刻」。
问卷设计与为何多数问卷会撒谎
问卷之所以流行,是因为可扩展;它们之所以被滥用,是因为容易做。多数产品问卷受三种偏差困扰:选择偏差(只有热情用户回应)、社会期望偏差(回答者告诉你他们认为你想听的)、顺序效应(上一题渗透到下一题的回答里)。问卷适合用来量化你已经定性发展过的假设 —— 几乎从来不适合从零探索。
- 用问卷来量化规模,而不是发现。
- 避免「你会用吗」和「你会付多少钱」—— 两者都不可靠。
- 把问题锚定在过去一周的行为,而不是抽象的偏好。
- 发送前用 10 个用户做试点;80% 的设计错误能在前 5 份回答中发现。
- 始终包含一个开放性问题;原文回答通常比评分量表更有用。
三角验证:定性 + 定量 + 市场
单一来源的洞察很危险。通过结合定性访谈(为什么)、定量分析(多大)、市场证据(世界是否支持这个趋势?)进行三角验证。当三者一致,信心度高;当它们不一致,跟随分歧 —— 那是最有用学习的所在。
- 定性告诉你正在发生什么、为什么。
- 定量告诉你多大、多频繁。
- 市场证据(竞品、相邻行业、领先指标)告诉你风是顺还是逆。
- 为每个来源标注置信度;不要平均,要加权。
Discovery 的产物:洞察库
没有产物的 discovery 会在某一个 PM 的脑袋里腐烂。团队需要一个共享的洞察库 —— 已标注的访谈片段、机会、证据 —— 它在 PM 流动后仍能存活,并跨项目积累。即使是一个有一致标签的简单共享文档,也比一个出色但孤岛化的记忆要好。
- 为每条引用打标签:人物、job、机会、严重性、置信度。
- 让库可搜索;如果你不能在 30 秒内找到一条已标注的引用,这个系统就失败了。
- 每季度回顾顶级机会,作为下个季度 OST 根节点的候选。
Framework atlas
Reference cards for each method in this mission
Expand a card for when to deploy it, misuse patterns, sequencing guidance, and (where relevant) shorthand formulas.
Discovery interview · Bob Moesta & Chris Spiek (Re-Wired Group / The Rewired Group)Switch / Forces of Progress(Switch)
A structured interview format that reconstructs a user's switch from an old solution to a new one, mapped to the four forces: push, pull, anxiety, habit.
When to use
- Understanding why users adopted (or didn't adopt) a category.
- Pricing and packaging research.
- Churn and switching investigations.
When not to
- Pure usability testing of a specific UI.
- Discovery for an entirely new behavior with no prior solution to switch from.
How to apply
- Recruit users who switched within the last 90 days.
- Anchor the conversation to the day of the switch.
- Probe push, pull, anxiety, habit explicitly with timeline questions.
- Identify the moment of first thought, struggle, deciding event, and consumption event.
- Synthesize forces and map to demand strength.
- Asking about preference instead of behavior.
- Letting users summarize ('I just got tired of it') instead of reconstructing the timeline.
Discovery synthesis · Teresa TorresOpportunity Solution Tree(OST)
Visual structure connecting a desired outcome to opportunities (problems), candidate solutions, and the experiments that test them.
When to use
- Continuous discovery teams aligning on what to learn next.
- Quarterly planning where the outcome is fixed but the path is not.
When not to
- When the team has not yet defined a clear outcome — fix that first.
How to apply
- State the outcome at the root.
- Surface opportunities from research; cluster duplicates.
- Map candidate solutions under each opportunity.
- Define the riskiest assumption per solution and an experiment to test it.
- Update weekly with new evidence; prune unsupported branches.
- Stuffing every feature request as a 'solution' regardless of opportunity fit.
- Letting the tree become a static slide deck instead of a living doc.
Discovery quantification · Tony UlwickOutcome-Driven Innovation(ODI)
Decomposes a job into outcome statements (e.g. 'minimize the time it takes to identify duplicate contacts'), then surveys users on importance and current satisfaction. Opportunity score = importance + max(0, importance - satisfaction).
Opportunity = Importance + max(0, Importance − Satisfaction)
When to use
- Mature markets where the job is well understood and you need to find under-served outcomes.
- Roadmap arbitration when many possible directions look equally appealing.
When not to
- Brand-new categories where the user can't articulate the job yet.
How to apply
- Identify the core functional job through interviews.
- Decompose into outcome statements (verb + object + clarifier, e.g. 'minimize time to ___').
- Survey 100+ users for importance (1-10) and satisfaction (1-10).
- Compute the opportunity score per outcome.
- Prioritize outcomes with score > 12 as under-served opportunities.
- Writing outcome statements that contain solutions ('add an auto-detect button').
- Surveying users who don't actually do the job.
Discovery prioritization · Marty Cagan / SVPGRisk-Assumption Mapping
Categorizes the risks of a product idea into Value, Usability, Feasibility, and Viability and tests the largest risks first with the smallest possible experiment.
When to use
- Before committing eng capacity to a non-trivial bet.
- When the team feels unable to articulate why an idea might fail.
When not to
- Tiny incremental changes where a single A/B test is enough.
How to apply
- List all assumptions the idea depends on.
- Tag each as Value / Usability / Feasibility / Viability risk.
- Score by impact-if-wrong and confidence-now.
- Design the cheapest experiment to retire the top 1-2 risks.
- Re-rank weekly as evidence accumulates.
Root cause analysis · Sakichi Toyoda / Toyota Production SystemFive Whys
Iteratively ask 'why' to walk from a symptom to a root cause. Useful in user interviews, post-mortems, and bug triage.
When to use
- Surface-level user complaints whose real cause is unclear.
- Post-incident reviews.
When not to
- Multi-causal complex systems where a single 'why' chain oversimplifies; use a fishbone diagram instead.
How to apply
- Start with the observed symptom or complaint.
- Ask 'why' and capture the answer; don't accept generalities.
- Repeat 4–5 times until the answer is structural rather than personal.
Product Psychology
Cognitive biases that distort product decisions
Confirmation Bias in Interviews
Interviewers selectively probe and remember evidence that confirms the going hypothesis.
Product Risk
The team walks out of every research round 'validated', regardless of what users actually said.
Research Countermove
Pre-register the hypothesis and the falsification criterion. Have a second interviewer or transcriber tag quotes blind to the hypothesis.
Researcher / Demand Effect
Users mirror what they believe the interviewer wants to hear, especially when interviewer comes from the company that might pay them or refer them.
Product Risk
Hypotheticals get inflated agreement; pricing surveys inflate willingness to pay; feature interest is overstated.
Research Countermove
Use neutral recruiters who don't disclose the hypothesis. Pay users a fixed incentive regardless of stated enthusiasm. Anchor questions in past behavior, not future preference.
Recency Bias in Synthesis
The most recent interview disproportionately influences the synthesis even when earlier interviews carried the same signal.
Product Risk
Roadmaps swing toward whichever user the team last heard from, especially executives or vocal users.
Research Countermove
Tag every quote at intake, not at synthesis. Synthesis should weight every tagged quote equally, not by memorability.
Articulation Bias
Users who can articulate clearly are over-represented; quieter users with the same problem are missed.
Product Risk
Power-user features ship while novice-user pain remains invisible.
Research Countermove
Recruit deliberately across articulation styles; supplement interviews with observation, screen-share recordings, and unmoderated tests.
Hawthorne Effect
Users behave differently because they know they're being observed.
Product Risk
Lab usability tests overstate competence; users perform for the researcher.
Research Countermove
Use unmoderated remote tests, in-product analytics, and longitudinal studies whenever possible. Treat moderated lab tests as one of multiple data sources.
Cargo-Cult Discovery
Adopting discovery rituals (interviews, OSTs, story maps) without the underlying behavioral change in the team's decision-making.
Product Risk
Discovery becomes documentation theater; the same backlog ships regardless of what was learned.
Research Countermove
Tie every discovery output to a decision: 'This week's research changes our roadmap in this specific way, or it changes our confidence in this specific item.'
Organizational anti-patterns
When ceremonies look like rigor but aren't
Validating, Not Discovering
Research is scheduled after the spec is written; goal is to confirm rather than challenge.
PM has already committed to the solution and uses 'discovery' as a checkpoint to feel safe.
Run discovery before scoping. If you must run it after, give the team explicit permission to kill the idea based on findings.
The Persona Slide That Lives Forever
A glossy persona deck made 18 months ago is still cited in decisions; nobody can name a real recent user.
Personas are easier to display than to maintain; nobody owns their freshness.
Replace static personas with a continuous panel. Cite real recent quotes and behaviors in decisions, not 'Marketer Mary'.
Survey-First Discovery
The team's first move on every new question is to send a survey.
Surveys feel scientific and scale fast; interviews feel slow and subjective.
Lead with 5-7 interviews; only survey to size what interviews already revealed qualitatively.
The Loudest User Drives the Roadmap
Roadmap shifts in response to the latest angry support ticket or executive escalation.
Without an aggregated insight library, vivid recent feedback wins by default.
Aggregate weekly: count themes across interviews, support tickets, NPS verbatims, and churn reasons. Make the count visible in roadmap meetings.
Insights as Slide Decks
Research findings live as polished one-time decks; they don't accumulate into a searchable corpus.
Researchers and PMs are rewarded for visible deliverables, not infrastructure.
Standardize tagging. Build a searchable repository — even a structured Notion/Coda/Airtable database is enough.
Worked examples
Walkthroughs translated from real trade-off rooms
Catching a phantom feature with a switch interview
A team is convinced users want richer reporting. Surveys show 78% interest. Internal advocates are pushing for a Q1 build.
- Run 8 switch interviews with users who recently adopted a competitor that already has rich reporting.
- Map the four forces. Push and pull are real; anxieties (cost, change) are large; habit (existing internal dashboards) is the largest force.
- Find that only 2/8 actually use the rich reporting after switching; 6/8 still rely on legacy dashboards exported to spreadsheets.
- Reframe the opportunity: not 'rich reporting in product' but 'reduce the spreadsheet round-trip'. Ship a CSV export with templated views in 3 weeks instead of a 4-month reporting build.
TakeawayStated demand was real but did not translate into post-switch usage. The actual job was about leaving the product, not staying in it.
Using ODI to find the under-served outcome
A meeting-notes product wants to know which AI feature to build first.
- Interview 12 users to identify the functional job: 'capture decisions and action items from a meeting'.
- Decompose into 14 outcome statements, e.g. 'minimize time to identify action items', 'minimize chance of missing a decision'.
- Survey 200 users for importance and satisfaction.
- Highest opportunity scores: 'minimize time to share notes with absentees' (15.2) and 'minimize chance of missing a decision' (14.8).
- Lower than expected: 'minimize time to identify action items' (10.1) — already considered well-served by the existing product.
TakeawayODI redirected the team from auto-summarization (already satisfying) toward decision tracking and absentee summaries (under-served).
Killing a feature using risk-assumption mapping
Team wants to add an in-app marketplace for third-party integrations.
- List assumptions: users want to discover integrations in-product; partners will list; we can review submissions; legal can manage liability; revenue model works.
- Tag risks: Value (partial — direct evidence weak), Viability (dominant — legal & revenue model unsolved), Feasibility (medium).
- Test viability first with 5 partner conversations and a legal review — both come back negative under current contracts.
- Kill the marketplace; instead, ship a curated integrations directory and a partner program with handpicked launch partners.
TakeawayThe dominant risk was viability, not value. Testing the right risk first prevented a 6-month build that would have shipped into a legal wall.
Resources / Case Studies
Curated reading for this mission
Teresa Torres
The canonical operating manual for weekly discovery practices, the Opportunity Solution Tree, and assumption testing.
The single most actionable book on modern discovery practice; every team benefits from running its first 90 days.
Teresa Torres
The original blog series introducing the OST as a connective tissue between outcomes, opportunities, solutions, and tests.
The clearest free reference for the OST diagram and its discipline.
Bob Moesta
Moesta's articulation of JTBD applied to selling. Covers the four forces, switching moments, and the timeline interview.
Translates JTBD from theory to operational interview craft for PMs and sales partners.
Tony Ulwick (Strategyn)
Ulwick's school of JTBD with outcome-driven innovation, opportunity scoring, and quantitative discovery.
The right tool when the team needs to size and prioritize unmet needs at scale, not just understand them qualitatively.
Marty Cagan (SVPG)
Cagan's Value/Usability/Feasibility/Viability framework and prototyping techniques for retiring each risk type.
Establishes the risk-typing language that the rest of the industry uses.
Steve Portigal
Portigal's craft-level guide to interviewing users without leading them. Covers question design, listening, and synthesis.
The best stand-alone book on interview mechanics, especially for PMs without UX research training.
Rob Fitzpatrick
How to run customer conversations that surface real evidence even when users (and your mom) want to be encouraging.
A 90-minute read that fixes the most common interview mistake — asking questions that beg for compliments.
Product Talk
Templates for OSTs, interview snapshots, and weekly trio cadences.
Saves teams the design-thinking-template hunt; production-ready artifacts to drop into Notion or Miro.
Alan Klement
JTBD case study showing how customers hire and fire products through unexpected substitutions.
Strong narrative companion to the Switch interview methodology.
Lenny Rachitsky
Practitioner case studies on user research from PMs at Airbnb, Stripe, Notion, and more.
Recurring real-world examples from current product teams; a complement to the canonical books.
Alberto Savoia
Pretotyping and the search for 'the right it' before 'building it right'. Practical low-cost demand experiments.
Bridges discovery and early experimentation, with concrete templates for fake-door tests, smoke tests, and the like.
How to operationalize ongoing user research at scale: panels, ops, tooling, and synthesis.
Covers the operational layer that most discovery books skip.