客户中心产品定义 (Customer-centric Product Definition)

CPD 把零散的客户声音、销售承诺和内部想法，收敛成一份**可开发、可验证、可说“不”**的产品定义。它是 APD Gate 0/1 的核心输入。

定义错了，后面所有加速都是在错误方向上狂奔。

什么是 CPD？

客户中心产品定义（CPD）是一套在立项与需求冻结阶段使用的方法：以客户要解决的工作/痛点为中心，而不是以功能清单为中心，输出清晰的产品边界与成功标准。

CPD 要回答

1. 为谁解决什么问题？
2. 客户用什么标准判断“解决了”？
3. 我们凭什么比现状/竞品更好？
4. 做什么、刻意不做什么？
5. 技术与商业上是否站得住？

为什么研发必须会写 CPD？

研发最常见的浪费不是写代码/画图慢，而是：

• 做了客户不付钱的功能
• 规格在设计中途反复改
• 销售、研发、质量对“什么叫合格”理解不一致

CPD 让跨职能在动手前对齐同一张真相源。

CPD 一页纸（日常模板）

复制以下结构，控制在 1–2 页：

【产品 / 项目名称】
日期：        版本：        Owner：

1. 客户与场景
- 目标客户（角色/行业/规模）：
- 使用场景（何时何地做什么）：
- 当前怎么凑合（竞品/手工/替代方案）：

2. 要解决的问题（客户语言）
- 核心痛点（最多 3 条）：
- 不解决的代价（时间/钱/风险/合规）：

3. 价值主张（一句话）
- 帮助【谁】在【场景】实现【结果】，不同于【替代方案】因为【差异点】。

4. 成功标准（可度量）
- 客户侧：______（如节拍、良率、停机、人力）
- 公司侧：______（如 ASP、毛利、TTM、份额）

5. 需求边界
- Must（必须有）：
- Should（应该有）：
- Could（可以有）：
- Won't（本版本不做）：

6. 关键约束
- 成本目标 / 交期 / 认证 / 接口 / 兼容：

7. 假设与待验证
- 假设：
- 验证方法与截止日期：

8. 决策
- Go / No-Go / 需补充：          决策人：

从 VOC 到 CPD：研发怎么参与

参考 VOC 与 CI（研发亲自到现场取证的方法），研发不是等市场部丢 PRD，而是主动参与翻译：

访谈时研发可问的好问题

• 上一次失败/返工发生在哪一步？
• 你怎么判断“今天这班干完了”？
• 如果只能保留一个能力，保留哪个？
• 你愿意为哪个改进多付多少 / 等多久？

需求分层：Must / Should / Could / Won't

用 MoSCoW 防止范围膨胀：

研发日常用法：设计评审时每项功能必须能指回 Must/Should；指不回的，默认是浪费。

规格怎么写才可开发、可测试

把客户需求转成工程规格时，遵循：

1. 可观测：能量化或有明确通过/失败判据
2. 有条件：电压、温度、负载、介质写清
3. 可追溯：规格条目 ↔ 测试用例 ↔ CPD 条目
4. 有主人：每条关键规格有 Owner

反例 → 正例

CPD 评审会（60 分钟议程）

参与：产品/项目经理、研发负责人、销售代表、质量、工艺（如涉及制造）、必要时客户成功。

1. 问题与价值主张是否成立（15）
2. Must/Won't 是否对齐（20）
3. 成功标准是否可度量（10）
4. 关键假设与验证计划（10）
5. Go / No-Go 决议（5）

输出：签字或电子确认的 CPD 基线版本号。

与 APD 门禁的关系

研发个人检查清单（动手前）

• 我能用客户语言复述核心痛点
• Must 不超过真正关键的几条（通常 5–9 条）
• Won't 已写明，且销售知情
• 每条 Must 有验证方法
• 目标成本与关键约束已知
• 最大的 3 个假设有验证计划

常见误区

1. 把功能清单当 CPD — 没有问题与价值主张的清单只是愿望墙。
2. 研发不参与定义 — 后期“做不到/太贵”会反噬交期。
3. 不敢写 Won't — 不拒绝等于隐式承接一切。
4. 成功标准全是内部指标 — 客户不认的 KPI 换不来复购。
5. 基线后口头加需求 — 必须变更评估，否则 APD 形同虚设。

本周就可以做的三件事

1. 为自己负责的在研产品补写 CPD 一页纸。
2. 召集 30 分钟对齐会，只确认 Must 与 Won't。
3. 给每条 Must 补一条验证方法（测什么、谁测、何时测）。

相关工具：CI · VOC · 创新八步法 · APD · DVP&R · VPM