Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,55 +1,55 @@
|
||||
---
|
||||
title: "Demo Engineering"
|
||||
type: concept
|
||||
tags: [sales, pre-sales, demonstration, b2b]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Demo Engineering 是以影响力为导向的 B2B 售前演示设计方法论——先量化买家痛点，再展示产品能力，最后以客户案例收尾，将每一次演示转化为明确的商业叙事，而非功能清单罗列。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### Lead With Impact, Not Features
|
||||
1. **量化问题**：展示产品前，先用发现阶段收集的具体数据重新陈述买家痛点
|
||||
2. **先展示结果**：先呈现最终仪表盘、报告、工作流结果，再解释实现原理
|
||||
3. **逆向讲解**：等买家对结果产生反应（"这正是我们需要的"）后再回溯配置和架构
|
||||
4. **以证明收尾**：以客户参考案例或基准数据结束——镜像买家处境的具体证据
|
||||
|
||||
### Tailored Demos Are Non-Negotiable
|
||||
- 演示前必须将买家的三大痛点映射到具体产品能力
|
||||
- 识别受众类型：技术评估者需要架构和 API 深度，业务决策者需要成果和时间线
|
||||
- 准备两条路径：计划叙事 + 灵活深度探索（应对"能展示一下底层实现吗"）
|
||||
- 使用买家的术语、数据模型和流程语言，而非产品词汇
|
||||
|
||||
### The Aha Moment
|
||||
每个演示必须产生至少一个买家说出或明显想到"这正是我们需要的"的时刻。如果演示结束那一刻未出现，演示就失败了。
|
||||
|
||||
## Demo Structure Template
|
||||
```markdown
|
||||
# Demo: [Account Name]
|
||||
|
||||
## Pre-Demo: Pain Quantification
|
||||
- [从发现阶段获取的具体数据]
|
||||
|
||||
## Narrative Arc
|
||||
1. [开场：重述痛点]
|
||||
2. [中段：展示核心能力 + 痛点解决]
|
||||
3. [高潮：瞄准买家的"Aha Moment"能力]
|
||||
4. [收尾：客户参考案例]
|
||||
|
||||
## Aha Moment Target
|
||||
- [具体哪个能力对当前受众最具冲击力]
|
||||
|
||||
## Risk Areas
|
||||
- [需要准备异议处理的地方]
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[POC-Scoping]] — Demo Engineering 是 POC 执行的前置铺垫
|
||||
- [[FIA-Framework]] — Demo Engineering 输出的成果是 FIA 中 "Act" 环节的重要组成
|
||||
- [[SalesEngineer]] — Demo Engineering 是 Sales Engineer 的核心能力之一
|
||||
- [[AhaMoment]] — 是 Demo Engineering 成功的核心衡量标准
|
||||
|
||||
## Contradictions
|
||||
- 与 [[SalesDiscoveryCoach]] 在发现阶段定位上存在张力：Demo Engineering 期望在发现阶段收集到足够深的痛点数据，但 Discovery Coach 更强调以业务语言建立信任而非过早进入技术细节
|
||||
---
|
||||
title: "Demo Engineering"
|
||||
type: concept
|
||||
tags: [sales, pre-sales, demonstration, b2b]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Demo Engineering 是以影响力为导向的 B2B 售前演示设计方法论——先量化买家痛点，再展示产品能力，最后以客户案例收尾，将每一次演示转化为明确的商业叙事，而非功能清单罗列。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### Lead With Impact, Not Features
|
||||
1. **量化问题**：展示产品前，先用发现阶段收集的具体数据重新陈述买家痛点
|
||||
2. **先展示结果**：先呈现最终仪表盘、报告、工作流结果，再解释实现原理
|
||||
3. **逆向讲解**：等买家对结果产生反应（"这正是我们需要的"）后再回溯配置和架构
|
||||
4. **以证明收尾**：以客户参考案例或基准数据结束——镜像买家处境的具体证据
|
||||
|
||||
### Tailored Demos Are Non-Negotiable
|
||||
- 演示前必须将买家的三大痛点映射到具体产品能力
|
||||
- 识别受众类型：技术评估者需要架构和 API 深度，业务决策者需要成果和时间线
|
||||
- 准备两条路径：计划叙事 + 灵活深度探索（应对"能展示一下底层实现吗"）
|
||||
- 使用买家的术语、数据模型和流程语言，而非产品词汇
|
||||
|
||||
### The Aha Moment
|
||||
每个演示必须产生至少一个买家说出或明显想到"这正是我们需要的"的时刻。如果演示结束那一刻未出现，演示就失败了。
|
||||
|
||||
## Demo Structure Template
|
||||
```markdown
|
||||
# Demo: [Account Name]
|
||||
|
||||
## Pre-Demo: Pain Quantification
|
||||
- [从发现阶段获取的具体数据]
|
||||
|
||||
## Narrative Arc
|
||||
1. [开场：重述痛点]
|
||||
2. [中段：展示核心能力 + 痛点解决]
|
||||
3. [高潮：瞄准买家的"Aha Moment"能力]
|
||||
4. [收尾：客户参考案例]
|
||||
|
||||
## Aha Moment Target
|
||||
- [具体哪个能力对当前受众最具冲击力]
|
||||
|
||||
## Risk Areas
|
||||
- [需要准备异议处理的地方]
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[POC-Scoping]] — Demo Engineering 是 POC 执行的前置铺垫
|
||||
- [[FIA-Framework]] — Demo Engineering 输出的成果是 FIA 中 "Act" 环节的重要组成
|
||||
- [[SalesEngineer]] — Demo Engineering 是 Sales Engineer 的核心能力之一
|
||||
- [[AhaMoment]] — 是 Demo Engineering 成功的核心衡量标准
|
||||
|
||||
## Contradictions
|
||||
- 与 [[SalesDiscoveryCoach]] 在发现阶段定位上存在张力：Demo Engineering 期望在发现阶段收集到足够深的痛点数据，但 Discovery Coach 更强调以业务语言建立信任而非过早进入技术细节
|
||||
|
||||
Reference in New Issue
Block a user