product-discovery

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Product Discovery

产品发现

Core Principles

核心原则

Continuous Discovery — Weekly user conversations, not episodic research
Outcome-Driven — Start with outcomes to achieve, not solutions to build
Assumption Testing — Validate risky assumptions before committing resources
Co-Creation — Build with customers, not just for them
Data-Driven — Use evidence over intuition and stakeholder opinions
Problem-First — Deeply understand the problem space before ideating solutions

持续发现 —— 每周与用户沟通，而非阶段性开展研究
以结果为导向 —— 从要达成的结果入手，而非从要构建的解决方案入手
假设验证 —— 在投入资源前先验证高风险假设
共创 —— 与客户共同构建产品，而非仅为他们构建
数据驱动 —— 基于证据而非直觉和利益相关者意见做决策
先聚焦问题 —— 在构思解决方案前深入理解问题领域

Hard Rules (Must Follow)

硬性规则（必须遵守）

These rules are mandatory. Violating them means the skill is not working correctly.

这些规则为强制性要求。违反规则意味着该技能未正常发挥作用。

No Solution-First Thinking

禁止“先解决方案”思维

Never start with a solution. Always define the problem and outcome first.

markdown

❌ FORBIDDEN:
"We should build a search bar for the product page"
"Let's add AI recommendations"
"Users need a mobile app"

✅ REQUIRED:
"Problem: Users can't find products (40% exit rate on catalog)
Outcome: Reduce exit rate to 20%
Possible solutions:
1. Search bar with filters
2. AI-powered recommendations
3. Better category navigation
4. Visual product browsing"

绝对不要从解决方案入手。始终先定义问题和结果。

markdown

❌ 禁止:
"我们应该为产品页面添加搜索栏"
"我们来加入AI推荐功能"
"用户需要一款移动端应用"

✅ 要求:
"问题：用户无法找到产品（目录页退出率达40%）
结果：将退出率降至20%
可行解决方案:
1. 带筛选功能的搜索栏
2. AI驱动的推荐系统
3. 优化分类导航
4. 可视化产品浏览"

Evidence-Based Decisions

基于证据做决策

Never assume user needs without evidence from real user research.

markdown

❌ FORBIDDEN:
- "Users probably want X" (assumption without data)
- "Our competitor has X, so we need it too" (copycat without validation)
- "The CEO thinks we should build X" (HiPPO without evidence)
- "It's obvious users need X" (intuition without validation)

✅ REQUIRED:
- "5 out of 8 interviewed users mentioned X as a pain point"
- "Analytics show 60% of users abandon at step 3"
- "Prototype test: 7/10 users completed task successfully"
- "Survey (n=500): 45% rated feature as 'must have'"

绝对不要在没有真实用户研究证据的情况下假设用户需求。

markdown

❌ 禁止:
- "用户可能想要X"（无数据支撑的假设）
- "我们的竞品有X，所以我们也需要"（未经验证的模仿）
- "CEO认为我们应该做X"（无证据的权威决策）
- "显然用户需要X"（无验证的直觉判断）

✅ 要求:
- "8位受访用户中有5位提到X是痛点"
- "数据分析显示60%的用户在步骤3放弃操作"
- "原型测试：10位用户中有7位成功完成任务"
- "调研（样本量500）：45%的用户将该功能评为‘必备’"

Minimum Interview Threshold

最低访谈阈值

Never validate a problem with fewer than 5 user interviews per segment.

markdown

❌ FORBIDDEN:
- "We talked to 2 users and they loved the idea"
- "One customer requested this feature"
- "Based on a quick chat with sales..."

✅ REQUIRED:
| Segment | Interviews | Key Finding |
|---------|------------|-------------|
| Power Users | 6 | 5/6 struggle with X |
| New Users | 5 | 4/5 drop off at onboarding |
| Churned | 5 | 3/5 cited missing feature Y |

Minimum per segment: 5 interviews
Confidence increases with more interviews

绝对不要用每个细分群体少于5次的用户访谈来验证问题。

markdown

❌ 禁止:
- "我们和2位用户聊过，他们都喜欢这个想法"
- "有一位客户要求添加这个功能"
- "基于与销售的快速沟通..."

✅ 要求:
| 细分群体 | 访谈次数 | 关键发现 |
|---------|------------|-------------|
| 核心用户 | 6 | 6位受访者中有5位在X方面存在困难 |
| 新用户 | 5 | 5位受访者中有4位在注册流程中流失 |
| 流失用户 | 5 | 5位受访者中有3位提到缺少功能Y |

每个细分群体最低访谈次数：5次
访谈次数越多，结论可信度越高

Falsifiable Assumptions

可证伪的假设

Every assumption must be testable and falsifiable with clear success criteria.

markdown

❌ FORBIDDEN:
- "Users will like the new design" (not falsifiable)
- "This will improve engagement" (no success criteria)
- "The feature will be useful" (vague)

✅ REQUIRED:
| Assumption | Test | Success Criteria | Result |
|------------|------|------------------|--------|
| Users will complete onboarding in new flow | Prototype test with 10 users | >70% completion | TBD |
| Users prefer visual search | A/B test | >10% lift in conversions | TBD |
| Price point is acceptable | Landing page test | >3% conversion | TBD |

每个假设都必须可测试、可证伪，并具备明确的成功标准。

markdown

❌ 禁止:
- "用户会喜欢新设计"（不可证伪）
- "这将提升用户参与度"（无成功标准）
- "该功能会很有用"（表述模糊）

✅ 要求:
| 假设 | 测试方式 | 成功标准 | 结果 |
|------------|------|------------------|--------|
| 用户能通过新流程完成注册 | 10位用户参与原型测试 | 完成率>70% | 待确定 |
| 用户偏好视觉搜索 | A/B测试 | 转化率提升>10% | 待确定 |
| 定价区间可接受 | 落地页测试 | 转化率>3% | 待确定 |

Quick Reference

快速参考

When to Use What

场景与工具匹配

Scenario	Framework/Tool	Output
Validate product idea	Product Opportunity Assessment	Go/no-go decision
Size market opportunity	TAM/SAM/SOM	Market size estimates
Understand user needs	User Research (interviews, surveys)	User insights, pain points
Analyze competition	Competitive Analysis	Competitive landscape map
Discover user motivations	Jobs-to-be-Done (JTBD)	Job stories, outcomes
Prioritize features	Kano Model	Feature categorization
Define value proposition	Value Proposition Canvas	Value prop statement
Test product concept	Lean Startup / MVP	Validated learnings
Map opportunities	Opportunity Solution Tree	Prioritized opportunities

场景	框架/工具	输出成果
验证产品想法	产品机会评估	立项/否决决策
评估市场机会规模	TAM/SAM/SOM	市场规模估算
理解用户需求	用户研究（访谈、调研）	用户洞察、痛点
竞品分析	竞品分析	竞品格局图
挖掘用户动机	Jobs-to-be-Done (JTBD)	任务故事、预期结果
功能优先级排序	Kano模型	功能分类
定义价值主张	价值主张画布	价值主张声明
测试产品概念	精益创业/MVP	已验证的认知
机会映射	机会-解决方案树	优先级排序后的机会

Continuous Discovery Habits

持续发现的习惯

The Product Trio

产品三人组

Discovery is led by three roles working together weekly:

Product Manager → Defines outcomes, owns roadmap
Designer        → Explores solutions, tests usability
Engineer        → Assesses feasibility, proposes technical solutions

产品发现由三个角色共同主导，每周协作推进：

产品经理 → 定义结果，负责路线图
设计师 → 探索解决方案，测试可用性
工程师 → 评估可行性，提出技术方案

Weekly Activities

每周工作内容

markdown

undefined

markdown

undefined

1. Customer Interviews (Weekly)

1. 用户访谈（每周）

Schedule 3-5 interviews per week minimum
Mix of current users, churned users, prospects
Focus on understanding problems, not pitching solutions
Record and share insights with team

每周至少安排3-5次访谈
覆盖现有用户、流失用户和潜在用户
聚焦理解问题，而非推销解决方案
记录并与团队分享洞察

2. Assumption Testing (Weekly)

2. 假设验证（每周）

Identify riskiest assumptions about solutions
Design quick tests (prototypes, landing pages, fake doors)
Run experiments with real users
Measure results against success criteria

识别解决方案中风险最高的假设
设计快速测试（原型、落地页、假门测试）
针对真实用户开展实验
对照成功标准衡量结果

3. Opportunity Mapping (Ongoing)

3. 机会映射（持续进行）

Build opportunity solution tree
Map customer needs to potential solutions
Prioritize based on impact and feasibility
Update as you learn

undefined

构建机会-解决方案树
将客户需求映射到潜在解决方案
基于影响力和可行性排序
根据新认知更新内容

undefined

Discovery vs Delivery

产品发现 vs 产品交付

Discovery (What to Build)          Delivery (How to Build It)
├─ Customer interviews             ├─ Sprint planning
├─ Prototype testing               ├─ Development
├─ Assumption validation           ├─ QA testing
├─ Market research                 ├─ Deployment
└─ Opportunity assessment          └─ Post-launch monitoring

Key difference: Discovery reduces risk BEFORE committing to build

产品发现（构建什么）          产品交付（如何构建）
├─ 用户访谈             ├─ 冲刺规划
├─ 原型测试               ├─ 开发
├─ 假设验证           ├─ QA测试
├─ 市场研究                 ├─ 部署
└─ 机会评估          └─ 上线后监控

核心差异：产品发现在投入构建前降低风险

Product Opportunity Assessment

产品机会评估

Marty Cagan's 10 Questions

Marty Cagan的10个问题

Before starting any product initiative, answer these questions:

markdown

undefined

启动任何产品项目前，先回答以下问题：

markdown

undefined

1. Problem Definition

1. 问题定义

What problem are we solving?

Be specific and measurable
Validate it's a real problem (not assumed)

我们要解决什么问题？

具体且可衡量
验证为真实存在的问题（非假设）

2. Target Market

2. 目标市场

For whom are we solving this problem?

Define specific user segments
Size the addressable market (TAM/SAM/SOM)

我们为谁解决这个问题？

定义具体的用户细分群体
估算可触达市场规模（TAM/SAM/SOM）

3. Opportunity Size

3. 机会规模

How big is the opportunity?

Revenue potential
User growth potential
Strategic value

这个机会有多大？

营收潜力
用户增长潜力
战略价值

4. Success Metrics

4. 成功指标

How will we measure success?

Leading indicators (usage, engagement)
Lagging indicators (revenue, retention)
Define targets upfront

我们如何衡量成功？

领先指标（使用量、参与度）
滞后指标（营收、留存率）
提前定义目标

5. Alternative Solutions

5. 替代方案

What alternatives exist today?

Direct competitors
Indirect solutions
Current user workarounds

目前有哪些替代方案？

直接竞品
间接解决方案
用户当前的权宜之计

6. Our Advantage

6. 我们的优势

Why are we best suited to solve this?

Unique capabilities
Market position
Technical advantages

为什么我们最适合解决这个问题？

独特能力
市场地位
技术优势

7. Strategic Fit

7. 战略适配性

Why now? Why us?

Market timing
Strategic alignment
Resource availability

为什么是现在？为什么是我们？

市场时机
战略对齐
资源可用性

8. Dependencies

8. 依赖项

What do we need to succeed?

Technical dependencies
Partnership requirements
Regulatory considerations

我们需要什么才能成功？

技术依赖
合作需求
合规考量

9. Risks

9. 风险

What could go wrong?

Market risk (will anyone want it?)
Execution risk (can we build it?)
Monetization risk (will they pay?)

可能出现哪些问题？

市场风险（有人需要吗？）
执行风险（我们能构建出来吗？）
变现风险（用户会付费吗？）

10. Cost of Delay

10. 延迟成本

What happens if we don't build this?

Competitive disadvantage
Lost revenue
Market opportunity window

undefined

如果我们不构建这个产品，会发生什么？

竞争劣势
营收损失
市场机会窗口关闭

undefined

Value vs Effort Framework

价值-投入框架

Quick prioritization of opportunities:

High Value, Low Effort  → Do First (Quick Wins)
High Value, High Effort → Plan Strategically (Big Bets)
Low Value, Low Effort   → Do Later (Fill Gaps)
Low Value, High Effort  → Don't Do (Money Pit)

快速优先级排序机会：

高价值、低投入  → 优先执行（快速胜利）
高价值、高投入 → 战略规划（重大赌注）
低价值、低投入   → 后续执行（填补空白）
低价值、高投入  → 放弃执行（资金陷阱）

Discovery Methods

产品发现方法

When to Use What Method

方法适用场景

markdown

undefined

markdown

undefined

Generative Research (What problems exist?)

生成式研究（存在哪些问题？）

Use when: Starting new product area, exploring unknown space Methods:

Ethnographic field studies
Contextual inquiry
Diary studies
Open-ended interviews

适用场景：进入新领域、探索未知空间方法:

人种学实地研究
情境调研
日记研究
开放式访谈

Evaluative Research (Does our solution work?)

评估式研究（我们的解决方案是否有效？）

Use when: Testing specific solutions, validating designs Methods:

Usability testing
Prototype testing
A/B testing
Concept testing

适用场景：测试特定解决方案、验证设计方法:

可用性测试
原型测试
A/B测试
概念测试

Quantitative Research (How much? How many?)

定量研究（多少？有多少？）

Use when: Need statistical validation, measuring impact Methods:

Surveys
Analytics analysis
A/B experiments
Market sizing

适用场景：需要统计验证、衡量影响力方法:

调研
数据分析
A/B实验
市场规模估算

Qualitative Research (Why? How?)

定性研究（为什么？如何？）

Use when: Understanding motivations, uncovering insights Methods:

User interviews
Focus groups
Customer advisory boards
User observation

undefined

适用场景：理解动机、挖掘洞察方法:

用户访谈
焦点小组
客户咨询委员会
用户观察

undefined

Interview Best Practices

访谈最佳实践

markdown

undefined

markdown

undefined

Preparation

准备阶段

Define research goals and hypotheses
Create interview guide (but stay flexible)
Recruit right participants (6-8 per segment)
Schedule 45-60 min sessions

定义研究目标和假设
制定访谈指南（但保持灵活性）
招募合适的参与者（每个细分群体6-8人）
安排45-60分钟的访谈

During Interview

访谈过程中

✓ Ask open-ended questions ("Tell me about...") ✓ Follow up with "Why?" 5 times to get to root cause ✓ Listen more than talk (80/20 rule) ✓ Ask about past behavior, not future hypotheticals ✓ Look for workarounds and pain points ✓ Record and take notes

✗ Don't ask leading questions ✗ Don't pitch your solution ✗ Don't ask "Would you use X?" (people lie) ✗ Don't multi-task while interviewing

✓ 提出开放式问题（“请告诉我关于...的情况”） ✓ 连续追问5次“为什么”以找到根本原因 ✓ 多听少说（80/20原则） ✓ 询问过去的行为，而非未来的假设 ✓ 关注用户的权宜之计和痛点 ✓ 录音并做笔记

✗ 不要提出诱导性问题 ✗ 不要推销你的解决方案 ✗ 不要问“你会使用X吗？”（用户可能会撒谎） ✗ 访谈时不要一心多用

Example Questions

示例问题

"Walk me through the last time you [did task]"
"What's most frustrating about [current solution]?"
"How are you solving this problem today?"
"What would make [task] easier for you?"
"Tell me more about that..."

undefined

“请告诉我你最近一次[完成某任务]的全过程”
“[当前解决方案]最让你头疼的是什么？”
你现在是如何解决这个问题的？”
“什么能让[该任务]对你来说更简单？”
“请再详细说说这一点...”

undefined

Survey Best Practices

调研最佳实践

markdown

undefined

markdown

undefined

When to Survey

何时开展调研

✓ Validate findings from qualitative research ✓ Measure satisfaction or sentiment at scale ✓ Prioritize features (Kano surveys) ✓ Segment users by behavior/needs

✓ 验证定性研究的发现 ✓ 大规模衡量满意度或情绪 ✓ 功能优先级排序（Kano调研） ✓ 按行为/需求细分用户

Survey Design

调研设计

Keep it short (<10 min to complete)
One question per screen on mobile
Mix question types (multiple choice, scale, open-ended)
Avoid leading or biased questions
Test survey with 5 people before sending

保持简短（完成时间<10分钟）
移动端每页一个问题
混合问题类型（选择题、量表题、开放式问题）
避免诱导性或有偏见的问题
发送前先让5人测试调研内容

Question Types

问题类型

Multiple choice → Segmentation, categorization
Likert scale (1-5) → Satisfaction, importance
Open-ended → Qualitative insights
Ranking → Prioritization
NPS (0-10) → Loyalty measurement

选择题 → 细分、分类
李克特量表（1-5分） → 满意度、重要性
开放式问题 → 定性洞察
排序题 → 优先级排序
NPS（0-10分） → 忠诚度衡量

Distribution

分发渠道

In-app surveys (high response, biased to engaged users)
Email surveys (broader reach, lower response)
Incentivize thoughtful responses ($10 gift card, early access)
Follow up with interviews for interesting responses

---

应用内调研（响应率高，但样本偏向活跃用户）
邮件调研（覆盖范围广，响应率低）
激励有质量的反馈（10美元礼品卡、提前体验权限）
针对有趣的回复跟进访谈

---

2025 Trends in Product Discovery

2025年产品发现趋势

AI-Powered Research

AI驱动的研究

markdown

undefined

markdown

undefined

AI Tools for Discovery

产品发现AI工具

Insight synthesis — AI analyzes interview transcripts, identifies patterns
Synthetic personas — AI-generated user proxies for rapid testing
Market intelligence — AI tracks competitor moves, pricing changes
Survey analysis — Automated sentiment analysis, theme extraction
Trend detection — AI identifies emerging market trends early

洞察合成 —— AI分析访谈转录文本，识别模式
合成用户画像 —— AI生成用户代理用于快速测试
市场情报 —— AI追踪竞品动态、价格变化
调研分析 —— 自动情绪分析、主题提取
趋势检测 —— AI提前识别新兴市场趋势

Examples

示例工具

Crayon → Competitive intelligence automation
Glimpse → Trend detection from web data
Delve AI → Automated persona creation
Attest → AI-powered survey insights
Quantilope → Machine learning research automation

Crayon → 竞品情报自动化
Glimpse → 基于网页数据的趋势检测
Delve AI → 自动生成用户画像
Attest → AI驱动的调研洞察
Quantilope → 机器学习研究自动化

Best Practices

最佳实践

✓ Use AI to scale research, not replace human insight ✓ Validate AI findings with real user conversations ✓ Combine AI analysis with qualitative depth ✗ Don't rely solely on synthetic users ✗ Don't skip talking to real customers

undefined

✓ 用AI扩大研究规模，而非替代人类洞察 ✓ 用真实用户对话验证AI发现 ✓ 结合AI分析与定性深度研究 ✗ 不要仅依赖合成用户 ✗ 不要跳过与真实客户沟通

undefined

Continuous Discovery at Scale

规模化持续发现

markdown

undefined

markdown

undefined

Modern Approach

现代方法

Discovery is embedded in every sprint, not a phase
Weekly user touchpoints (interviews, tests, feedback)
Rapid experimentation (dozens of tests running)
Fast pivots based on evidence (days, not months)

产品发现嵌入每个冲刺阶段，而非独立阶段
每周与用户互动（访谈、测试、反馈）
快速实验（同时运行数十个测试）
基于证据快速调整（以天为单位，而非月）

Team Structure

团队结构

Product trios own discovery for their area
Centralized research team supports (tools, methods)
Customer success shares feedback loop
Data analysts provide quantitative insights

产品三人组负责各自领域的产品发现
中央研究团队提供支持（工具、方法）
客户成功团队提供反馈闭环
数据分析师提供定量洞察

Cadence

节奏

Weekly: Customer interviews, prototype tests
Bi-weekly: Opportunity review, assumption validation
Monthly: Market analysis, competitive review
Quarterly: Strategic discovery (new markets, big bets)

---

每周：用户访谈、原型测试
每两周：机会评审、假设验证
每月：市场分析、竞品复盘
每季度：战略发现（新市场、重大赌注）

---

Opportunity Solution Tree

机会-解决方案树

What It Is

定义

Visual framework for mapping the path from outcome to solution:

        OUTCOME (Business goal)
             |
    ┌────────┴────────┐
    │                 │
OPPORTUNITY 1    OPPORTUNITY 2
    │                 │
    ├─ Solution A     ├─ Solution C
    ├─ Solution B     └─ Solution D
    └─ Solution C

用于映射从结果到解决方案路径的可视化框架：

        结果（业务目标）
             |
    ┌────────┴────────┐
    │                 │
机会1    机会2
    │                 │
    ├─ 解决方案A     ├─ 解决方案C
    ├─ 解决方案B     └─ 解决方案D
    └─ 解决方案C

How to Build One

构建步骤

markdown

undefined

markdown

undefined

Step 1: Define Outcome

步骤1：定义结果

Start with measurable business outcome Example: "Increase Day 30 retention from 20% to 30%"

从可衡量的业务目标入手示例：“将30天留存率从20%提升至30%”

Step 2: Map Opportunities

步骤2：映射机会

Discover customer needs/pain points through research Example: "Users don't understand core features"

通过研究挖掘客户需求/痛点示例：“用户不理解核心功能”

Step 3: Generate Solutions

步骤3：生成解决方案

For each opportunity, brainstorm multiple solutions Example:

Better onboarding tutorial
In-app tooltips
Interactive product tour

为每个机会 brainstorm 多个解决方案示例:

优化注册引导教程
应用内提示框
交互式产品导览

Step 4: Test Assumptions

步骤4：验证假设

For each solution, identify riskiest assumption and test Example: "Users will complete a 5-step tutorial" Test: Build simple prototype, test with 10 users

为每个解决方案识别风险最高的假设并测试示例：“用户会完成5步引导教程” 测试：构建简单原型，邀请10位用户测试

Step 5: Compare Solutions

步骤5：对比解决方案

Use evidence to choose best path forward Build what tests validate, discard what fails

undefined

基于证据选择最佳路径构建经测试验证的方案，放弃未通过的方案

undefined

Benefits

优势

✓ Visualizes multiple paths to outcome
✓ Prevents jumping to first solution
✓ Encourages broad exploration before narrowing
✓ Documents why decisions were made
✓ Keeps team aligned on priorities

✓ 可视化从结果到解决方案的多条路径
✓ 避免直接跳到第一个想到的解决方案
✓ 鼓励先广泛探索再聚焦
✓ 记录决策依据
✓ 保持团队优先级对齐

Integrating Discovery with Delivery

产品发现与交付的整合

Discovery Kanban

产品发现看板

markdown

undefined

markdown

undefined

Discovery Board Columns

发现看板列

┌─────────────┬──────────────┬──────────────┬─────────────┐ │ OPPORTUNITIES│ ASSUMPTIONS │ EXPERIMENTS │ VALIDATED │ │ │ │ │ │ │ Customer │ Riskiest │ Running │ Ready to │ │ needs we've │ assumptions │ tests │ build │ │ identified │ to validate │ │ │ └─────────────┴──────────────┴──────────────┴─────────────┘

┌─────────────┬──────────────┬──────────────┬─────────────┐ │ 机会列表│ 待验证假设 │ 进行中实验 │ 已验证方案 │ │ │ │ │ │ │ 已识别的客户需求 │ 需验证的高风险假设 │ 正在运行的测试 │ 可进入交付环节的方案 │ └─────────────┴──────────────┴──────────────┴─────────────┘

Flow

流程

Opportunities flow from research
Solutions generate assumptions to test
Experiments validate/invalidate assumptions
Validated solutions enter delivery backlog

undefined

机会从研究中产出
解决方案生成待验证的假设
实验验证/推翻假设
已验证方案进入交付待办列表

undefined

Definition of Ready

就绪标准

Before moving from discovery to delivery:

markdown

undefined

从产品发现进入产品交付前，需满足：

markdown

undefined

Discovery Checklist

产品发现检查清单

Customer problem validated (5+ interviews)
Solution tested with prototype (10+ users)
Success metrics defined and measurable
Technical feasibility confirmed by engineering
Business case approved (revenue/retention impact)
Design mocks completed and tested
Open questions resolved or explicitly acknowledged
Story broken into shippable increments

---

客户问题已验证（5次以上访谈）
解决方案已通过原型测试（10位以上用户）
成功指标已定义且可衡量
工程师已确认技术可行性
业务案例已获批（对营收/留存的影响）
设计稿已完成并测试
未解决问题已明确或已解决
用户故事已拆分为可交付的增量

---

Common Anti-Patterns

常见反模式

What NOT to Do

切勿做这些事

markdown

undefined

markdown

undefined

✗ Solution-First Discovery

✗ 先解决方案再发现

Starting with "We should build X" then finding evidence to support it → Instead: Start with outcome and problem, explore multiple solutions

从“我们应该构建X”入手，再寻找证据支撑 → 正确做法：从结果和问题入手，探索多个解决方案

✗ Episodic Research

✗ 阶段性研究

Doing discovery as a phase, then stopping when development starts → Instead: Continuous weekly discovery throughout product lifecycle

仅在某个阶段开展发现，开发启动后就停止 → 正确做法：在产品全生命周期内持续开展每周发现

✗ Confirmation Bias

✗ 确认偏差

Only talking to users who will validate your ideas → Instead: Seek disconfirming evidence, talk to churned users

仅与会验证你想法的用户沟通 → 正确做法：寻找反驳证据，与流失用户沟通

✗ Fake Validation

✗ 虚假验证

Asking "Would you use this?" and trusting the answer → Instead: Test with realistic prototypes, measure actual behavior

问“你会使用这个吗？”并相信答案 → 正确做法：用真实原型测试，衡量实际行为

✗ Analysis Paralysis

✗ 分析瘫痪

Endless research without ever shipping → Instead: Define upfront what evidence is "enough" to move forward

无休止研究却从不落地 → 正确做法：提前定义“足够”的证据标准，达到后推进

✗ Building for Everyone

✗ 面向所有人构建

Trying to solve for all users at once → Instead: Focus on specific segment, nail it, then expand

试图同时解决所有用户的问题 → 正确做法：聚焦特定细分群体，做透后再扩展

✗ Ignoring Weak Signals

✗ 忽略弱信号

Dismissing early negative feedback as "just a few users" → Instead: Treat complaints as early warning signs, investigate

---

将早期负面反馈视为“只是个别用户的问题”而忽略 → 正确做法：将投诉视为早期预警信号，开展调查

---

参考资料

reference/market-research.md — TAM/SAM/SOM, Porter's Five Forces
reference/user-research.md — Interview guides, survey methods, ethnography
reference/competitive-analysis.md — Competitive frameworks and analysis
reference/opportunity-frameworks.md — JTBD, Kano, Value Proposition Canvas
templates/discovery-template.md — Product discovery document template

reference/market-research.md — TAM/SAM/SOM、波特五力模型
reference/user-research.md — 访谈指南、调研方法、人种学
reference/competitive-analysis.md — 竞品分析框架
reference/opportunity-frameworks.md — JTBD、Kano模型、价值主张画布
templates/discovery-template.md — 产品发现文档模板