下面这篇文章是笔者整理分享给刚刚踏入B端产品行业的新人的关于PRD模板的内容，大家一起往下接着看看学习学习吧！

一、模板

因为贴不了链接，我先截图吧。有需要演示地址的，到时候看怎么给吧。

我的这份PRD模板有四个层级：

修订记录：文档的修订历史，记录文档版本号、修订人、修订时间、修订内容等。

全局说明：

①介绍这个系统（模块）的背景信息（解决什么问题、解决的价值是什么，或者上一层的产品规划概述等）。

②定义全局术语。

③定义全局规范，比如流程画法、原型图画法等。

版本号或迭代轮次：因为这份文档是针对某个系统（模块）的完整功能，可能包含多次迭代开发或多个版本增量开发，每个迭代或版本的功能需要归集到一起。根据不同人的习惯，也可以一次迭代或版本就写一份文档，或者迭代与版本放在另外的页面单独记录更改内容。

版本或迭代概览：

1. 介绍本次迭代要解决哪些问题，问题的背景、价值等，或者上一层级的产品规划方案、迭代计划等。
2. 本次迭代的关键用例。
3. 本次迭代的功能清单，涉及到的流程清单。

功能模块：具体每个功能模块的文件夹，比如渠道管理、订单管理等。每个功能模块下也有功能模块概览、功能模块的详细功能。在功能模块下面，首先要详细描述业务对象、业务对象关系、涉及到的业务流程、业务规则等，其次要画出原型图，并标注对应的逻辑、UI等信息。

这么说着有点抽象，等周末有空了整理一个简单的案例，结合着说应该更有体感。

重点重点：这套模板是给B端产品新人的。我这套模板只是抛砖引玉，你觉得能用的就用，觉得垃圾的就暗暗骂两句XX，不要跟我计较。

这套模板还不完整，只是把框架整理出来了，我会利用业余时间更新。

二、痛苦与困惑

1. 痛苦

我工作快9年了，做过开发、运营，在6年前转B端产品经理后一直干到现在，目前在一家营收5~10亿的公司负责数字化建设。

回想起成长历程，我认为在转型最开始的那两三年是最煎熬的。缺少体系的方法论，很多基础能力都不具备，可供参考的B端产品没能力找到。长期处于迷茫、焦虑状态，用线上线下课程、大佬写的书籍、请教前辈等方式，试图缓解焦虑。但根本没用，因为接收到的信息太多了，反而更焦虑。

我记得转型第一年，深深的无力感加上焦虑，导致我有三个多月的时间直接颓废了。不想上班，不想学习，不想出去玩儿，不想见任何人。上班能混就混，下班宅在家里看视频动漫小说，看腻了就躺在床上。

那段时间我经常晚上跑到楼栋的顶层（一般是晒衣服被子的地方），看着城市的灯光和月亮发呆，脑子里是各种幻想，用这种方式来减缓压力，还是有一定作用的。一句话总结就是：心有不甘但不想行动，压力巨大但无力改变。

在这段期间，我没遇到什么奇遇（比如看了某本书、某条金句等就豁然开朗），就是硬熬过来的。大概是习惯了就好了，也可能是某些能力需要时间的沉淀。后来了解到达克效应，我想那三个多月我大概是处于绝望之谷吧。

我问过身边的同事，大家都有这种经历，越是想提升自己的人经历的越多。我基本上每年都会有一阵儿，只不过现在被磨炼出来了，那种撕心裂肺的痛苦会减轻很多，也能适当的放松自己。

2. 困惑

在学习、实践过程中，我发现不管是学习的课程、读的书和文章，还是我自己在工作中实践经验，始终有2个最主要的问题一直驱动我成长，直到现在我仍然在探索。

重点重点：下面是我个人的观点，如果让你感觉不适，是我的问题，大家不要跟我计较。

1）B端产品的核心是什么？

或者用另一句话来问，B端产品在做规划的时候，最开始的、最坚固的起点是什么？我学习了很多的课程，贵的上万的线下课，便宜的几百的口水课，老师们讲的有干货，但始终没给我满意的回答。

有的老师没回答这个问题，讲解的是某些技巧。比如B端产品工作流程，怎么做需求调研等等。

有的老师说的不够深入，讲的是如何在开需求评审会的时候不会让技术挑战你。比如要梳理流程，推敲清楚逻辑关系，提前跟技术组长过一下方案，了解一些技术常识等等。

有的老师说会深入一些，讲的是解决你的用户/或客户的问题。比如挖掘需求，通过换岗等方式深入了解业务，尽量去做竞品分析等等。

最近这一两年，我认为逐渐有很少的B端产品的文章可能说到了核心点，那就是从企业经营角度找B端产品的核心。

不管你负责企业内部的信息化、数字化，还是在软件公司（如SaaS、传统软件等）负责给客户设计系统，B端产品经理要面临的是企业经营问题，对外的拓展，对内的管理，向外要收入，向内要利润。毕竟盈利性企业存在的第一目的是为股东赚钱，第二目的是为股东持续赚钱，第三目的是为股东持续赚大钱。

2）我该从哪里下手？

产品经理成长的不同的阶段，都会面临这个问题。你学了很多的理论，讲起来滔滔不绝，但实际让你做的时候就觉得无处下手。当一个产品新人收到需求或接到新任务时，往往采取的方法有：

1. 比较不好的，赶紧画原型。在某课程里学到的画原型的方法，需要几个页面，每个页面有几个按钮，搜索栏应该长这样，列表操作栏应该长这样，功能的逻辑说明应该放在页面的右边，要区分UI、逻辑说明，方便技术查看。
2. 稍微好一些的，按流程干活。从某课程里学到了产品工作流程，先约需求方调研需求，再设计流程，再设计功能逻辑，找导师或前辈指点指点，找需求方或者TA的老大指点指点，找技术组长指点指点，准备妥当后提交需求评审计划，然后在评审会上滔滔不绝并答疑，最终排期开发跟进进展，上线前喊着需求方一起验收一下，上线后跟踪功能使用的情况和效果，再进入到下一轮的迭代。
3. 再好一些的，关注整体设计，知道这个版本或迭代的位置。公司的产品大牛规划了公司多个产品的整体架构，你的部门拆解架构并设计了这个产品的架构，你所在的小组组长设计了负责模块的地图并输出了迭代计划。你分析了收到的需求/任务，对标到产品的哪个模块，计划在哪次迭代用什么功能解决，甚至能知道为什么优先级是这么排的。根据这些信息，跟你的领导沟通一下，这次的需求/任务要哪一次迭代做，谁来做，如果是你做那大概要怎么做。
4. 更好一些的，会建模。知道系统的本质是信息的流转，产品经理画这画那的关键就是怎么把问题分析清楚，怎么把解决方案抽象成模型，然后用技术实现模型。

我相信，很多的B端产品新人在成长过程中，都会经历我经历过的痛苦，也会面临我面临的困惑。希望各位新人要坚持，只要你热爱这个行业，你就要咬牙坚持。

我写这些的原因是想通过分享经验，能帮助你们减轻一点点痛苦，解答一点点困惑。因为工作比较忙，有空了就不定期更新，希望能达成我的目的。

转载声明

原创不易，转载请注明出处。

若发现未经授权转载者，一律举报。

注意：未经作者同意不得二次转载。