从文档驱动到Demo驱动:产品迭代方法的重构

问题还是那些问题，但暴露的时机变了——从开发阶段提前到Demo阶段。

你是不是也这样？

需求评审效率低，返工多。第一反应是：PRD写得不够细，评审不够认真。

但问题不在人，在载体。

PRD是文字描述，业务方要"想象"产品长什么样，研发要"翻译"需求成技术方案。想象和翻译之间，信息必然损耗。PRD写得再细，业务方看着文字也想象不出实际操作会是什么样；评审再认真，研发也翻译不出交互细节的每一个分支。

所以问题在三个时间点反复暴露：业务评审时业务方发现没想全，技术评审时研发说不好实现，开发过程中交互细节持续追问。三个时间点，三次返工，越晚暴露成本越高。

一、换一个载体：先出Demo，再评审

后来我换了一种方式：先出Demo，再评审。

外数账单核算就是个典型——流程设计为创建结算→对账→核算→结算→单据录入，一开始业务说定价只有固定定价和阶梯定价。如果按传统方式写PRD评审，这个遗漏要到开发阶段甚至上线后才会暴露。但我先出了Demo，业务方操作测试时当场发现：还有外数定价无法展示和计算。这不是加字段的事，是流程里缺了一个定价类型的处理环节。

问题还是那些问题，但暴露的时机变了——从开发阶段提前到Demo阶段。 改Demo的成本远低于改代码。

Demo驱动不是不要文档——是Demo做验证，文档做沉淀。Demo减少的是"沟通型文档"，那种写了几十页业务方还是看不懂、研发还是要来问的文档。

二、"来回"才是常态

Demo先行不是一帆风顺的。"来回"才是常态，但这个"来回"不是失败，是Demo驱动的核心价值——问题在Demo阶段暴露，比在开发阶段暴露好得多。

Demo驱动的"来回"有三种模式，从表层到深层：

交互调整——最浅的"来回"。按钮位置不对、字段展示少了一列，业务方操作Demo后当场反馈，你当场改Demo。成本低、速度快，是Demo驱动的日常。

流程重构——更深的"来回"。不是加字段的事，是业务流程本身要重来。

触达跨场景频控就是一例：我以为"跨场景"是不同场景的一个渠道独立频控（促注册AI 7天2次，促授信AI 7天1次），实际是不同场景的多个渠道累计频控（促注册AI+短信+人工，7天2次）。Demo把这个理解偏差提前暴露了——如果按传统方式写PRD，这个问题要到开发甚至上线后才会发现。

抽象回退——最深的"来回"。不是流程不对，是抽象本身过度了——你对系统的拆分方式有问题。营销画布中"线"作为独立实体，工程复杂度激增，回退成附属关系。这是"抽象到位不是抽象到极致，是抽象到够用"的典型体现。

关键是判断你遇到了哪种"来回"——交互调整直接改Demo，流程重构要回到业务流程拷问，抽象回退要重新审视抽象是否到位。

三、三件事一次确认

传统方式，业务评审、技术评审、交互确认是分开的。Demo驱动，三件事一次搞定：业务方现场操作Demo看流程是否正确、操作路径是否顺畅、信息呈现是否符合预期；研发现场看和哪些系统关联、技术实现难点、具体技术选型。不需要来回传文档、等回复、再确认。

不是所有需求都适合Demo先行：新功能和交互复杂的、存量迭代改动明确的，适合Demo驱动；纯后端无界面的、紧急修复的，文档驱动更合适。

四、PM角色转变：省下的时间想方向

Demo驱动迭代后，我的时间分配发生了根本变化（切换到Demo驱动后大约三个月的体感估算）：项目维护从60%降到20%，过程风险管理从30%降到20%，思考产品方向从10%升到60%。

但这个转变不是自动发生的。如果你把省下来的时间继续用来"做更多需求"——你只是更快地救火了，并没有从救火队员变回产品设计师。

刻意动作：把省下来的时间分配给方向思考——下个月产品长什么样？这个方向对不对？而不是这个需求开发到哪了、风险能不能按时上线。

我意识到这个转变，是在那个触达跨场景频控的Demo评审会上。Demo做出来，业务方操作后说：不对，跨场景是多个渠道累计频控，不是一个渠道独立频控。这不是加字段的事——是对业务逻辑的理解就错了。如果按传统方式写PRD，这个理解偏差要到开发甚至上线后才会暴露。但Demo提前暴露了它。

那一刻我意识到：Demo最大的价值不是"快"，是"提前暴露方向性错误"。Demo省下的时间，最大的价值不是"做更多"，是"想清楚方向"。方向错了，做得越快浪费越多。

五、PRD从起点变终点

Demo驱动迭代中，PRD的角色发生了根本变化——从"驱动开发的起点"变成"验证结果的记录"。

传统方式：先写PRD，再评审，再开发。Demo驱动：先出Demo，评审验证通过，再生成PRD。PRD记录的是"已经验证过的需求"，不是"想象中的需求"。

PRD变薄了，不是因为偷懒，是因为信息载体变了。以前PRD要承载所有信息——业务流程、交互细节、边界情况、验收标准，全靠文字描述。现在Demo承载了大部分信息，PRD只需要记录Demo无法承载的部分：验收标准、关联关系、变更日志。

写在最后

文档驱动→Demo驱动，这个变化的本质不是"快了"，是问题暴露的时机变了。

但Demo驱动不是万能的：纯后端无界面的需求，文档驱动更合适；Demo先行不是一帆风顺，"来回"才是常态；PM角色转变不是自动发生的，需要刻意把省下来的时间分配给方向思考。

下次需求评审返工的时候，先别急着怪PRD不够细——问问自己：是不是载体选错了？

行动建议：

1. 先出Demo再评审：任何有交互界面的需求，先出Demo，业务方操作验证
2. 三件事一次确认：流程、交互、展示，在Demo评审中一次搞定
3. "来回"不是失败：Demo验证不通过，回到"想清楚"重新拷问，比开发阶段返工好得多
4. 省下的时间想方向：Demo减少了返工，但转变需要刻意——把时间分配给方向思考，不是接更多需求

本文是「AI实践日志·产品管理专题」第09篇。上一篇：AI工具箱——不是会多少工具，是知道什么时候用什么。下一篇：效果评估——不是"感觉变快了"，是"评审从5轮降到2轮"。

关注我，持续更新AI时代产品经理的实战方法论。