微需求五问检测器

一句话定位

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

何时触发

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

输入

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

示例输入：

"项目负责人总要在会后再追一遍责任确认"

输出

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

五个问题

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]

综合输出格式

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 → 高价值微需求

产品方向：

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

启示：

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