PRD写得再厚，客户为何不买账？给需求绑上业务的救命绳

《产品经营》专栏｜【产品重构OS】系列· 2/9

【阅读导航】

• 如果你是创始人或业务一号位：重点看“第一层：决策权划分矩阵”，看看公司里是不是存在“谁都能提意见，但谁都不对最终结果负责”的怪圈。
• 如果你是产研负责人：重点看“第二层”，反思下团队每天在写的文档，究竟是施工图纸，还是盲人摸象。
• 如果你是一线产品经理/研发：直接跳到文末看“明天上班就试试”，这 30 分钟能帮你挡掉一大半的无效折腾。

你好，我是老马。

窗外的夜风把没关严的窗帘吹得轻轻晃了晃。我拨弄了一下书桌上那盏老台灯，看着光晕打在手边一本泛黄的笔记本上。

上篇咱们聊完“唯交付论”之后，很多朋友群里倒苦水。大家普遍的困境是：老马，你说的对，我们确实像个内部外包团队。可是客户和老板天天催进度，我们除了拼命写文档、赶代码，还能怎么办？

这确实是个极其现实的痛点。我想起七八年前，带过的一个给某区域银行做“信贷风控平台”的项目。

当时，团队里的产品经理小张熬了整整两个星期，憋出了一份将近80页的PRD（产品需求文档）。功能清单、流程图、校验规则，事无巨细，连一个按钮的四种状态都定义得清清楚楚。评审会上，他讲得头头是道，测试和研发频频点头，大家都觉得这份文档“很专业”。

三个月后，系统顺利上线。

可没过几周，销售老李就在走廊里把我拦住了，一边抽烟一边叹气：“老马，这系统怎么回事啊？客户那边的信贷部主任打电话骂娘了，说用了咱们的新系统，一笔贷款的审批时长不仅没降，反而因为流程太繁琐，多卡了两天。明年的续保合同，悬了。”

我当时愣在那儿，后背直冒冷汗。

后来复盘我才惊觉，那份写得无比精致的80页PRD里，从头到尾，没有任何一个字提到过“审批时长”这个业务指标。