产品经理怎么写PRD？先把需求想清楚

最近在一次产品咨询中，遇到了一个很典型的 PRD 问题。

为什么一份看起来「该写的都写了」的 PRD，到了评审阶段，却依然无法进入开发？

这份新人 PRD 是这样的：项目背景、需求目标、APP 端的页面和文案调整，看起来该有的「文档内容」并不少，但把它们拼在一起，并没有形成一个完整的产品方案。

更准确地说，它更像一份「APP 页面改版说明」，而不是一份可以进入开发的产品需求方案

这也是很多新人产品经理非常容易踩的一个坑。

下面就通过这个案例，拆解一下一个需求从「看起来清楚」到「真正可落地」，中间还缺少哪些关键环节。

先说一个容易让新人产生误解的问题。

很多 PRD 模板都会告诉你：项目背景、需求目标、用户分析、功能说明、原型图……于是新人很容易形成一种感觉：只要这些模块都填上了，这份 PRD 就完整了。

但实际上不是。

但它们都没有回答一个非常重要的问题：这个需求具体要怎么落地？

这中间缺失的，恰恰是产品经理最重要的一部分工作——把需求转化成产品方案。

这个案例里，需求本身是一个功能改版。但 PRD 的主要内容集中在 APP 端：哪个页面修改、哪些文案调整、哪些页面发生变化。

乍一看，好像已经把需求写得很清楚。但如果把 APP 页面全部拿掉，只问一个问题：这个业务到底是怎么流转的？就会发现，答案并不清楚。

比如涉及提现这样的业务，至少应该先把完整链路梳理出来：

这里面还会继续产生很多问题：

这些问题没有回答之前，直接开始改 APP 页面，其实是很容易出问题的。因为你只是定义了「页面长什么样」，却没有定义「这个功能怎么运行」。

因为产品经理设计的并不是几个页面。页面只是业务逻辑最终呈现出来的一个载体。

尤其是涉及提现、支付、订单、审核、权限、资金、状态流转这些业务时，页面往往只是冰山露出水面的那一部分。真正复杂的，是页面背后的：角色、流程、规则、状态和系统之间的关系。

所以拿到一个改版需求后，我更建议产品经理先别急着画页面，可以先问自己五个问题：

还有一个特别容易被新人忽略的地方：状态。

很多新人描述一个功能的时候，会习惯用：点击 → 成功。但真实业务通常远没有这么简单。

还是以提现为例，它可能存在：

甚至还可能存在：审核中、审核拒绝、已取消、超时。

不同状态下，这些都需要明确：

所以很多时候，产品经理真正需要设计的不是「这个页面放什么按钮」，而是「这个业务从开始到结束，会经历哪些状态，以及状态之间如何流转」。

这个案例还有一个很典型的问题。在后台部分，只简单写了一句：后台无需修改。

但产品经理不能仅仅用一句话把后台排除在需求之外。因为开发会继续问：为什么不用改？

如果经过分析，确实不需要改，那应该把判断依据说清楚。比如：

这样才是一个完整的产品判断。否则「后台不用改」更像一个结论，却没有告诉团队：这个结论是怎么得出来的。

如果把这次问题重新梳理一下，我认为一个功能改版至少应该经历这样一个过程：

这时候，PRD 才真正成为一个可以交给研发、设计、测试共同执行的产品方案。

我觉得新人产品经理真正需要完成的一个转变是：

以前：「需求方说要改这里，我把这里改一下。」

慢慢变成：「为什么要改？现在哪里有问题？业务应该怎么流转？改完以后会影响谁？有哪些规则和异常？最后应该如何落到产品上？」

这其实就是：从「记录需求」，到「设计方案」。

所以，PRD 写得不好，很多时候并不是文档能力的问题，甚至也不是不会画原型。而是：在开始写 PRD 之前，还没有完成产品设计。

很多新人产品经理都会经历这个阶段。刚开始接到需求时，很容易直接打开原型工具：「这个页面改一下。」然后打开 PRD：「这个文案改一下。」

所以，PRD 的完整，从来不只是文档内容的完整，更是产品逻辑的完整。

页面、流程、规则、异常场景以及上下游链路，都需要被纳入需求设计。

否则，写得再详细，也可能只是把「要改什么」写清楚了，却没有真正回答「系统应该怎么做」。