在产品开发过程中，产品需求文档（PRD）扮演着至关重要的角色。然而，即便是经验丰富的产品经理也可能在PRD的撰写逻辑上存在误区。本文旨在深入探讨PRD撰写的核心要点，提供系统化的方法论，以确保文档的逻辑性和全面性。

最近模拟面试了几个产品同学，发现一个问题，虽然有些人已经有几年经验，但是在问到写PRD的思路时，却答得不通顺，逻辑很乱。

也不是他们不会写PRD，而是写的思路是乱的、错的，没有成体系的方法。

这还让我挺惊讶的，产品经理这个岗位，都进入下行周期了，产品的基础技能，网上已经有非常多成熟的资料，他们竟然连最最基础又核心的PRD，都没有吃透，属实有点不应该。

现在大部分公司，要求产品经理既要有高度，又要能落地，上至产品规划，下产品需求，都要干，写好PRD，对于产品经理来说，非常重要。

写PRD最重要的是什么？

我发现很多产品经理写PRD，都是从模板开始。在网上找到一个觉得很完善的模板，然后就套着模板写，模板包含什么，就写什么。

还有一些是对着原型写，大部分写的是交互说明，其实只是PRD里面的一部分而已。

01 写PRD最重要的是什么？

是逻辑啊！

PRD是分层次的，需要从不同的维度去写。

新项目和迭代的项目，侧重点又有一些不一样。

02 新项目PRD怎么写？

从0到1的新项目，最重要的是梳理清楚业务流程、系统架构和功能结构。

业务流程是整个项目设计的起点，梳理不同角色完成业务目标的过程。

业务流程可以推导出系统架构。

系统架构是把满足业务的所有系统遍历出来，再按照一定结构进行组织的过程。

每个系统又包含不同的功能，把所有功能梳理出来，可以指导后续具体的产品设计。

对于一个新项目来说，PRD的结构大致是这样的：

1、项目背景。描述当前遇到的问题，或市场机会。要达到什么目标，以及大致的方案是什么样的

2、整体说明。业务流程、系统架构、功能结构、全局通用说明（名词解释，全局交互等）

3、功能需求。按照系统→功能模块→功能点的方式，进行拆分，一个功能点就是一个设计模块

4、非功能需求。包括安全性，并发，数据统计等

03 迭代项目的PRD怎么写？

迭代项目，要么是新增功能点，要么是对已有功能点的优化。

迭代的项目，最重要的是弄清楚单个功能点的需求是怎么写的。

写PRD，很大一部分时间都是在写具体的功能，所以写好单个功能的需求非常重要。

对于单个功能点来说，主要包括以下部分：

功能描述：这个功能满足哪些用户需求，解决用户什么问题。

业务流程：用户和系统是怎么交互的，主要流程是什么，分支流程是什么，异常流程是什么。

业务规则：系统在执行逻辑判断的时候，依据的规则是什么。

界面交互：注意，写PRD一定是前面的步骤梳理清楚以后，才是写界面交互，界面交互的细节非常多，也是经常容易遗漏写不全的模块。一个功能里通常包含多个页面，写界面交互的时候，第一个是要梳理清楚各个页面之间的跳转关系，第二是要梳理单个页面里的交互。一个页面，通常包含这些部分：

– 页面描述：进入页面的默认内容，进入下一个页面后再返回，页面怎么处理。不同状态下页面的区别，进入页面的权限等。

– 字段描述：输入型表单规则，有哪些输入型，录入方式是什么，是否必填，有哪些规则。输出型的展示规则：展示哪些字段，展示的逻辑是什么。

– 交互描述：点击后跳转到哪里，界面元素有哪些变化，有哪些控件，不通状态的展示，操作权限等。

– 异常情况：网络异常、接口异常、加载超时，该怎么处理

– 埋点/日志：哪些事件要做埋点，数据怎么存

交互写多了以后，你应该能够形成一份自己的交互走查清单，以确保需求完整，类似下图的自查清单：

迭代里优化功能的需求，大概是需求的某个模块进行调整，可能是业务流程，可能是业务规则，也可能是具体的交互。

这类需求主要是要说清楚，现在用户的使用场景是什么样的，为什么要改，修改前是怎样的，修改后是怎样的。

04 写在最后

以上，提供一个写PRD的思路，对于新项目来说，重点是说清楚项目背景和整体的设计，然后再以功能为单元进行具体的设计。

对于迭代类的PRD，重点是描述每个功能的所有元素，如果是修改的话，弄清楚用户的使用场景，为什么要改，改成什么样。

实际上，PRD的具体形式，不必过于看中，可以用axure+批注，也可以用word文档，重点是逻辑，重点是思路。