用途与适用时机
大多数演示失败的方式如出一辙：销售代表把产品能做的全部展示一遍，指望总有一点能打动客户。结果买家带着“消化不良”离场——满眼功能，却找不到一条清晰的线连回自己真正关心的问题。好的演示恰恰相反：它是一段简短、锋利的证明，说明某个具体且已量化的痛点有具体的解法。每一屏展示都在回答买家真正在问的问题：“这能解决我的问题吗？值这个钱吗？”
本技能在发现与演示之间架起桥梁。它把你在发现通话中学到的东西，转化为一份“Why This Demo”计划：对每个值得展示的痛点，量化其成本、指出根本原因，并映射到能证明问题已解决的确切演示时刻。所有没有资格进入演示的内容，都会被放进“删减清单（cut-list）”。
在以下任一情况成立时运行本技能：
- 你已有发现笔记，下一步就是演示。
- 发现阶段浮现了多个痛点，你必须决定展示什么、跳过什么。
- 此前一次演示拖得很长、铺得很宽，却没有推动交易。
- 买家（或你的经理）在问“我们打算讲什么、为什么讲这些”。
- 你发现自己正在规划一场功能巡览，而不是一次证明。
如果发现阶段实际上还没完成——如果你说不出任何一个已量化的痛点——就不要运行本技能。答案是再做一次发现对话，而不是做演示。建立在模糊痛点上的“Why This Demo”计划，只是一个加了标题的功能巡览。
操作步骤
所需输入
在构建计划前先收集以下内容。凡是缺失的数字或事实，不要编造——标记为 [CONFIRM WITH BUYER]，并把确认它作为演示前的跟进任务。
- 交易背景：公司、内部支持者（姓名 + 职位）、交易阶段、将参加演示的人。
- 发现阶段陈述的痛点——用买家自己的话，最好是通话中的直接引语或接近原意的转述。
- 与每个痛点相关的指标和基线——数量、耗时、人数、交易规模、周期长度、转化率、流失率、成本——任何能让你衡量痛点规模的数据。
- 买家期望的结果，以及在他们看来“解决了”是什么样子。
- 演示现场有哪些人，每位参会者关心什么。
- 你可以展示的、能映射到这些痛点的产品时刻（你自己关于“什么能证明什么”的知识）。
如果你对任何痛点都没有可量化的指标，请停下来，把“拿到数字”当作演示前的任务——见第 4 步。
第 1 步——列出痛点并排定优先级
把买家在发现阶段提出的每一个痛点用他们的话列出来。然后按两件事排序：它让买家付出多少代价（第 2 步），以及它对他们所说的目标结果有多核心。你不会把所有痛点都演示。目标是把演示围绕 2–3 个影响最大、验证最充分的痛点来构建。其余都是删减清单的候选。
第 2 步——用美元、ARR 或时间量化每个痛点
对每个排定优先级的痛点，给它一个数字。把痛点转化为买家能认出的成本：损失的钱、面临风险的 ARR、烧掉的小时数、占用的人力、滑掉的交易。使用买家自己的基线。用一行展示你的算术，使其可审计且保守，而不是凭空幻想出来的数字。
弱（没有数字）：“销售代表浪费时间在邮件里追着利益相关者跑。”
强（已量化）：“8 名 AE × 每周约 5 小时追利益相关者 ≈ 每周 40 小时 ≈ 损失 1 个全职销售人力，涉及约 120 万美元停滞在邮件泥潭中的管道。”
如果你无法量化一个痛点，也无法在演示前拿到数字，就把它降到删减清单——一个未量化的痛点不构成演示任何内容的理由。
第 3 步——把每个痛点与其根本原因挂钩
对每个已量化的痛点，指出其底层根本原因——产生它的机制——而不只是症状。演示必须解决原因，而不是表面。这正是证明与功能的区别所在。“交易停滞”是症状；“没有一个共享的地方让每位利益相关者都能自助获取信息，于是势头在通话之间消亡”才是你能证明已被解决的根本原因。
第 4 步——映射能证明解法的那一个确切演示时刻
对每个“痛点 → 根本原因”，找出能证明根本原因已解决的单一、具体的产品时刻。不是一个功能区域——而是一个时刻。你会点什么、买家会看到什么、这证明了什么？写成：痛点 → 金额影响 → 根本原因 → 我展示的确切内容 → 它证明了什么。
差：“展示交易室功能。”
好：“打开一个实时交易室，展示一位我们还没见过的利益相关者自助获取商业论证——证明根本原因（没有共享场所、势头消亡）已解决，也就是第 2 步中约 1 个全职人力 / 120 万美元的痛点。”
如果一个痛点没有干净的证明时刻，就诚实说明，而不是硬把一屏无关内容塞进演示。
第 5 步——构建删减清单
明确列出你不展示的功能和屏幕，以及原因。这与你要展示的内容同样重要。任何不能映射到这位买家某个已量化、已找到根本原因的痛点的东西，都归入此处。删减清单正是防止“消化不良”的关键。如果某位利益相关者问起删减清单上的东西，你可以应要求展示——但不要主动以它开场。
第 6 步——为演示排序并写出“为什么”
按影响力从高到低排列证明时刻，让演示尽早赢得注意力。然后写一两行“为什么做这次演示”，可以在演示前发给买家：你将要证明已解决的 2–3 个痛点，用他们的话，带上利害关系。这把演示设定为买家同意的证明会，而不是他们忍受的产品巡览。
产出内容
一份“Why This Demo”计划，包含：
- 排定优先级的痛点——2–3 个，用买家的话。
- 量化影响——每个痛点的美元/ARR/时间成本，附一行算术。
- 根本原因——每个痛点背后的机制。
- 证明映射——对每个痛点，确切的演示时刻及其证明内容。
- 演示顺序——证明时刻按影响力从高到低排列。
- 删减清单——刻意跳过的功能/屏幕及原因。
- “为什么做这次演示”说明——演示前发给买家的简短消息。
- [CONFIRM WITH BUYER] 事项——任何缺失的指标或基线，标记为演示前任务而非猜测。
好的标准
一份出色的“Why This Demo”计划读起来像检察官的案情陈述，而不是产品目录。展示的每一屏都能追溯到买家点名的某个具体痛点，以及让它真正疼起来的某个具体数字。买家看完演示会想“这正是我的问题，而他们刚刚向我展示了它已经消失”——而不是“产品真厉害”。删减清单比展示清单更长，而这正是重点。
起作用的迹象：
- 销售代表能用每屏一句话说明为什么这一屏在演示里。
- 幻灯片上出现的是买家自己的指标，而不是编造的行业平均值。
- 不能映射到已量化痛点的功能，永远不会进入演示现场。
- 演示比销售代表本能想要的更短——却打得更重。
- 演示前的“为什么”说明得到内部支持者一句“对，正是这些”。
偏离轨道的迹象：
- 计划是一份功能清单，痛点只是事后硬贴上去的。
- 痛点没有数字，或者数字是圆整的、夸大的、没有来源的。
- 发现到的每个痛点都入选了——什么都没跳过。
- 证明时刻是功能区域（“展示报表”），而不是证明解法的具体点击。