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

聊天界面需要有一个发红包的按钮，作为产品经理需要思考的就是这个按钮怎么放，这个功能的使用的优先级如何？

需要输入红包的金额，那么金额有没有限制呢？

需要输入留言，留言是必填的吗，要是用户不想填有没有默认留言？

要输入支付密码，密码输入完毕后要不要用户再点击确认？

解决完这些问题一个完整的发红包功能就出炉了，在这个基础上画原型图的话不仅会很快，后期也不需要频繁修改。

重视流程、利用好流程图这个工具，不仅能够帮助产品经理们大大提升效率，减少返工，还会给别人留下一种靠谱的印象，避免成为别人眼中的”改图”经理。

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

0-1岁的产品经理们还在进行从用户向产品经理的转变，在设计产品时脑子想的更多的不是我这个产品或者我这个功能怎么样最好，而是回想以前用过的类似的产品或功能都有什么东西可以套用。虽然模仿和参考本身不是坏事，但是作为一个产品经理需要去判断什么样的功能是当前产品更适合的。最难的永远不是加功能，而是如何去减功能，而产品新人往往陷入加功能中无法自拔，反而会拖累产品的发展。

加功能之所以不难在于你永远能够找出理由来支持你加这个功能，而在众多功能中要决定砍掉哪个却很考验产品人的能力。当我们谈论减功能时，首先要明白我们为什么要减功能，我认为主要有以下三大原因：

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

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

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

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

（3）最后是资源的问题

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

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

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

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

4、不会给PRD“减负”

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

给PRD“减负”听上去似乎很奇怪，难道PRD还会超负荷吗？

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

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

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

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