demand-psychology-mining

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 — 触发场景

1. 用户问一个新功能该不该做。
2. 用户给出竞品功能或用户反馈，希望判断是否跟进。
3. 用户想从“功能需求”挖到“心理诉求”。
4. 用户需要判断一个功能是否能带来“爽”“好玩”或自传播。

语言信号

• “用户说想要”
• “竞品都有这个功能”
• “这个需求是真的吗”
• “背后的心理是什么”
• “为什么用户会主动用/传播”

与相邻 skill 的区分

• 与 human-group-sensing 的区别: 本 skill 聚焦单个需求的心理根因。
• 与 scenario-boundary-design 的区别: 本 skill 先判断需求是否真实，后者再决定如何做、藏、延后或不做。

E — 可执行步骤

1. 改写表层需求

   • 完成标准: 把“用户要 X 功能”改写成“用户想避免/获得/表达/确认 Y”。

2. 寻找心理驱动力

   • 完成标准: 至少判断是否涉及省力、存在感、隐私、好奇、随机性、倾诉、怕落伍、社交压力。

3. 验证群体潜力

   • 完成标准: 判断该诉求是否可能形成群体效应或口碑传播，而不只是个体抱怨。

4. 给出需求判定

   • 完成标准: 输出 做 / 不做 / 延后观察 / 换一种更抽象方案，并说明为什么。

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