产品经理的「临界点」

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「177」篇原创敬上

大家好，我是Z哥。

大部分的互联网公司都有产品经理这个岗位。据我的观察，这个岗位其实有一个临界点。如果没达到这个临界点（60、70分的及格线），产品经理不但起不到应有的作用，甚至可能起反作用。

残酷的现实是，市场上大部分的产品经理都没有跨过这个临界点。原因有很多，机遇、态度、知识储备等等。

这个临界点是什么呢？我认为就是能不能把需求真正的给技术人员描述清楚。

在实际的工作中，产品经理主要的作用其实就是信息传递，将业务部门的想法转化成技术人员所能理解的方案进行开发。如果处理得好，起到的是粘合剂的作用，如果处理得不好，那么起到的是衰减器的作用。

在描述需求的过程中，最主要的就是「PRD」和「原型设计」。那么做好它们的思路是什么？我来分享一些我的看法，欢迎一起讨论。

PRD和原型设计这两件事恰好一件对着业务方，一件对着技术人员。前者是通过业务方的“输入”将它们转换成PRD，后者是基于PRD输出原型设计，交由技术人员来实现（当然其中还要设计制作高保真原型），其中的加工过程就是产品经理的核心工作。

你仔细想想，身边能把这两件事做到位的产品经理，基本上对TA的评价都不会太差。

/01  PRD/

PRD里主要体现的是业务逻辑，而形成一个业务逻辑的过程，主要经过两个步骤：需求获取 -> 讨论和设计。

01  需求获取

在获取需求的这一刻，我的习惯是「先做判断，然后记录下来」，经过这些年下来觉得很好用。

好记性不如烂笔头，大家都知道记录下来的好处，但是为什么要先做判断呢？

做判断的好处主要是以下两个：

1. 用简短的时间先对需求的优先级有个大致的了解。

2. 趁大脑还在热乎的对话场景中，把聊到的业务场景里的相关因素、条件梳理出来。

第一点比较好理解，就是“这个需求有没有必要做？”，“要做的话安排在什么时候？”。

关于第二点，我自己的亲身感受是，一旦我当时就草草地写了一句话来概括需求，那么如果这个需求在几周甚至几个月后才开工的话，我对当时为什么提这个需求的印象会开始模糊，甚至会觉得这个需求有啥用？不得不重新厚着脸皮去问提出者，这样就会显得自己很不专业。

记录的时候主要是写一下「问题」和「解决方案」，其实不用花太多时间。比如简单的一句话，

XXX 在用 XX 功能时，觉得存在问题 XXX和问题YYY。可以A方案改善XXX问题，B方案改善YYY问题。

这么做还有一个间接的好处是，那些你连问题都没法定义的需求，自然就被你拒掉了。比如那些提需求的人自己都说不清楚的需求。

02  讨论和设计

很多产品经理喜欢单纯的用文字表达业务逻辑，不喜欢画图，特别是流程图之类的东西，我觉得这个习惯很不好。

先不说中国汉字博大精深，不同的人可能会存在理解偏差的问题。哪怕大家理解的都没问题，对于那些流程不是那么简单的业务来说，做着做着脑子里理解的东西可能就模糊了。

在这里我推荐两个我认为最有效的图，一个是常见的流程图，另一个是时序图。

我觉得大部分的业务逻辑，通过这两个图都能表达清楚。一图胜千言，希望你能充分利用好这些利器。

另外，当你真正开始设计一个需求的具体方案的时候，难免会需要再次向提出方确认一些细节问题。这个时候除了确认细节，你还需要确认以下两件事：

1. 时间节点。包括出方案的时间节点，上线的时间节点。这个目的是，将双方的预期做一个校准，免得你这边觉得进度差不多，业务方觉得开发效率太低。

2. 方案的方向。这个目的是，只有这样才能发挥你作为产品经理的主观能动性和创造力，在双方都认可的方向上考虑解决方案，而不仅仅非得100%照着提出者的想法来实现。另外，确定下来的方向也是产品经理和技术人员评估方案可行性时作出取舍的重要参照。

/02  原型设计/

01  突出主次

一个完整的业务场景，必然是有主次的，有主线、有支线。所以我们在基于PRD做原型设计的时候，需要不断思考：

• 什么模块要突出？

• 什么模块要弱化？

• 背后的思考和原理是什么 ？

最怕的就是在一些次要的模块上大费周章，在核心模块反而草草了事。这样会导致技术人员花费过多的时间在低价值的方向上工作，最终的产品效果自然不会太好，甚至会变形。

02  保持一致性

对于某个概念，在整个原型里的体现应该是一致的，小到每个按钮的上的提示，大到一个模块。比如，不要在这个地方叫“汇总”，在另一个地方叫“合计”，这样的问题如果到处存在，给人的感觉是这个原型好乱。

另外，对于在整个产品里多次出现的模块，比如快捷登录的弹窗。有些产品经理会到处复制黏贴，这样很容易改了一个地方漏了其它地方，导致不一致。这

个时候你应该想办法把它提炼出来，让它可以复用。比如Axure里的母版功能。

好了，暂时就想到这么多，你有什么不同的想法或者有补充的，欢迎和我交流哦。

在很多公司，产品经理都是单独一个团队，并不直接与技术人员属于一个团队。在这样的情况下，其实对产品经理的要求是非常高的，PRD和原型设计上需要更加有责任心才行。如果仅仅作为一个“信息的传递者”，出现衰减是必然的。

如果产品经理没有起到粘合剂的作用，其实不如将产品经理团队划分到技术团队里。在我看来，和开发人员穿同一条裤子，总比多衰减一次更好一些。

总结一下。

这篇呢，Z哥和你分享了我对产品经理如何更好地描述需求这件事的看法。

产品经理最基本、也是花时间最多的工作就是写PRD和画原型，前者源于业务，后者输出给技术。但是做同样的事情，并不是所有产品经理都能把需求描述的准确、清楚。

要写出好的PRD，需要：

1. 认真对待需求的获取，接到需求的第一时间，做好判断和记录。

2. 在讨论和设计的时候，多画流程图和时序图。并且在和业务方确认需求细节的时候，同时明确好时间节点和方案的方向。

要做好原型设计，需要：

1. 突出主次

2. 保持一致性

希望对你有所启发。

推荐阅读：

原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）

如果你有关于软件架构、分布式系统、产品、运营的困惑

可以试试点击「阅读原文」