上一篇我分享了一个初阶产品经理所具备的“软实力”，下面我为大家介绍下必备的“硬实力”是哪些？

之前有人比喻说，产品经理就是一个团队的小CEO，需求怎么做，得由产品经理定。

其实这倒不是因为产品经理权利有多大，而是因为产品经理所代表的是业务的诉求，所以任何逻辑、功能点、权限的设计问题一定是要产品同学来（背）拍（锅）板的。

研发同事们在开发过程中经常在群里艾特我：“是PM让这么干的”“PM给个逻辑吧”“PM你们决定到底怎么做吧。”

每次遇到这种等着我拍板的情况，真让我瑟瑟发抖……

俗话说的好，背不好锅的PM不是一个优秀的PM，那作为一个优秀的初阶PM，需要具备哪些的专业能力呢？要想回答这个问题，就得要知道，产品经理每天都在干些啥？

首先我们同步一个流程，产品同学要完成一个完整的功能迭代需要经过以下这些环节：

• 需求沟通 → 沟通能力
• PRD输出&原型绘制 → 需求文档撰写能力、原型基本功
• 产品组内需求评审 → 沟通能力、抗压能力
• 开发评审&排期 → 沟通能力、抗压能力
• 测试用例评审 → 逻辑能力
• 开发&提测&测试 → 项目推动能力
• 验收 → 细心
• 效果回归 → 数据分析能力

这么总结下来，一目了然，一个小白产品所具备的核心硬实力大致分为四个模块，即PRD撰写能力、AXURE绘制能力、项目管理能力以及数据分析能力。

01 PRD撰写的能力

PRD（Product Requirement Document）即产品需求文档，要想了解，PRD到底是个什么东西，就要问问自己这几个问题：

问：PRD给谁看？

答：PRD是产品提供给开发、测试同学看的

问：PRD用来干嘛

答：PRD是产品用来告诉开发这次需求是要实现什么功能、怎么实现、实现效果

问：PRD写的时候有什么要求吗？

答：没有特殊的规定，本着“把话说清楚”的原则，把这次需求的背景、目前的现状、以及实现的方案写下来即可。

个人方法论分享

写文档的时候围绕“谁要用”，“为什么要用”，“怎么实现”这三个维度去写，这样就确保这个需求的前因后果是清晰的了。

围绕着系统去写

在写实现方案的时候，要通过在系统上触发的场景去写对应的交互过程或者后续的流程，必要的时候可以通过流程图展示出来。B端的产品要注意需求中所涉及到的数据的流转、存储等；而C端的产品则要注意功能中涉及到的交互、跳转逻辑等要描述清楚。

考虑界面、系统的关联性

比如是一个很简单的加字段的需求，也要考虑到这个字段是否支持删、改、查等操作，包括他的输入规则、取值逻辑以及对其他系统的影响，比如说，如果我是在订单系统加了这个字段，那退费系统也需要展示吗？等等等等

数据埋点需求

如果这个功能后需要进行效果评估的话，就需要在文档里说明埋点的场景以及埋点的规则。

考虑各种边界值以及异常情况

正向的流程我们每个人都能想得到，但是一旦流程中任何一个环节发生了问题，系统又该如何处理呢？

举一个很简单的例子，微信支付我们都使用过：用户扫码–手动输入金额–输入密码–支付成功。

可是这其中几乎每个节点都有可能终止操作：扫码失败、不展示二维码怎么办？金额输入过大是否有限制？限制规则是什么？密码校验失败后系统会怎么提示用户呢？密码输入正常但是没有调起微信的支付接口该怎么办？接口响应延迟导致重复支付了怎么办等等等等。

这些问题以及应对办法，就是产品经理必须来做决策的，一个好的文档一定是各种正向流程、逆向流程、每个边界值都考虑周全，把开发安排的明明白白~

但是毕竟产品同学也没有那么多时间去把每个正向、负向场景的用例梳理出来，如果之后在技术评审或者在开发的过程中被指出来的话，就用小本本记录下来，之后再做类似的功能的时候不要再犯相同的错误就好啦。

再多说一句：写完文档之后自己要review一遍，把自己想象成一个门外汉，看下能不能读懂，文档的逻辑有没有漏洞，这个方法亲测很有效哦。

02 Axure绘制的能力

Axure是画原型的一个工具，也有很多人用Sketch。原型就是指你所做的功能的一个设计demo。

如果是B端产品的话，对原型能力要求没那么高，基本就是一个打辅助的作用，来解释需求文档（以前我都是画个demo后直接找UI小姐姐~）；C端的产品更重交互，所有对原型能力要求高一些，有的公司会要求产品画高保真设计图。

个人方法论分享

现在网上也有很多教程，我最早看的是小楼写的，比较显而易懂。当时还作死用了Axure全英版，查单词就要花好久……（答应我一定要汉化好吗）

入门的话可以先模仿下画Baidu首页，这个时候一般自己是没啥设计思路的，可以画画喜欢的APP/PC界面，或者可以参考下antdesign的设计，现在还蛮多的互联网公司用的都是蚂蚁那一套，提前熟悉了的话正式工作以后也有帮助。

（画外音：Axure也可以用来简单的P图，我前几天还用Axure把同事的照片和易烊千玺的P在一起了你敢信吗）

03 项目管理能力

项目管理能力=跟进+推动力。

推动力，从字面上解释就是推着走，工作中也就是把这个项目逐步推的上线，一般在遇到瓶颈或者由于临时的问题而影响进度的时候，产品同学就要通过不断地沟通、解决问题去推动项目上线。

跟进则主要是在开发、测试阶段，通过跟进开发进度、解决开发过程中的问题点，或者提前暴露风险从而避免项目delay等等。

个人方法论分享

说话一定要tough！不要不好意思扭扭捏捏，这点对于刚入行的小白同学十分重要，要有底气把自己的需求点、期望结果和同事讲明白，不要随便讲一句话就脸红（去年我实习的时候第一次评审时声音都在颤，更别提推动了），组织会议的时候、评审的时候、其他一切场合都不要方，你要记住你是这个项目的owner，要适当的硬气一些。（悄悄告诉你，这个也是面试官会考察的一个能力点噢）。

和开发也好、业务也好，双方确认完某个事情后，一定要在对应的时间的节点下再去跟进确认，每个阶段都要保证是在自己的可控范围内的、无风险的。写到这里的时候突然想到我之前的mentor和我说：产品经理做的就是一个操心的活。现在想想，真是深有体会。

04 数据分析能力

你以为需求上线了这个项目就算结束了吗？too young too simple！

功能是给业务做了，那业务用的好不好，有没有解决他们的问题，他们的反馈如何？这些产品同学也要关注呀！

工作以后最大的一个感悟就是：一切都要以数据说话。

上学的时候那种主观的说辞“我觉得不错”“挺有用的”“确实提高了效率”，在职场上完全是行不通的。

如果你说这个功能解决了你的问题，那你得靠数据去证明：做这个功能前，人均耗时多久，扑多少人力，上了这个功能后，人均耗时多少，大约提高了多少工效？等等等等。

个人方法论分享

带着目的去做需求，比如：我这次这个功能就是想要把某某部门的工效提升20%，那在PRD中就要把涉及到工效的触发点进行埋点处理，上线后请开发小哥哥跑一下数据自己算一下，看看有没有达到期望指标，没有达成的话，就要考虑功能上哪些地方还有不足。用这次的分析结果作为下个功能迭代的依据，逐步优化。

最重要的是，在这个过程中你十分清晰自己在这个过程中做了什么事，取得了什么效果，解决了什么问题。诶？等下，这些问题听着好熟悉，对啦！这就是你下次跳槽的时候面试官会问的问题呀~ 如果这些你都了然于胸，那offer不就是你的了吗？

作者：小仙贝；公众号：闫秀儿

本文由 @小仙贝 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议