| name | demand-psychology-mining |
| description | 当用户面对“用户说要某功能”“竞品都有”“我有个好点子”“要不要做已读/分组/导入/滤镜/提醒”等需求判断时调用，用于挖出表层功能背后的心理诉求、群体效应和真实驱动力。
不适用于: 明确 bug、合规必做项、已验证的工程需求。
|
| source_book | 《微信背后的产品观》 张小龙 |
| source_chapter | 需求篇 |
| tags | ["product","demand","psychology"] |
| related_skills | ["human-group-sensing","scenario-boundary-design"] |
需求背后心理诉求挖掘
R — 来源
原书依据见本节来源说明。
依据《需求篇》中关于否定新点子、不照搬用户说法、寻找心理诉求，以及漂流瓶、附近的人、摇一摇、朋友圈、Web 微信等案例。
I — 方法论骨架
用户说出的需求通常是解决方案，不是根因。
产品经理要先否定点子，再反问它背后的心理驱动力是否真实、普遍、强烈。
真实驱动力常常来自倾诉、好奇、随机性、存在感、隐私、安全感、怕落伍、想省力、想被朋友看见。
一个好需求不一定由用户提出，但应该能解释用户为什么会自发使用和传播。
如果需求只能在竞品、会议讨论或产品经理想象中成立，它还没有通过心理层验证。
A1 — 书中的应用
案例: 漂流瓶
- 问题: 漂流瓶看似是交友功能，容易被误解。
- 方法论的使用: 作者把它解释为倾诉、发泄和好奇，而不只是交友。
- 结论: 默认语音更贴合随时释放情绪的心理。
- 结果: 功能从“交友工具”变成“低风险倾诉机制”。
案例: Web 微信
- 问题: 用户说想要 PC 版。
- 方法论的使用: 作者区分“PC 版”与“键盘输入”这两个不同需求。
- 结论: 真诉求是解决手机输入负担，而不是复制 PC 在线状态。
- 结果: Web 微信被定位为连接键盘，而非完整 PC 版。
A2 — 触发场景
- 用户问一个新功能该不该做。
- 用户给出竞品功能或用户反馈，希望判断是否跟进。
- 用户想从“功能需求”挖到“心理诉求”。
- 用户需要判断一个功能是否能带来“爽”“好玩”或自传播。
语言信号
- “用户说想要”
- “竞品都有这个功能”
- “这个需求是真的吗”
- “背后的心理是什么”
- “为什么用户会主动用/传播”
与相邻 skill 的区分
- 与
human-group-sensing 的区别: 本 skill 聚焦单个需求的心理根因。
- 与
scenario-boundary-design 的区别: 本 skill 先判断需求是否真实，后者再决定如何做、藏、延后或不做。
E — 可执行步骤
-
改写表层需求
- 完成标准: 把“用户要 X 功能”改写成“用户想避免/获得/表达/确认 Y”。
-
寻找心理驱动力
- 完成标准: 至少判断是否涉及省力、存在感、隐私、好奇、随机性、倾诉、怕落伍、社交压力。
-
验证群体潜力
- 完成标准: 判断该诉求是否可能形成群体效应或口碑传播，而不只是个体抱怨。
-
给出需求判定
- 完成标准: 输出
做 / 不做 / 延后观察 / 换一种更抽象方案，并说明为什么。
B — 边界
- 明确 bug、法律合规、安全修复不应被“心理诉求”分析拖延。
- 不把用户的所有痛苦都解释成情绪需求，有些就是流程或性能问题。
- 不以“用户不会表达”为理由傲慢否定所有反馈。
- 专业工具和企业软件需要结合任务效率、责任链和审计需求。
失败模式
- 用户说什么就做什么。
- 竞品有什么就补什么。
- 产品经理说“我有个好主意”就推进。
- 把省钱、效率等表层价值误认为足够强的传播驱动力。
相关 skills
- depends-on: {human-group-sensing}
- composes-with: {scenario-boundary-design, product-structure-evolution}
- contrasts-with: {feature-request-triage}
审计信息
- 源文件:
wechat-product-philosophy-skill/source/SOURCE.md
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 测试通过率: 待 darwin 运行
- 蒸馏时间: 2026-06-14
