p0a-micro-needs-detector

---
name: p0a-micro-needs-detector
version: 1.0.0
description: 微需求五问检测器。团队天然偏爱"大需求"，这个 Skill 把看起来很小、但可能压得很深的问题重新看见。 基于《AI rebuild product
  needs》工具卡。
author: Max
tags: p0, 需求发现, 微需求检测
- book-skill
- needs-discovery
- micro-needs
- ai-product
requires: []
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p0a-micro-needs-detector
stage: p0a
source_book: AI rebuild product needs
source_chapter: 第1章 微需求检测

---


# 微需求五问检测器

## 一句话定位

需求池里全是大词时，用这五个问题检测那些"太小不值得做"的问题，是不是真正的产品起点。

## 何时触发

- 需求池里全是大词（"协作总控台"、"智能化升级"）
- 团队觉得"这个点太碎，不值得做"
- 你怀疑真正的问题藏在系统外补偿动作里

## 输入

一个具体场景描述（不要抽象需求，要具体事件）。

**示例输入**：
```
"项目负责人总要在会后再追一遍责任确认"
```

## 输出

五问检测结果 + 判断建议。

## 五个问题

### Q1: 这个问题是不是每天都在发生，只是每次都很小？

**检测方法**：
- 这个动作是否在不同项目/不同团队重复出现？
- 是否已经成为某些角色的"默认动作"？
- 是否很少被单独讨论，但实际频率很高？

**输出格式**：
```
频率评估: [high/medium/low]
证据: [ju体观察/数据/访谈结果]
```

### Q2: 用户是不是已经为它发展出稳定的 workaround？

**检测方法**：
- 用户是否有固定的"补救步骤"？
- 这些 workaround 是否已经被视为"正常流程"？
- 是否有人专门负责处理这些 workaround？

**输出格式**：
```
workaround 列表:
1. [workaround 描述] - 频率: [x次/天/周]
2. ...

隐性成本: [时间/精力/情绪代价]
```

### Q3: 如果不做，谁会继续默默为它承担代价？

**检测方法**：
- 这个代价是平均分摊还是由某个/某几个角色党底？
- 党底的人是否是组织中最忙或最有价值的人？
- 这种代价是否会影响他们做更重要的事？

**输出格式**：
```
承担角色: [角色名称]
承担内容: [具体代价]
机会成本: [因此错过的更重要事项]
```

### Q4: 这段负担是不是带着羞耻、疲惫或责任风险，因此不容易被主动表达？

**检测方法**：
- 用户是否会在正式场合提出这个问题？
- 是否常常被用"这就是工作"或"习惯了"带过？
- 是否涉及"这不是我该做的"或"我不想让别人知道我在做这个"的心理？

**输出格式**：
```
情绪负担: [shame/fatigue/anxiety/none]
表达障碍: [用户主动提出频率 low/medium/high]
潜台词: [用户实际会说什么来描述这个问题]
```

### Q5: 一旦系统接住它，用户体感会不会明显变轻？

**检测方法**：
- 解决后，那些党底的人是否立刻少背一层心智负担？
- 是否有人会主动说"终于不用再…了"？
- 这个改变是否可以被感知到（而不是只是数据上好看）？

**输出格式**：
```
体感变化: [dramatic/moderate/subtle/none]
关键见证: [用户可能会说的话]
价值密度: [high/medium/low]
```

## 综合输出格式

```yaml
micro_needs_assessment:
  input: "原始场景描述"
  
  q1_frequency:
    score: "high/medium/low"
    evidence: "证据"
  
  q2_workaround:
    workarounds: ["列表"]
    hidden_cost: "隐性成本"
  
  q3_bearer:
    role: "承担角色"
    cost: "具体代价"
    opportunity_cost: "机会成本"
  
  q4_emotion:
    burden: "shame/fatigue/anxiety/none"
    expression_barrier: "low/medium/high"
  
  q5_relief:
   体感_change: "dramatic/moderate/subtle/none"
    value_density: "high/medium/low"
  
  verdict:
    is_micro_need: true/false
    confidence: "high/medium/low"
    reasoning: "判断理由"
  
  recommendation:
    action: "建议动作"
    priority: "P0/P1/P2"
    next_step: "下一步"
```

## 常见误判

- **小 ≠ 深**：问题小不自动等于值得做
- **隐蔽 ≠ 高价值**：隐蔽的问题也需要验证是否真的有人在乎
- **体感变化是必要条件**：如果接住了但用户感觉不到，不是好的微需求

## 一句判断

> 微需求不靠声量成立，靠重复出现的代价成立。

## 核心概念

### 概念一：微需求（Micro-Need）

微需求不是情绪波动，也不是偶发抱怨。它是用户在现实中反复承担的一小段劳动——具体、长期、反复发生，却一直没被认真命名。

三大特征：
1. **长期存在**：不是一次性起伏，而是用户在现实中反复承担的代价。
2. **被习惯化**：用户未必天天抱怨，甚至会把它当成工作的一部分；正因被习惯化，它更难被普通需求流程看见。
3. **一旦被接住，体感变化很大**：用户未必用宏大语言夸你，但会明显感觉"终于少背一点了"。

> 来源：《AI rebuild product needs》第20章——微需求才是产品真正的起点。

### 概念二：团队为什么系统性低估微需求

产品团队长期被训练依赖"可见性"做判断——大词、大人群、大场景、大指标。微需求不具备这些特征：

- 不会成为行业热词
- 用户不容易把它总结成一句投诉
- 自然映射不到一个大功能模块
- 在 Dashboard 里也不明显

真正拉开产品差距的，往往是谁更早看见那些别人觉得"不值得看"的小负担。

> 来源：《AI rebuild product needs》第20章第1节——为什么团队系统性低估微需求。

### 概念三：AI 时代微需求第一次获得入场券

过去即使看见微需求，团队也会犹豫——实现成本太高。AI 降低了原型、流程和功能实现的门槛，那些"值得理解但不值得建造"的问题第一次获得了进入系统的机会。

如果 AI 只用来放大已可见的大需求，产品只会更快进入同质化竞争。但如果 AI 降低了处理微需求的门槛，它反而成为产品重新接近现实的机会。

> 来源：《AI rebuild product needs》第20章第4节——AI 时代微需求更值得做。

### 概念四：微需求与补偿行为的关系

系统没接住的代价不会凭空消失，而是转化成用户额外承担的劳动——这就是补偿行为（workaround）。补偿行为是微需求最可靠的信号来源：

- 会后多发一条确认消息
- 自己记一层待办
- 给自己设闹钟
- 把系统链接私存到备忘录

这些行为的存在说明：问题不只是抱怨，而是现实里已经在持续支付代价。

> 来源：《AI rebuild product needs》第19章——用户说出来的未必是需求，用户活出来的才是。

### 概念五：微需求的判断边界

不是每个微需求都值得建造。小不自动等于深，隐蔽不自动等于高价值。微需求也可能是偶发偏好、局部习惯、或某一小群用户的便利。五问法的核心不是"找到更多微需求"，而是"分辨哪些小负担真正值得进入系统"。

> 来源：《AI rebuild product needs》第20章第6节——微需求是起点，不是终点。

## 分步执行

### Step 1：场景采集——找到具体的补偿行为

**输入**：一个具体场景描述（不要抽象需求，要具体事件）

**处理**：
1. 不要从"用户想要什么"开始，而是从"用户在多做什么"开始
2. 观察用户在系统外的补偿动作：额外确认、重复记录、私下提醒、手动补位
3. 记录至少 3 个真实用户的行为案例，注意频率和触发条件
4. 区分"用户的痛苦"和"用户描述的痛苦"——后者往往已被媒介翻译过

**输出**：补偿行为清单（附频率和触发场景）

---

### Step 2：五问检测——逐项评估微需求价值

**输入**：Step 1 产出的补偿行为清单

**处理**：
对每个识别出的补偿行为/小负担，逐项过五问：
1. Q1：是不是每天都在发生，只是每次都很小？
2. Q2：用户是不是已经发展出稳定的 workaround？
3. Q3：如果不做，谁会继续默默承担代价？
4. Q4：这段负担是不是带着羞耻、疲惫或责任风险？
5. Q5：一旦系统接住，用户体感会不会明显变轻？

**输出**：五问评估结果（每项标注 yes/no + 证据）

---

### Step 3：价值判断——标记高价值微需求

**输入**：Step 2 产出的五问评估结果

**处理**：
1. ≥3 问回答"是"→ 标记为高价值微需求
2. 在需求池旁单开一列："这个点为什么虽然小，却值得做"
3. 评估体感变化等级：dramatic > moderate > subtle > none
4. 体感变化为 none 的，即使其他问题都通过，也不标记为高价值

**输出**：高价值微需求清单（附五问评分 + 体感变化等级）

---

### Step 4：代价量化——估算隐性成本

**输入**：Step 3 产出的高价值微需求清单

**处理**：
1. 对每个高价值微需求，估算补偿行为的隐性成本：
   - 时间成本：每次 X 分钟 × 每天 Y 次 × 每月 Z 天
   - 注意力成本：是否打断了更重要的工作
   - 情绪成本：是否带来焦虑、疲惫、羞耻
   - 责任风险：出错时谁被追责
2. 评估承担代价的角色是否是组织中最忙或最有价值的人
3. 估算机会成本：这些人因此错过的更重要事项

**输出**：代价量化报告

---

### Step 5：方案映射——从微需求到产品动作

**输入**：Step 3 的高价值清单 + Step 4 的代价量化

**处理**：
1. 对每个高价值微需求，思考：系统接住的最小动作是什么？
2. 区分"系统直接承接"和"系统辅助判断"
3. 不要试图一次解决所有微需求——选择代价最高、体感变化最大的 2-3 个先做
4. 设定验证指标：不是功能上线率，而是"用户是否停止了某个补偿行为"

**输出**：微需求产品化方案（附优先级和验证标准）

---

### Step 6：上线验证——30 天后回看

**输入**：已上线的微需求解决方案

**处理**：
1. 上线 30 天后，重新跑一次五问检测
2. 重点验证：用户的补偿行为是否真的消失了
3. 收集"终于不用再……了"类型的用户反馈
4. 如果补偿行为没有消失，分析是方案问题还是执行问题

**输出**：验证报告 + 迭代建议

---

## 示例 1

### 场景：会后协作中的"再多说一句"

**背景**：一家内部协作工具的产品团队，大需求很明确：自动笔记、自动任务拆解、自动同步、自动提醒。讨论时间自然都集中在这些"大功能"上。

**微需求发现**：

产品经理跟访一位项目负责人一整天后，发现一个非常小的动作：每次会议快结束时，她都会低头看一眼笔记，然后在大家开始收电脑的间隙，随口加一句："我一会儿再发个总结，大家到时候看一下。"

语气很轻，像是只加一个例行备注。

**五问检测**：

| 问题 | 回答 | 证据 |
|------|------|------|
| Q1：每天都在发生？ | ✅ 是 | 几乎每次会议结束她都会加这句话 |
| Q2：有稳定 workaround？ | ✅ 是 | 固定动作：会后再发一遍、再戳一遍人、再加一句背景 |
| Q3：谁在默默承担？ | ✅ 是 | 项目负责人自己——一旦没人加这层保险，出问题最先被追责的是她 |
| Q4：带着责任风险？ | ✅ 是 | 太碎了，不会被说成正式需求；"我多做一点就好了" |
| Q5：接住后体感变轻？ | ✅ 是 | 真正想摆脱的不是"多发一条消息"，而是"总觉得需要再加一层保险"的紧张感 |

> 五问得分 5/5 → 高价值微需求

**产品动作**：

团队没有把它包装成大功能。他们只在系统生成会后内容时，增加了一层非常轻的接受反馈：谁看到了、谁明确确认了、谁还没回复、哪些事项仍然是"发出去但没被真正接住"的状态。

**结果**：

项目负责人说了一句话："终于不用每次我自己再加那句话了。"

---

## 示例 2

### 场景：远程会议中的"再确认一眼"

**背景**：一个远程会议产品，团队在做大功能升级。有一个非常小、很容易被忽略的投诉：

> "我分享完屏幕后，总得再确认一下大家是不是真的看到了我刚才讲的那个页面。"

**微需求分析**：

这听起来小得可笑——不值得放进策略文档，也不值得单独上线关注。但持续观察后发现：

- 分享者不确定自己是否把关键内容讲清楚了
- 听众有时走神但不想打断
- 一旦会议继续推进，误解会在后续被放大

**五问检测**：

| 问题 | 回答 | 证据 |
|------|------|------|
| Q1：每天都在发生？ | ✅ 是 | 每次分享屏幕后都会发生 |
| Q2：有稳定 workaround？ | ✅ 是 | 分享者会口头问"大家看到了吗"，或者切换回上一页再问一次 |
| Q3：谁在默默承担？ | ✅ 是 | 分享者——承担"可能没讲清楚"的责任风险 |
| Q4：带着责任风险？ | ✅ 是 | 如果后续出问题，"当时分享时你没说清楚"会指向分享者 |
| Q5：接住后体感变轻？ | ✅ 是 | 不用反复确认，少一层"不知道大家有没有看到"的焦虑 |

> 五问得分 5/5 → 高价值微需求

**产品方向**：

值得解决的不是"做一个更酷的演示功能"，而是让共享状态、视图焦点、页面位置和理解确认——那些过去完全依赖人不断补位的微小动作——被系统更早接住。

**启示**：

大需求更容易表达、更容易被竞品复制、更容易快速跟进。但藏在补偿动作、微表情、犹豫和小负担里的问题，往往不会同时出现在每个团队的视野里。谁先看见，谁就有更大机会做出看起来不同、且更难被复制的产品。