本文探讨了产品经理在产品开发过程中应该编写PRD（产品需求文档）还是用户故事的选择问题，提供了深入的见解和建议，引导阅读，希望对你在产品管理领域的实践有所帮助。

产品经理最基本的技能之一是编写需求，但应该怎样编写需求呢？我搜索了“产品经理如何整理需求”的词条，发现主要有以下四类方式。

1. 需求文档（PRD）。这是目前最主流的方式之一。网络上有很多PRD格式分享、撰写PRD的培训等等。
2. 以用户为中心的PRD。因为PRD主要以描述功能细节为主，随着“用户为王”的意识越来越强烈，PRD中开始加入目标用户的部分，做用户细分、用户画像、用户流程，希望弥补用户导向的缺失。
3.  直接在原型软件中写PRD的“一体化原型”。慢慢的用户、或者项目相关干系人会发现word版的PRD中描述的功能，最后开发出来的往往和想象的不一样，和定稿的原型有诸多不对应的地方。于是部分产品经理开始以原型为中心，详细描述该原型页面的功能情况，这样可以比较大程度保证所见的、所约定的，就是开发出来的结果。
4. 用户故事。通过名字就可以看出这是一种完全以用户为导向的需求编写方式。这样的需求是一个故事线，讲述了用户可以通过将要开发的这个特征、这个功能实现什么，从而明确这一个用户故事对用户、对整个项目的价值。

我个人倾向于写用户故事。前三种需求编写方式在我看来依然脱离不了PRD的影子，所以下面我将根据我的个人经验，对比PRD和用户故事，分享一下更喜欢用户故事的原因。先放一张PRD和用户故事的对比图，方便不了解这两者的朋友有个基本的概念，后面会做具体的对比分析。

2018年我在一家外企刚开始做产品经理时，接受了用户故事的培训。我当时问我老板为什么我们不写PRD（产品需求文档）？因为我所了解到的这个职位是要写BRD、MRD、以及PRD的。我当时看了一下这几个文档的格式和页数，感觉比写用户故事要高大上的多，看上去也更专业，因为要写好几个几十页的文档呢。

当时我在工作中已经能够熟练的编写用户故事了，有新的需求，就按照用户故事given, when, then的格式写好就可以了，感觉没什么挑战性了。

而且我也并没有听懂用户故事中的vertical slice（垂直切片）是什么，也不明白面向用户做端到端的交付的真正意思。所以我虽然理所当然的写了接近四年的用户故事，但一直觉得PRD或许是一种更好的描述需求的方式。

后来去到一家民企，发现他们在使用PRD。刚开始觉得这只是编写需求的不同方式，也挺开心可以尝试一下PRD这种需求写作格式的。但是当迭代需求时，我的一个同事把“允许用户分章节下载”的需求放在整整6页的word里给我时，我是懵的。第一眼就是完全看不下去，因为看了前三页都看不到重点。

项目的背景，产品介绍等参与项目的人都应该是很熟悉的了，却占据了主要的位置。

等到终于在第4页找到新增功能部分时，发现被写下来需求仅仅是“该功能包括1，2，3部分”的描述。

具体这个功能是怎么设计的，用户是怎么使用的，并没有指出来。这样的文档还要给用户审核，用户批准后再开发。但其实用户最终得到的是一个黑盒子的功能交付，用户其实完全不知道这个功能真正长什么样子，最后还需要再花时间去给用户培训。

当然，后面我看了其他PRD文档的案例，得知这只是一个特别坏的个例。大多数的PRD还是会有交互式原型说明产品功能的。

但当我仔细看这些PRD文档时，我还是发现PRD和用户故事是有本质区别的。之前我是一直不理解vertical slice用户故事中vertical的目的和意义，直到我看到了上面那个很差的“允许用户分章节下载”的PRD的例子。我在这6页word的PRD文字里是完全看不到这个功能被用户使用起来是什么样子的，甚至这个功能长什么样子我也想象不出来。这时候我才明白一个功能点为什么要写成垂直切片用户故事了。

这并不仅仅是为该功能点明确他的用户是谁，更是明晰这个用户是如何使用这个功能的。如果这一点能够做到足够简单、直白，那所有参加项目的人一眼就能看到这个功能点对于某用户的价值：用户这样操作这个功能，是不是对该用户、对该阶段的项目目标增加价值的。

所以用户故事垂直切片的一端是直接交付用户价值的，而不是到这个具体功能点的细节部分就截止了。

PRD中的具体功能点对用户的增值部分、对项目的增值部分我认为是缺失的。PRD更多的是在大的层面描述项目的价值。例如PRD的前一部分肯定会写项目背景、项目意义、项目目标等等内容。甚至PRD之前还会有BRD、MRD等充分支持这个项目存在的合理性。证明项目是有意义、有价值的。

这在任何公司、任何项目上都是必要的，否则某个项目早在倡议阶段就被砍掉了，大家就不会坐下来一起做这个项目了。

那么问题来了，在确认某个项目是有意义、有价值的时候，具体到产品上、具体到产品的某一个功能上，我们怎么确定它是有意义和价值的呢？

我们可以做竞品调研，看看别人做了ABCD哪些功能；也可以做用户访谈看用户说他们需要ABCDEFGH哪些功能；以及通过用户描述的问题和不便，看是否可以由IJKLMN等功能点解决这些问题。

然后我们把以上得到的这些ABCDEFGHIJKLMN功能点都列出来，筛选出优先级高的ABCDEFMN几个功能点组合成交付的第一个版本的产品。

但进一步的问题是，我们是怎么筛选出优先级高的ABCDEFMN这几个需求的呢？用户反馈需要的急迫程度是一个参考点; 在有些公司技术实现的难易在具体开发过程中甚至会凌驾于需求优先级之上，左右需求开发的次序。

但仅仅根据用户反馈的需求优先级和技术难易程度所选出来的功能点，能完整的串成一个用户场景吗？如果我们把ABCDEFMN放在用户流程图上，发现它们都是分散的怎么办？

开发可能会最先提出质疑。在传统开发逻辑中，开发更喜欢整体的、横向的开发方式。因为他们觉得可以把某一个开发任务一起做了，例如花3天把整个产品所有涉及到用户权限的功能的权限设置都开发好。

先做高优先级的几个功能点的话，他们会觉得像是在“东一榔头、西一棒子”，每个开发任务都没做完、每个开发任务也都没做好的感觉，例如下图这样。

这个时候我们就要回到vertical slice的用户故事上来了。如果我们能保证每一个用户故事都是一个完整的用户特征点、都是一个完整的开发模块、都是用户直接能够使用的，那即使我们实现了一些高优先级、但是分散的功能点也是没有问题的。

因为这一个用户可以通过该功能完成TA的正常工作步骤，实现一个完整的 “我用这个特征点做了什么” 使用故事流程。

我们回到文章开头PRD和用户故事的对比图，可以更清晰的看出横向切片PRD和垂直切片用户故事的区别。

右侧PRD文档里包含了五大区域20多个模块，每个模块都是该产品全部内容的集合。例如产品结构图中列出的是该产品全部的功能；页面逻辑区域列出的是该产品全部页面的逻辑。PRD讲究的是大而全、扣的是细节，更多的是关注在功能的全面罗列和细节的逻辑自洽。

每个色块区域这么一层层横向罗列下来，产品形象在ppt上，在向上汇报上很容易拔高，但具体的落地则需要大量的人力和时间去反复口头沟通和敲定；也需要靠谱的开发做好项目技术上的整体架构，否则很容易产品一堆bug、代码一团浆糊。

而左侧的用户故事从标题和概述可以很容易看出是哪一个用户、哪一个功能。具体这个用户通过这个功能要做什么的细节全部列在了acceptance criteria里了，开发可以逐行按描述要求开发，后续写test case也可以直接复用大部分。

支持这一个用户故事的数据情况、相关项也都明确在了这一个用户故事中。从上到下这么一眼顺下来，感觉这一用户需求点讲的既具体而又明确。

每个功能的逻辑和数据都是相对独立的，如果出现了什么问题，既能够及时、准确的定位问题所在，也不会影响其他用户故事的开发或者使用。

例如我工资条部分编写的数据表和字段的代码仅支持工资条部分的功能，如果这里某一个字段出现问题，它并不会影响到请假申请功能相关的数据表或者字段。请假申请功能依然能够被继续开发或者使用。

从上面的对比可以看出，如果想要敏捷的迭代一个产品的特征和功能点，使用用户故事也是更具有优势的。因为每个用户故事从用户价值到代码实现都是相对模块化、相对独立的。后续修改功能或者新增功能，做产品扩展、做产品整合都会方便很多。所以综合来看，需求编写我更倾向于使用用户故事的方式。