产品工作中需要避开的四大坑

2017-07-03 22:34:00

产品经理在日常工作中会遇到很多坑，刚入行的产品经理尤其如此。只有掌握有效的方法来快速避开这些坑，才能让产品工作更加得心应手。本文根据自己的产品工作经历，总结了产品工作中需要避开的四大坑，希望能对大家有所用处。

1、误把客户需求等同产品需求

虽然常说产品经理需要去发现、洞察用户需求，但是往往更多的是在对接需求。这些需求可能来自公司内部，比如运营的需求、市场的需求，当然还包括老板的需求；也可能来自公司外部，比如像在齿轮易创这样提供技术解决方案的公司，产品经理所接的需求大多是来自客户的需求。

那么问题来了？产品经理应该以怎样的姿势来对接需求呢？这里面就有我今天要说的产品第一坑：

误把客户需求等同产品需求。

无论是客户也好，运营、市场也罢，他们所做的工作都是实现整个产品的第一步——提出需求。

但这个需求往往不是产品真实需求，产品经理常常被人诟病的一个原因就是被认为产品经理的工作很简单——接到需求后画画原型写写文档然后就是盯设计盯开发盯测试，好像没有太多技术含量。

这种观点对出现很值得我们思考：为什么产品经理们会给外界留下这样的印象？我想可能和很多产品经理在需求阶段就没有深入地去判断和区分客户需求和产品需求有关。

“更快的马车”的例子在互联网界已耳熟能详，但懂得道理并不代表能够实际运用到工作中去。正确判断客户需求和产品需求需要多问自己两个问题：

客户需求的本质是什么？
这个客户需求的目的是什么？

举个例子，假如客户A想要做一款健身类APP，其核心就是通过领取任务—完成任务—领取奖品的方式来吸引用户健身、提升产品的用户活跃度和用户黏性。并且客户还提出完成任务就会给用户发放特定的奖品并寄送给用户。

面对这样的客户需求，产品经理当然可以顺着客户的需求去做，但希望能够掌控产品的各位是不是也要从自己的判断出发，梳理发现这样的要求下真正的产品需求。

我们可以发现奖品实质上是一个激励因素，而发放奖品的目的就是为了激励用户使用自己的产品，提升产品的各项数据指标。在了解需求本质的基础上我们再来从产品角度思考这一需求：是不是一定要发放实物奖品呢？有没有更好的实现方式能够满足这一目的？那么也许我们可以用现金红包、手机话费、流量券等多种方式实现这一产品需求，而同时又大大节省了实物奖品所耗费的人员和物流成本。

当然以上讨论并不一定是这一产品的最好实现方式，但却是一个产品经理应有的思考。如果只是机械地接需求、实现需求，而不去深入思考需求本身，就无法发挥产品经理的真正价值。

2、被页面主导而忽视流程

产品经理最”炫酷”的技能可能要属画原型了，这也是0-1岁产品经理会很热衷于画原型的原因之一。画原型是产品经理的基本功，是将需求通过可视化的形式表现出来，将功能和其中包含的逻辑以简单明了的方式呈现出来以方便确认需求和沟通。

但很多产品经理都会有这样的感受，原型图画了一遍又一遍，跟其他PM过功能，发现很多问题，改；跟开发进行需求评审，发现逻辑漏洞，改；跟老板或者客户汇报，不满意，改。结果就是原型改了很多遍才能最终定稿。诚然其中会有一些修改是因为需求本身发生了变更或由于其他不可控因素而发生的，但是仍有很多修改问题来源于产品经理本身—— 忽视流程而被页面主导往往是这类问题的根源。

画原型最忌讳的就是一上来就直接画图，而没有提前对功能的流程及其逻辑进行深入思考，这也正是初阶产品经理常跳的一个坑。

这类问题往往出现在逻辑相对复杂的功能板块，如果直接上手画原型图思维就会被页面带着走，页面画到哪想到哪，想到什么就画什么。不能很好地从整个功能板块的业务流程角度去思考问题，一方面会给自己埋下逻辑漏洞，另一方面修改起来也比较麻烦，更容易影响整个产品流程。

因此在画原型图之前可以花很少的时间先把流程图给画出来。流程图，顾名思义就是用来表达流程的图，可以使用各种工具，甚至可以手画；表现形式也可以是多种多样，只要能够帮助你理清业务逻辑、想清楚完整流程即可。比如下图是微信给好友发红包的一个简单流程图：

这个流程图看起来很简单，画出来甚至花不了一分钟的时间，但是有了这样一个流程图之后我们就可以很方便地进行按图索骥了。我们可以将原来一个完整的比较复杂的发红包功能分成一个个连贯的小部分，从而逐一进行单点突破：

聊天界面需要有一个发红包的按钮，作为产品经理需要思考的就是这个按钮怎么放，这个功能的使用的优先级如何？
需要输入红包的金额，那么金额有没有限制呢？
需要输入留言，留言是必填的吗，要是用户不想填有没有默认留言？
要输入支付密码，密码输入完毕后要不要用户再点击确认？

解决完这些问题一个完整的发红包功能就出炉了，在这个基础上画原型图的话不仅会很快，后期也不需要频繁修改。
重视流程、利用好流程图这个工具，不仅能够帮助产品经理们大大提升效率，减少返工，还会给别人留下一种靠谱的印象，避免成为别人眼中的”改图”经理。

3、只会做加法不会做减法

0-1岁的产品经理们还在进行从用户向产品经理的转变，在设计产品时脑子想的更多的不是我这个产品或者我这个功能怎么样最好，而是回想以前用过的类似的产品或功能都有什么东西可以套用。虽然模仿和参考本身不是坏事，但是作为一个产品经理需要去判断什么样的功能是当前产品更适合的。最难的永远不是加功能，而是如何去减功能，而产品新人往往陷入加功能中无法自拔，反而会拖累产品的发展。
加功能之所以不难在于你永远能够找出理由来支持你加这个功能，而在众多功能中要决定砍掉哪个却很考验产品人的能力。当我们谈论减功能时，首先要明白我们为什么要减功能，我认为主要有以下三大原因：

（1）首先是产品定位的问题

要弄清楚自己这个产品的定位是什么，对于不符合产品定位的功能就应该果断砍掉。

（2）其次是产品迭代的问题

互联网产品与传统行业在产品更新换代上有着显著差异，传统行业往往会几年时间调研、设计、生产一款新产品，而互联网行业遵循的则是快速迭代的精益创业理念，同类产品间竞争的往往不是谁更好，而是谁更快一步，只有快速迭代、快速试错才能紧跟市场的变化。因此，面对如此快速的迭代过程，产品经理必须下狠心对功能动刀子。

（3）最后是资源的问题

因为资源永远是不足的，即使在BAT这样的大公司中资源也是短缺的。比起你想做的，你能做的往往会大打折扣。这里的资源涵盖时间、人力、金钱等产品研发中所需要的各类资源，面对资源短缺的现实，产品经理只能将现有资源效益最大化，先做优先级最高的功能先把”孩子”生下来。

腾讯去年11月推出的轻聊版QQ——TIM就是一个减功能的好例子，因为TIM就是在手机QQ的基础上增加功能和减少功能而成的。拿TIM举个最简单的例子，TIM1.0.1版本中虽然上线了在线协作文档功能，但是只能进行最基本的文字编辑，之后在1.1.5版本中才加入了上传图片的功能。在移动端支持上传图片本身并不存在技术难度，那为什么在第一版本没有做呢？

因为在线文档编辑的实际使用场景在PC端，移动端只是PC端的一个补偿，移动端文档的主要使用场景是不在电脑身边又需要及时查看文档，而不是编辑文档。所以在第一版本中TIM的产品经理们将上传图片的功能砍掉了。但这并不表示移动端上传图片就是个伪需求，相反它是一个可以提升用户体验的点，在产品迭代优化的过程中这个功能是值得做的。

要记住，砍掉一个功能并不代表这个功能不重要，只是因为同时有更重要的功能。对于一个产品新人来说，学会砍功能比学会加功能更加重要。

4、不会给PRD“减负”

撰写PRD文档也是产品经理的基本功，但是要把文档写好却并不是一件简单事。产品新人初写文档时往往不得要领会犯很多错误，而PRD里面的坑也确实不少，今天主要想给大家分享如何给PRD“减负”。

给PRD“减负”听上去似乎很奇怪，难道PRD还会超负荷吗？
当然，当你的PRD文档有着大量重复内容或者需要用非常繁琐的文字说明去解释某一功能的时候，就说明你的PRD文档需要减负了。因为撰写PRD文档是为了能更好地沟通清楚需求，如果盲目撰写文档、不给文档减负以增强可读性，不仅达不到提升沟通效率的目的，反而会让看文档的人深受其累。

那么如何去给PRD文档减负呢？

我认为有两个方法可以提供参考：

（1）用模块化的思维来撰写文档

在一个产品中往往有在很多页面中反复出现的板块，比如一款音乐APP中的音乐播放板块、歌曲列表、分享板块等。产品经理在撰写文档时没有必要每次遇到同样的或类似的板块都重复再说明一遍。

有同学可能会问，如果只是将那个板块的说明复制粘贴过来，既不增加工作量，又可以使文档更加滴水不漏，岂不更好？
答案是否定的，因为在撰写文档时我们仍然要紧绷用户体验这根弦。虽然这样做对撰写文档本身没有增加太多工作量，但是对于阅读文档的人来说，为了确保不遗漏信息却要认真看每一句话，这样无疑增加了文档阅读者的工作量。更重要的是当他们发现大段都是重复内容的时候内心一定是一万头草泥马在奔腾。

因此对于这样的内容，我们可以采用两种方式来进行优化：在音乐APP的例子中，对于音乐播放这样的板块应该拿出来作为一个单独板块进行统一阐述，而对于歌曲列表这样反复出现但本身又不复杂的板块则只需要在第一次出现歌曲列表的时候尽可能详细地说明清楚，此后再遇到同类型歌曲列表只需一语带过。通过这样给PRD文档”瘦身”既能提升我们自己的工作效率，更能大大提升文档的可读性。

（2）善用流程图

在一款产品中，往往会有一些比较复杂的功能，要么是功能流程长，要么是背后有着非常复杂的判断逻辑。这种时候要想把这个功能表述清楚往往就需要花费很大的篇幅。而大篇幅的文字说明对开发来说往往不是最好的理解方式。且不说更有甚者，即使花了很大的篇幅也无法把问题表述清楚。而这种时候流程图这种图形语言就能够提供很大的帮助。

拿最简单的登录验证来举例子，用户输入手机号和密码后需要依次经过如下图所示的五个判定，缺一不可。