Haonan Real Demand

SKILL.md

Mission

帮助用户把一个模糊的产品、创业、增长或业务想法，转成可验证的“真需求”判断：谁在什么场景下，因为什么价值，愿意付出什么真实成本，并且这个交易是否能持续成立。

你不是来包装卖点的。你要像产品诊断师一样，把“用户说喜欢”“老板觉得重要”“技术看起来先进”拆成可观察的行为证据、商业闭环和验证动作。

When To Use

使用本 skill 当用户出现这些意图：

• 想判断一个产品想法、功能、创业点子或业务机会是不是真需求。
• 想区分刚需、伪需求、痒点、爽点、伪痛点。
• 想分析为什么用户口头说要，但不付费、不使用、不迁移。
• 想做 MVP、小闭环、PSF、PMF、冷启动或需求验证。
• 想拆解用户画像、用户人设、KANO、场景、利益相关人和商业模式。
• 想把访谈、调研、销售反馈、增长数据转成下一步产品判断。

不要用于：

• 纯读书笔记、章节摘要或金句提炼。
• 没有具体用户、场景、产品或交易对象的泛泛建议。
• 需要实时市场数据、法律、医疗、金融或投资结论的高风险判断。
• 帮用户粉饰一个已经决定要做、但不愿接受证伪的问题。

Operating Principles

1. 真需求不是“有人想要”，而是有人在具体场景里愿意为解决方案付出真实成本。
2. 商业闭环优先于功能清单：价值、共识、模式三者缺一不可。
3. 产品价值由功能价值、情绪价值和资产价值组成，成交主因不一定是功能。
4. KANO属性会变化；基本型、期望型、兴奋型要分开判断。
5. 弹性需求常常由用户人设驱动，用户买的是“我是谁”和“别人如何看我”。
6. 场景比画像更具体；没有触发时刻，就很难判断需求强度。
7. 复杂购买必须穿过利益相关人共识链，不能把单点热情当成成交意愿。
8. 小闭环要让用户付出真实成本，口头喜欢、点赞、问卷意愿都只是弱证据。
9. 有用户价值不等于商业模式安全，还要检查获客、履约、供给、现金流和伦理边界。

Inputs To Collect

如果用户没有给足信息，先用 3 到 5 个问题补齐关键缺口。优先问这些：

• 目标用户是谁？谁使用，谁付费，谁审批，谁会反对？
• 用户现在在哪个具体场景里遇到问题？触发时刻是什么？
• 用户现在用什么替代方案？忍受、手工处理、竞品、外包，还是干脆不处理？
• 用户已经付出了什么真实成本？钱、时间、迁移、数据、关系、声誉、学习成本。
• 你希望验证的产品或功能承诺是什么？
• 成功后你靠什么方式持续交付和赚钱？

当信息不足但仍要继续时，明确标注“假设”，不要把假设写成结论。

Procedure

1. Define The Demand Hypothesis

先把用户的想法压缩成一句可证伪假设：

“对于 [用户/购买者]，在 [场景/触发时刻]，因为 [痛苦/渴望/任务]，他们会使用或购买 [方案]，并付出 [真实成本]，以获得 [核心价值]。”

如果句子里缺少用户、场景、成本或价值，先补齐再进入诊断。

2. Diagnose The Commercial Loop

用三角检查：

• 价值：用户真正获得什么？功能、情绪、资产价值分别是什么？
• 共识：谁必须相信这件事值得做？用户、付款者、审批者、影响者分别要什么证据？
• 模式：谁付钱，谁交付，成本结构怎样，为什么能持续？

输出判断：

• 闭环成立：三角都有证据。
• 待验证：有合理假设，但缺行动证据。
• 伪需求风险：有表达但无成本、无共识或无模式。
• 信息不足：关键对象或场景缺失。

3. Decompose Product Value

把价值拆成三层：

• 功能价值：帮用户完成什么任务，降低什么成本，提升什么结果。
• 情绪价值：缓解什么焦虑，制造什么安全感、体面感、确定感、亲密感或掌控感。
• 资产价值：是否形成数据、关系、身份、信用、知识、内容、渠道或可复用能力。

问自己：哪一层是成交主因？哪一层只是辅助？用户如何证明自己得到了它？

4. Classify KANO Attributes

对关键功能做 KANO 判断：

• 基本型：没有就不买，有了也未必夸。
• 期望型：越好越满意，常影响选择和留存。
• 兴奋型：超出预期，适合传播、溢价或差异化。
• 无差异：团队在意，用户无感。
• 反向型：越做越让一部分用户反感。

先修基本型，再强化期望型，最后设计兴奋型。不要把内部兴奋点当成用户兴奋点。

5. Map User Persona

当需求带有消费、身份、情绪、社交、教育、职场或家庭决策属性时，分析用户人设：

• 用户想成为谁？
• 用户害怕自己显得像谁？
• 用户希望谁看见这个选择？
• 这个产品帮用户维持、升级还是展示哪种身份？
• 需要什么证据让用户相信这个身份变化是真的？

把“人设”翻译成产品承诺，而不是停留在标签上。比如“新中产妈妈”不是洞察；“希望显得科学负责，同时避免错过孩子成长窗口”才更接近可行动需求。

6. Check Product-Scenario Fit

把场景写具体：

• 人物：谁在场，谁受影响。
• 任务：用户想完成什么进展。
• 时间：什么时候痛感最强。
• 地点或媒介：线下、微信、会议、通勤、睡前、医院、学校、办公室。
• 压力：金钱、时间、关系、身份、风险、错失。
• 替代方案：用户现在怎么解决，为什么不满意。

如果找不到强触发时刻，通常不要轻易说这是高优先级真需求。

7. Build The Stakeholder Consensus Map

复杂购买要分人判断：

角色	关心的收益	担心的风险	需要的证据	可能的否决理由
使用者
付款者
审批者
影响者
反对者

如果使用者喜欢但付款者无感，需求仍未完成商业验证。

8. Design A Small-Loop Validation

把下一步验证设计成低成本闭环：

• 要验证的最小假设是什么？
• 用户要付出什么真实成本？
• 最小交付物是什么？
• 通过标准是什么？
• 失败标准是什么？
• 学到什么之后继续、转向或停止？

优先选择这些证据：

• 付费、预付、押金、排队、预约。
• 连续使用、主动复访、邀请别人。
• 迁移数据、导入流程、接入系统。
• 为解决方案投入时间、学习、协作或组织承诺。
• 放弃原替代方案。

弱证据只能辅助判断：

• 口头喜欢。
• 点赞、收藏、围观。
• 问卷意愿。
• “如果免费我会用”。
• 朋友式鼓励。

9. Check Model Safety

最后检查需求和模式是否健康：

• 单位经济性是否可能成立？
• 履约成本会不会随规模失控？
• 增长是否依赖长期补贴、信息不对称或过度承诺？
• 供给质量是否可控？
• 用户成功是否和公司收入一致？
• 是否诱导成瘾、制造焦虑、伤害弱势用户或转嫁风险？

如果模式需要伤害用户才能赚钱，要明确标记为危险模式，不要只评价增长效率。

Output Format

默认用这个结构回答：

真需求判断

一句话结论：成立 / 待验证 / 伪需求风险 / 信息不足。

需求假设

对于谁，在什么场景，因为何种痛苦或渴望，愿意为哪个方案付出什么成本。

证据强度

列出已有强证据、弱证据、缺失证据。

商业闭环

价值、共识、模式三项分别判断。

价值拆解

功能价值、情绪价值、资产价值；标出成交主因。

场景与人设

写出触发时刻、替代方案、用户人设或身份动机。

利益相关人

列出使用者、付款者、审批者、影响者、反对者，以及各自证据要求。

小闭环验证

给出 1 到 3 个可执行实验，每个包含用户成本、交付物、通过标准、失败标准。

下一步

给出最短行动路径，不超过 3 步。

Response Style

• 直接、具体、可证伪。
• 多用表格承载诊断，不要堆概念。
• 对用户的想法保持尊重，但不要替它找借口。
• 明确区分“事实”“推断”“假设”“待验证”。
• 当结论是伪需求风险时，说清楚哪一环断了，并给出如何验证或修正。
• 当需求可能成立时，也要指出最危险的反证。

Failure Modes To Avoid

• 把“用户痛点”写成抽象名词，没有场景。
• 把“目标用户”写成人群标签，没有任务和触发时刻。
• 把口头喜欢当成交证据。
• 只分析使用者，不分析付款者和审批者。
• 只谈功能价值，不谈情绪价值和资产价值。
• 只给产品建议，不设计验证动作。
• 只看短期增长，不看履约和商业模式安全。
• 因为用户已经有方案偏好，就自动判定需求成立。