编辑导语：作为一名产品经理，从需求到PRD，中间还有多少纠结？，这中间到底经历了什么？作者先以熟悉又尴尬的语境对话开始，结合自身经历，倾诉了从需求到PRD，产品经理经历了什么，在想什么？

需求讨论会已进入尾声，各方终于达成了共识，与会人员纷纷露出了疲惫又满意的微笑。这时，领导对产品经理小M说道：

“小M，需求咱们已经讨论清楚了，你看，明天能给PRD吗？”

“！？”，小M一脸诧异地看着领导。

“？”，领导一脸诧异地看着一脸诧异的小M。

工作中，我经常会碰到“今天提需求、明天要PRD”，甚至“上午提需求，下午要PRD”的情况。很多时候，并不是因为项目有多么紧急。而是，相关干系人对“制作PRD”没有概念，不知道具体是在做什么，要花多少时间。

其实，不仅是其他岗位的朋友不了解。很多对产品感兴趣的朋友，因为没有实际项目经验，往往也很难有比较深入的了解。制作PRD，并不是简单的文档作业，不是把讨论好的需求直接整理成文档就好了。从需求到PRD，产品经理需要梳理、填充、完善很多内容，有很多两难的情况需要纠结、决策。

这个思考纠结的过程，非常重要，往往也非常花时间。有时候，具体把东西写出来，大概也就1个小时。但是，前面我可能得呆坐在电脑前思考一整个上午。

从需求到PRD的过程中，产品经理都在考虑些什么，纠结些什么？今天我们就来聊聊这个话题。

在进入话题之前，我们先来解读一个概念，“讨论好的需求”。

可能你也注意到了，上文有这么个“逻辑漏洞”：既然需求都讨论清楚了，产品经理还需要纠结什么？或者说，既然还存在问题需要纠结，产品经理为什么不在需求讨论会上提出来讨论？

这个嘛，大概只能说是理论和实操的差异吧。能沟通的尽量沟通清楚，这是一个无需赘言的大前提。但是，在实际工作中，不可能把所有的问题、所有的细节都讨论清楚。

大多数情况下，能把核心流程讨论清楚，并对几个重要的问题点达成共识，就已经算是非常不错了。甚至，有的时候，因为条件限制，根本没法进行深入的沟通。

比如说，不幸碰到了一个“不愿多说，让你自己去意会”的干系人。比如说，跨公司合作，或者异地团队合作，沟通只能靠电话和微信，非常受限。

所以，当我们说“需求讨论清楚”，其实可以理解为，就是确定了个大纲而已。

拿到“需求大纲”之后，产品经理还需要考虑些什么呢？

当然，还是那句话。不同产品岗位、不同项目，情况大不相同。这里，我结合自己的经验，分享几个比较有共性的点。

一、根据需求大纲，把整个交互链条梳理并完善

举个例子，假设我们要做一个抽奖活动。抽奖资格、奖品设置、抽奖概率、奖品发放等核心内容，需求讨论会上肯定会讨论清楚。

但是，这些只涉及到整个交互链条中的一小部分，还有很多空白要补充。产品经理需要从用户触达那一刻开始，通盘考虑，梳理完善。

比如说登录态判断，未登录访问怎么办？

如果是仅限特定会员参加的活动，且不宜外漏，那么访问时就需要强制跳转到登录页。否则，这个H5专题，就还需要补充一个“未登录”状态，并且得有登录指引和登录模块。

比如说用户类型判断，没有抽奖资格的用户类型访问，要怎么办？是引导用户进行指定操作，使之变成有抽奖资格的用户类型呢？还是直接告知没有抽奖资格呢？那是否需要向用户说明理由，或者留个联系客服入口？

比如说，抽奖成功/失败后的引导、抽奖结果查询、奖品发放与扣回等等。

从用户触达到所有流程走到终点，产品经理要根据需求大纲的要求，梳理完善全部的交互链条。

整个交互链条都补充完整了，这个方案才能算是“可用”。

二、结合公司产品情况，考虑需求的涉及范围

还是用上面的例子，我们要搞个H5专题，用来做抽奖活动。那么，会议讨论的核心，肯定是围绕着“H5专题”进行的。但是，产品经理的思维不能被限制住。还得考虑，公司的PC端网站，是不是也应该搞一个PC端的抽奖专题放上去？

假设背景情况是，移动端已经是发展的趋势，但是目前还有一半的流量在PC端。面对这样的情况，你觉得，PC端的抽奖专题，是做，还是不做？

当然，这里面没有标准答案，需要具体情况具体分析。但是，如果脑中只有“Yes”和“No”两个选项，那就还是被限制住了思维。

这里面有n个选项，比如说：

• PC端完全没有入口
• PC端放个广告图，附上移动端H5专题的二维码
• PC端加个入口，点击在新标签页打开移动端的H5专题
• PC端做个静态专题，仅作介绍，并附上移动端H5专题的二维码
• PC端做个和移动端一样功能的抽奖专题

可选项其实非常多，这也就是为什么产品经理需要纠结，且需要纠结很久的原因。考虑需求的涉及范围，核心是要平衡“业务需求”和“开发成本”。就像上面的例子，换一个方案，开发成本可能就得翻倍。

三、根据项目的重要性，斟酌功能的精细程度

要实现一个功能，可简单、可复杂。

具体要做到怎样的程度？需求讨论会一般不会讨论到这么细。基本得靠产品经理自己斟酌。比如说，引导关注微信公众号。

如果只是附属功能，比如在支付成功页为公众号引流，那放个二维码就差不多了（虽然对非微信环境下的访问不太友好）。如果是核心功能，或者是核心流程中必经的结点，那就得做得更加精细，优化体验，以较少流失。

可能就得这么搞：

• 微信环境下，显示二维码，引导长按识别；
• 浏览器环境下，显示二维码图片和操作指引，引导长按下载图片，并有调起微信的功能；
• APP环境下，调起小程序，在小程序中打开指定的微信图文链接，在图文中引导用户长按识别。

又比如说，查看详细地址。我曾经做过一个招聘的专题，里面自然需要有公司的所在地址。干系人提出，用户点击地址时，需要调起地图应用，定位并导航。

这体验当然很好！

但是，开发成本可能比招聘专题本身还要大，肯定是不合适的。根据其重要程度，仅在页面内显示详细地址的文本，就差不多了。如果还需再优化，再加个“点击复制地址”的功能，也还算合理。

可以看出，本质上，我们是在权衡“用户体验”和“开发成本”的关系。以前大家爱讲“追求极致”，但实际工作中，更需要“点到为止”。其中如何权衡，需要产品经理结合项目的重要程度去分析决策。

四、思考与旧模块旧功能的关系，划清需求边界

对旧模块旧功能进行调整，往往比新搞一个东西，要麻烦得多。有时候，在运行新机制时，还需要同时保持旧机制正常运转，以保证某些老用户的正常使用。同时还得有引导用户从老机制切换到新机制的功能。

当然，这些大概率会在需求讨论会上沟通清楚，不在我们今天的讨论范畴内。但是，在制作PRD的时候，你还是会发现，有很多细碎繁琐的东西要厘清。

比如说，我需要调整A类产品的价格显示样式。看起来很简单，把所有涉及到A类产品价格的地方，都调整一下，不就好了？

并非如此。

那个好多年前搞的老页面，好久没人维护了，也很少用户访问，要一起改吗？某个地方有个价格显示的bug，涉及包括A类产品在内的多种产品，这个bug要一起改吗？

像这样细碎的问题，需要产品经理一个个去排查、去权衡，非常繁琐。如果偷懒，敷衍了事，后面进入开发测试阶段，就得经常停下来协商讨论，开发进度就会经常“卡壳”。

在制作PRD的时候，产品经理需要花很多时间精力，去梳理和斟酌许多细枝末节的问题。它并不像“需求分析”那么有“价值”，所以大家谈论得比较少。

但是，这些细节，却实实在在地关系着项目的最终效果。当然，也反映了产品经理的专业水平。

#专栏作家#

简明产品论，微信公众号：简明产品论（ID：JianMingPM），人人都是产品经理专栏作家。在真实的世界里做产品。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议