大学实习期间辗转反侧比较幸运地进入一家较大互联网公司做了三个月、在三个月之内也接触了不少的运营和产品；做过大大小小的项目，由于想尝试自身更多的可能性，或者说得更直接一点，想成为一个决策者。

由个人追求的转变，于是决定转行产品经理。

有了这个想法之后，在工作时间之外开始学习产品的知识，从最基础的产品工具，到产品书籍，最后和几个同事做了一些小的产品需求。

一、成绩

没有产品的经验是很难设计产品的。在设计产品之前，需要做好充足的准备。

个人是花了一个月的时间梳理自己的产品知识体系的，作品集是最好的体现。可以尝试着自己分析一款产品，写产品分析，从各个角度提出优化建议。也可把自己经历过的项目，从前期的市场调研、用户需求、交互体验、商业变现的过程整理成作品集。

除此之外，还需要看一些入门的书培养自己的产品感觉，从用户体验和商业价值去思考一个产品。

从工程师转岗产品，有技术能力固然是好的，但是千万不要让技术去限制你的思维——产品首先需要的是全局观，需要以结果为导向；不要拘泥于技术上的性能，加载等细节问题。产品需要像小白一样去体验产品，如何把产品设计得高效、简单、让用户不需思考、如何实现商业变现才是需要考虑的事情。

二、项目前期

1. 尽快熟悉业务

公司业务是做产品的根本。

你需要清楚的知道你所负责的版块与哪些内容相互联系，他们之间的关系是什么？如果要改动其中的一块需要哪些资源，同时会不会对其他的有影响。

2. 做需求之前弄清来龙去脉

需求可能来源于运营，来源于销售，更多的是来源于老板，他们提出的方式可能是直接告诉你解决方案。

这时，产品需要做的应该是：问清楚他们的目的是要什么？这个需求是否合理？是否已经存在这样的解决方案只是他们并不知道？在确定之后自己再去想解决方案——因为别人提出的方案可能并非最优，并且可能不具有可行性。

举个例子（也是自己曾经踩过的坑）：

我刚来公司的第一周，老板让我学习之前产品的结构，并且从中提炼出来业务流程、虽然有前辈带领，但还是投机取巧的把操作流程走了一遍、最终导致我考核成绩不理想、

老板可能只需要你理解业务流程后结合自身实际能力来了解业务，这个时候个人能力就会凸显出来，这个时候也直接显现出来你以前的努力都能发挥作用、真实的付出了多少就得到了多少、所以能亲自来的就自己来、能做就别逼逼。

3. 做场景分析

在写产品文档和写产品文档之前，需要尽可能多的根据业务做场景分析。

什么是核心场景？然后它附带的其他的场景是什么？再画一个核心流程图，当任务不在核心流程图上时要想好怎么处理。

举个例子：可能都是一个客服系统，但是基于需求不同，所以根本不可能照抄别人的设计模式。

市场上常见的客服系统都是比较完善的，有用户排队功能、客服评分功能、多线程处理功能、留言功能、统计功能等；但是这时你需要做一个即时会话的IM、并且你的客服只有2个，是用来专门处理某些用户的特定需求，并且这些用户提问的频率并不高——这时，你还需要上述这么多功能吗？你需要的仅仅的只是在线时的即时会话功能，离线时的留言功能，以及最简单的客户分配规则，其余的需求都可以后续根据情况再加上去。

4. 需求评审

在进行需求评审之前，产品文档要尽量写清楚，写清各种临界条件。

在开发对某些需求提出质疑时，首先要弄清楚是需求不合理还是需求无法实现。若是需求不合理，千万不要拿这是老板的需求说话，因为这会减少开发对你的信任。需要以自己的理由说服开发，做这个需求的目的是什么，能带来什么样的效果。若是需求无法实现，可以问无法实现的原因，或者告知自己想要的结果，让他们提供可以实现的解决方案。

有时候开发为了能够实现需求而采用一些降级方案，但是由于产品欠缺技术的原因，开发提出的方案并不能很好的理解并且造成一些问题，所以在做之前，需要确认：

*

* 这种方案做出来是怎么样的，有什么优缺点?有什么弊端。

*

* 如果无法知道做出来的效果。要说出自己的需求，这种方案要能满足需求。

*

避免最后发现做的东西不满意，但是能用，是一个残次品的情况。

在和开发确认完需求后，把修改后的需求文档发给开发确认，同时把产品原型给设计师。

5. 项目排期

在确定需求后，需要规定一个项目交付日，如果自己做的项目涉及到其他产品经理所负责的模块，也需要提前沟通协调。否则自己这部分做好了其他部分没做，浪费了开发时间，做的需求不能及时上线。同时为了避免中途被插需求和开发人员请假的情况，需要留一定的时间应对这种突发状况。

三、项目中期

这个阶段主要做的就是项目跟进，如果几天不问项目进度，开发干其他事去了，导致项目延迟上线。产品一定不能偷懒、不能偷懒。同时在过程中还能及时跟进开发所遇到的问题，有必要的时候需要修改最初的方案。

有些开发会经常忘记一些临时提出的一些优化小需求。首先产品经理要养成良好的习惯，尽量不要中途修改需求。如果实在需要修改，需要在原来的文档上批注说明，并且需要及时提醒开发。 如果公司有公用的wiki，那么可以更新在wiki上，如果没有，可以根据项目类型选择适合自己的项目管理工具。

根据个人的经验来看：

如果是琐碎型需求，没有明确的上下线时间，可以用wounderlist。一个人完成，直接勾掉，适合产品和前端之间的样式上的修改。如果是一个流程比较复杂的项目并且周期长，需要多人协作，可以使用tembition管理项目进度，把团队成员都拉入进去。

当遇到对设计师做的设计稿不满意怎么办？有时候设计师为了追求美观而忽略实用性，最好不要发生争吵，但是作为产品经理，先满足需求，再优化体验是必须要坚持的。这时候可以提供给设计师自己的想法和方案，同时自己也要多看竞品，精品，扩展自己的视野。

四、项目验收

1. 新功能的验收

新增功能，一定要注意验收。有时候不知道哪些功能会受影响，至少把相关的内容，同一个页面的东西之前做好的功能再检查一遍。

新功能上线，做好数据埋点。知道这个功能是否有人用，然后不足在哪里，收集反馈。再对反馈进行筛选，优化迭代。

2. 产品迭代记录

对于小公司，没有规范，发版也是想发就发，没有一个明确的时间。迭代的东西也没有记录，也没有发送给用户。首先，如果没有规范，需要自己去建立规范，规定在一个时间才能发版，这样有利于把控做事的节奏，同时也不会影响线上的功能。

产品迭代日志是很有必要的。一方面是告诉用户我们做了哪些迭代，一方面是日后总结工作起来也比较方便。同时如果新上线的有问题，也能快速地比较清楚的知道切回哪一版比较好。

五、其他

1. 定期汇报

定期向老板汇报比较重要，让他能知道你都做了哪些事情，进展怎么样，成果怎么样。

每次会议之后，主动发会议总结。

只有充分赢得老板的信任，他才会把重要的事逐步交给你。

2. 肯定别人

当与设计师、开发、老板意见不合时，不能只是与他们发生争吵，他们跟你是一个team，不是对手。应当认真听完他们的意见，毕竟每个人的想法都有自己的原因。所以尊重是第一步。如果确实发现自己的不合理，那么需要仔细思考别人的意见、虚心接受，提出更好的解决方案。

3. 多看、多思考、扩展视野

产品需要保持对新鲜事物的探索，每天阅读相关的产品文章、了解互联网圈正在发生的事情，保持敏锐的嗅觉。花一点时间去体验一款产品的优劣，学会总结和输出。只有不断输出，才能形成自己的知识体系。同时，产品经理除了要涉猎产品知识，对UI设计体验、市场营销，用户研究甚至技术都应该有基本的学习和了解，保证能跟他人沟通顺畅。

产品是对综合能力要求很高的一个职位，只有不断的思考、不断的更新知识体系，对这个行业充满着未知的探索，才能保持一颗初心，打磨出一款出色的产品。

本文由 @97独立完成，转发需谨慎