with one click
p0a-micro-needs-detector
// 微需求五问检测器。团队天然偏爱"大需求",这个 Skill 把看起来很小、但可能压得很深的问题重新看见。 基于《AI rebuild product
// 微需求五问检测器。团队天然偏爱"大需求",这个 Skill 把看起来很小、但可能压得很深的问题重新看见。 基于《AI rebuild product
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p0a-micro-needs-detector |
| description | 微需求五问检测器。团队天然偏爱"大需求",这个 Skill 把看起来很小、但可能压得很深的问题重新看见。 基于《AI rebuild product |
需求池里全是大词时,用这五个问题检测那些"太小不值得做"的问题,是不是真正的产品起点。
一个具体场景描述(不要抽象需求,要具体事件)。
示例输入:
"项目负责人总要在会后再追一遍责任确认"
五问检测结果 + 判断建议。
检测方法:
输出格式:
频率评估: [high/medium/low]
证据: [ju体观察/数据/访谈结果]
检测方法:
输出格式:
workaround 列表:
1. [workaround 描述] - 频率: [x次/天/周]
2. ...
隐性成本: [时间/精力/情绪代价]
检测方法:
输出格式:
承担角色: [角色名称]
承担内容: [具体代价]
机会成本: [因此错过的更重要事项]
检测方法:
输出格式:
情绪负担: [shame/fatigue/anxiety/none]
表达障碍: [用户主动提出频率 low/medium/high]
潜台词: [用户实际会说什么来描述这个问题]
检测方法:
输出格式:
体感变化: [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: "下一步"
微需求不靠声量成立,靠重复出现的代价成立。
微需求不是情绪波动,也不是偶发抱怨。它是用户在现实中反复承担的一小段劳动——具体、长期、反复发生,却一直没被认真命名。
三大特征:
来源:《AI rebuild product needs》第20章——微需求才是产品真正的起点。
产品团队长期被训练依赖"可见性"做判断——大词、大人群、大场景、大指标。微需求不具备这些特征:
真正拉开产品差距的,往往是谁更早看见那些别人觉得"不值得看"的小负担。
来源:《AI rebuild product needs》第20章第1节——为什么团队系统性低估微需求。
过去即使看见微需求,团队也会犹豫——实现成本太高。AI 降低了原型、流程和功能实现的门槛,那些"值得理解但不值得建造"的问题第一次获得了进入系统的机会。
如果 AI 只用来放大已可见的大需求,产品只会更快进入同质化竞争。但如果 AI 降低了处理微需求的门槛,它反而成为产品重新接近现实的机会。
来源:《AI rebuild product needs》第20章第4节——AI 时代微需求更值得做。
系统没接住的代价不会凭空消失,而是转化成用户额外承担的劳动——这就是补偿行为(workaround)。补偿行为是微需求最可靠的信号来源:
这些行为的存在说明:问题不只是抱怨,而是现实里已经在持续支付代价。
来源:《AI rebuild product needs》第19章——用户说出来的未必是需求,用户活出来的才是。
不是每个微需求都值得建造。小不自动等于深,隐蔽不自动等于高价值。微需求也可能是偶发偏好、局部习惯、或某一小群用户的便利。五问法的核心不是"找到更多微需求",而是"分辨哪些小负担真正值得进入系统"。
来源:《AI rebuild product needs》第20章第6节——微需求是起点,不是终点。
输入:一个具体场景描述(不要抽象需求,要具体事件)
处理:
输出:补偿行为清单(附频率和触发场景)
输入:Step 1 产出的补偿行为清单
处理: 对每个识别出的补偿行为/小负担,逐项过五问:
输出:五问评估结果(每项标注 yes/no + 证据)
输入:Step 2 产出的五问评估结果
处理:
输出:高价值微需求清单(附五问评分 + 体感变化等级)
输入:Step 3 产出的高价值微需求清单
处理:
输出:代价量化报告
输入:Step 3 的高价值清单 + Step 4 的代价量化
处理:
输出:微需求产品化方案(附优先级和验证标准)
输入:已上线的微需求解决方案
处理:
输出:验证报告 + 迭代建议
背景:一家内部协作工具的产品团队,大需求很明确:自动笔记、自动任务拆解、自动同步、自动提醒。讨论时间自然都集中在这些"大功能"上。
微需求发现:
产品经理跟访一位项目负责人一整天后,发现一个非常小的动作:每次会议快结束时,她都会低头看一眼笔记,然后在大家开始收电脑的间隙,随口加一句:"我一会儿再发个总结,大家到时候看一下。"
语气很轻,像是只加一个例行备注。
五问检测:
| 问题 | 回答 | 证据 |
|---|---|---|
| Q1:每天都在发生? | ✅ 是 | 几乎每次会议结束她都会加这句话 |
| Q2:有稳定 workaround? | ✅ 是 | 固定动作:会后再发一遍、再戳一遍人、再加一句背景 |
| Q3:谁在默默承担? | ✅ 是 | 项目负责人自己——一旦没人加这层保险,出问题最先被追责的是她 |
| Q4:带着责任风险? | ✅ 是 | 太碎了,不会被说成正式需求;"我多做一点就好了" |
| Q5:接住后体感变轻? | ✅ 是 | 真正想摆脱的不是"多发一条消息",而是"总觉得需要再加一层保险"的紧张感 |
五问得分 5/5 → 高价值微需求
产品动作:
团队没有把它包装成大功能。他们只在系统生成会后内容时,增加了一层非常轻的接受反馈:谁看到了、谁明确确认了、谁还没回复、哪些事项仍然是"发出去但没被真正接住"的状态。
结果:
项目负责人说了一句话:"终于不用每次我自己再加那句话了。"
背景:一个远程会议产品,团队在做大功能升级。有一个非常小、很容易被忽略的投诉:
"我分享完屏幕后,总得再确认一下大家是不是真的看到了我刚才讲的那个页面。"
微需求分析:
这听起来小得可笑——不值得放进策略文档,也不值得单独上线关注。但持续观察后发现:
五问检测:
| 问题 | 回答 | 证据 |
|---|---|---|
| Q1:每天都在发生? | ✅ 是 | 每次分享屏幕后都会发生 |
| Q2:有稳定 workaround? | ✅ 是 | 分享者会口头问"大家看到了吗",或者切换回上一页再问一次 |
| Q3:谁在默默承担? | ✅ 是 | 分享者——承担"可能没讲清楚"的责任风险 |
| Q4:带着责任风险? | ✅ 是 | 如果后续出问题,"当时分享时你没说清楚"会指向分享者 |
| Q5:接住后体感变轻? | ✅ 是 | 不用反复确认,少一层"不知道大家有没有看到"的焦虑 |
五问得分 5/5 → 高价值微需求
产品方向:
值得解决的不是"做一个更酷的演示功能",而是让共享状态、视图焦点、页面位置和理解确认——那些过去完全依赖人不断补位的微小动作——被系统更早接住。
启示:
大需求更容易表达、更容易被竞品复制、更容易快速跟进。但藏在补偿动作、微表情、犹豫和小负担里的问题,往往不会同时出现在每个团队的视野里。谁先看见,谁就有更大机会做出看起来不同、且更难被复制的产品。