problem-discovery

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Problem Discovery

问题发现

Validate the problem exists before defining the solution.

This skill sits between strategic rationale (

why-strategic-rationale

) and solution definition (

business-product-leadership

). It answers: "Is this problem real, specific, and painful enough to solve?"

在定义解决方案前先验证问题是否存在。

该技能处于战略合理性（

why-strategic-rationale

）与解决方案定义（

business-product-leadership

）之间。它旨在解答：“这个问题是否真实、具体，且严重到值得解决？”

Position in the Product R&D Flow

在产品研发流程中的定位

why-strategic-rationale  →  problem-discovery  →  business-product-leadership
      (WHY layer)              (VALIDATE layer)         (WHAT layer: JTBD + MVP)

why-strategic-rationale  →  problem-discovery  →  business-product-leadership
      (WHY 层)              (VALIDATE 层)         (WHAT 层: JTBD + MVP)

The Multi-Signal Discovery Framework

多信号发现框架

Use ≥ 2 signals. Confidence accumulates across signals — no single method is sufficient.

需使用≥2种信号。置信度会随信号数量累积——单一方法不足以支撑判断。

Signal 1 — Customer Interviews (Always Required)

信号1 — 用户访谈（必选）

Ground truth. Everything else is proxy data.

Protocol:

Talk to 5–10 people who represent the target segment
Ask about past behavior, not hypothetical future intent
Key questions:
- "Tell me about the last time you experienced [problem area]."
- "How did you solve it? What was frustrating about that?"
- "How much time/money does this cost you?"
Red flag: "I would use that" — this is intent, not evidence
Green flag: "I spent 3 hours last week doing X manually" — specific, quantified past pain

Output: Verbatim quotes + frequency count of recurring pain themes

最真实的依据，其他所有数据均为代理数据。

执行规范：

与5-10名代表目标用户群体的人员沟通
询问过往行为，而非假设性的未来意向
核心问题：
- “请告诉我你最近一次遇到[问题领域]时的情况。”
- “你是如何解决的？过程中有哪些令人沮丧的地方？”
- “这个问题会花费你多少时间/金钱？”
红色预警：“我会用这个”——这只是意向，而非证据
绿色信号：“上周我花了3小时手动完成X任务”——具体、可量化的过往痛点

输出： 逐字引用内容 + 重复出现的痛点主题频次统计

Signal 2 — Labor Market Research (LMR)

信号2 — 劳动力市场调研（LMR）

Best for B2B / developer tools. Job postings reveal what companies are actively paying to solve.

Protocol:

Search job boards (LinkedIn, Indeed, specialized boards) for roles related to the problem domain
Identify recurring skill requirements → these are manual tasks ripe for automation
Check hiring volume trend (growing demand = problem getting worse, not better)
Validate compensation bands → high pay for scarce skill = strong demand signal

Example: 500+ job postings for "data pipeline engineer" with manual ETL skills = demand for automation tooling.

Limitations: Only works when the problem is currently solved by human labor. Not valid for consumer products or novel problem categories.

Output: Hiring volume + skill gap + estimated market size

最适用于B2B/开发者工具类产品。招聘启事能体现企业正积极付费解决的问题。

执行规范：

在招聘平台（LinkedIn、Indeed、垂直领域招聘板）搜索与问题领域相关的岗位
识别重复出现的技能要求——这些是适合自动化的手动任务
查看招聘量趋势（需求增长=问题正在恶化，而非好转）
验证薪酬区间——稀缺技能对应高薪=强烈需求信号

示例： 500+招聘“数据管道工程师”的岗位要求手动ETL技能=自动化工具存在需求。

局限性： 仅适用于当前由人力解决的问题。不适用于消费产品或全新问题类别。

输出： 招聘量 + 技能缺口 + 估算市场规模

Signal 3 — Landing Page / Smoke Test

信号3 — 着陆页/烟雾测试

Measures behavioral intent, not stated preference.

Protocol:

Build a landing page describing the product (1–2 days max, no actual product)
Drive traffic via relevant communities (Reddit, HN, Slack groups, LinkedIn)
Measure: sign-up rate, email capture, waitlist conversion
Threshold: >5% conversion on cold traffic = strong signal

Smoke test variant (Wizard of Oz): Fake the product entirely. Take orders manually. See if anyone tries to use it before you build.

Output: Conversion rate + qualitative feedback from sign-ups

衡量行为意向，而非口头偏好。

执行规范：

搭建一个描述产品的着陆页（最多1-2天，无需实际产品）
通过相关社区（Reddit、HN、Slack群组、LinkedIn）引流
衡量指标：注册率、邮箱捕获量、等待列表转化率
阈值： 冷流量转化率>5%=强烈信号

烟雾测试变体（绿野仙踪法）： 完全模拟产品，手动处理订单。查看是否有人在你开发前就尝试使用。

输出： 转化率 + 注册用户的定性反馈

Signal 4 — Competitor & Proxy Revenue Analysis

信号4 — 竞品与替代方案营收分析

If others are solving the adjacent problem and making money, the problem is real.

Protocol:

Find closest competitor or substitute solution
Check: App Store ratings (high ratings + "wish it did X" reviews = gap), G2/Trustpilot reviews, job postings at competitor companies
Estimate competitor revenue via SimilarWeb traffic × industry conversion rates
Look for underserved segments: competitors with 3-star average in one niche

Output: Competitor landscape + underserved segment identification

如果已有其他厂商在解决相邻问题并盈利，说明该问题真实存在。

执行规范：

找到最接近的竞品或替代解决方案
查看：应用商店评分（高评分+“希望它能做X”的评论=存在缺口）、G2/Trustpilot评论、竞品公司的招聘启事
通过SimilarWeb流量×行业转化率估算竞品营收
寻找未被满足的细分群体：在某个细分领域平均评分为3星的竞品

输出： 竞品格局 + 未被满足的细分群体识别

Confidence Assessment

置信度评估

After running ≥ 2 signals, assess overall confidence:

Level	Criteria	Next Step
High	2+ signals agree, verbatim quotes quantify pain, competitors exist and are profitable	Proceed to JTBD definition
Medium	1 strong signal + 1 weak, pain is real but scope unclear	Run 1 more signal before JTBD
Low	Signals conflict or are weak, pain is theoretical	Do not proceed — pivot problem statement or abandon

在获取≥2种信号后，评估整体置信度：

等级	判断标准	下一步行动
高	2+信号一致，逐字引用内容量化痛点，竞品存在且盈利	推进JTBD定义
中	1个强信号+1个弱信号，问题真实但范围不明确	在定义JTBD前再获取1种信号
低	信号冲突或薄弱，痛点仅为理论层面	停止推进——调整问题陈述或放弃

Output: Problem Statement

输出：问题陈述

markdown

undefined

markdown

undefined

Problem Statement — [Domain/Initiative Name]

Date: YYYY-MM-DD Confidence: High / Medium / Low

The Problem

[1 sentence: who has the problem, what it is, what it costs them]

Evidence

Signal	Finding	Strength
Customer interviews (N=X)	[Key quote or pattern]	Strong / Weak
LMR	[Job volume, skill gap]	Strong / Weak
Landing page	[Conversion rate]	Strong / Weak
Competitor analysis	[Gap found]	Strong / Weak

Signal	Finding	Strength
Customer interviews (N=X)	[Key quote or pattern]	Strong / Weak
LMR	[Job volume, skill gap]	Strong / Weak
Landing page	[Conversion rate]	Strong / Weak
Competitor analysis	[Gap found]	Strong / Weak

The Segment

[Who specifically has this problem most acutely? This becomes the beachhead.]

Kill Criteria

[Condition that means "this problem isn't real enough to solve"]

[Condition that means "this problem isn't real enough to solve"]

Open Questions

[Assumption still unvalidated that could change direction]

---

[Assumption still unvalidated that could change direction]

---

Ecosystem Connections

生态关联

Requires upstream →
```
why-strategic-rationale
```
: WHY Statement gives the strategic hypothesis that problem-discovery validates empirically
Feeds downstream →
```
business-product-leadership
```
: Problem Statement → JTBD definition → Core Domain mapping → MVP scope
Feeds downstream →
```
diffusion-release-tracking
```
: Segment identification → beachhead for Innovator/Early Adopter gates
Feeds downstream →
```
ddd-core
```
: Problem scope → Core Domain boundary

上游依赖 →
```
why-strategic-rationale
```
: WHY陈述提供战略假设，问题发现会通过实证验证该假设
下游输出 →
```
business-product-leadership
```
: 问题陈述 → JTBD定义 → 核心领域映射 → MVP范围
下游输出 →
```
diffusion-release-tracking
```
: 细分群体识别 → 创新者/早期采用者阶段的切入点
下游输出 →
```
ddd-core
```
: 问题范围 → 核心领域边界

Anti-Patterns

反模式

Anti-pattern	Why it fails	Fix
Interviews only	Confirmation bias — people tell you what you want to hear	Combine with behavioral signal (landing page or LMR)
LMR only	Measures yesterday's problem, not tomorrow's opportunity	Validate with interviews to confirm pain is acute today
Survey instead of interview	Surveys answer "what", not "why"	Replace with open-ended 30-min conversations
Building before any signal	Sunk cost blinds you to negative evidence	Min 2 signals before writing production code
"Everyone I talked to loved it"	Selection bias — you talked to friends	Recruit strangers from target segment
Skipping Low-confidence problems	Feels like wasted time	A clear NO saves months of building the wrong thing

反模式	失败原因	修复方案
仅依赖访谈	确认偏差——人们会说你想听的内容	结合行为信号（着陆页或LMR）
仅依赖LMR	衡量的是过去的问题，而非未来的机会	通过访谈验证当前痛点是否严重
用问卷替代访谈	问卷只能回答“是什么”，无法回答“为什么”	替换为30分钟的开放式对话
未获取任何信号就开始开发	沉没成本会让你忽视负面证据	至少获取2种信号后再编写生产代码
“我交谈过的所有人都喜欢这个想法”	选择偏差——你交谈的是朋友	从目标用户群体中招募陌生人
跳过低置信度的问题	感觉是浪费时间	明确的“否定”能避免数月时间投入到错误的事情上