作为产品经理，你们从每个项目中都总结出什么？

每个项目总会踩到一些坑，遇到一堆bug，但是在每个项目的结束之后，总结经验吸取教训往往是最好的成长机会。

前世之事后事之师，将你的经验分享出来，自己做总结之余，也给其他小伙伴们一点参考。

作为产品经理，你们从每个项目中都总结出什么经验？



解答一：

作为一个仍在产品路上爬摸打滚的年轻人，刚入行的时候我的Mentor就告诉我，年轻人做产品，执行力和他推动力最重要。刚开始肯定是从打杂干起，但是千万以为自己除了画个图听吩咐就完事了，要善于利用自己作为菜鸟的这段时期以打杂的心态去跟进整个项目的流程。

比如，在迭代进入特定阶段的时候，尽量协助充当这个阶段主体的同学，为他们免去尽可能多的杂事，换句话说也就是替他们“打杂”。

一方面，我们可以规范迭代流程，给每个迭代阶段都留出充足的时间，让他们游刃有余地处理手头的工作；另一方面，我们也可以通过及时准确、一次到位的沟通，来避免一而再、再而三地交代需求细节所造成的时间浪费。

落实到具体的工作上，有以下这几点可以参考（不敢说参考，只能给大家一点儿小建议吧）：

1、部门沟通一定要落实到邮件或者纸面

比如说每次需求评审都使用原型与文档辅助讲解；会议记录整理后用邮件发出，一方面避免了口头沟通易忘的风险，可以帮助各部门同学记住重要信息，另一方面也可以借此规范迭代流程，明确各自责任，以防出现问题时大家互相推诿。

落实到纸面上的信息，比如已经确定的产品策略、开发排期等等，如非极其特殊的情况，尽量不要更改。即使只更改过一次，也会让其他部门同学对你产生不好的印象，再提需求的时候可能就困难了。



2、一定要有Plan B

在项目落地的过程中难免会有各种的八格，比如开发或测试没有如期完成，影响了下一阶段的工作，此时应该如何做，是砍掉部分相对不重要的需求，还是牺牲上线时间，视具体情况而定，总之一定要有plan b.不然这个锅无论是谁的都有产品的一口。



3、产品迭代周期要控制好

一般迭代周期为1-2周，少于一周，时间太紧，很可能导致每次迭代都做很少一点功能草草了事，用户也会厌烦。大于两周，工作在时间上难以把控，很容易造成迭代不能如期完成，难以形成稳定有效的规范。


解答二：

1.任何产品都是一个大工程，绝对没有想象的那么简单。只有真正去做过产品，才会体会到产品、交互、视觉设计、开发等有着无穷无尽的问题，产品经理也绝不是提提想法，指指方向这么简单。



2.文档的重要性。尤其是小团队，做项目非常不看中文档，包括现在的我自己。但事实上，永远不要高估你自己的判断力，很有可能你今天信誓旦旦做出的改版明天你自己就要推翻，你也很难保证你口头说的改动人家就能完全理解和记住，认真改文档去吧，做好版本管理。



3.产品形态、功能和逻辑模式是最重要的。刚入行的新人一定要不要过份追求极致体验和极致视觉，往往那些东西会极大地占用时间，拖慢进度，甚至最后东西都没做出来，项目就要就要结束了。



4.不要把自己当做用户典型，也不要轻易否定别人的想法。除去明显的硬伤，一切都要以事实为准，因此调研、访谈和测试都不是走过场的，都是十分重要的。