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

毕业后比较幸运地进入一家较大互联网公司做了两年研发，在两年之内也接触了不少的运营和产品；做过大大小小的项目，由于想尝试自身更多的可能性，或者说得更直接一点，想成为一个决策者。

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

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

跳槽后，开始准备产品面试。

一、面试

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

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

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

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

二、项目前期

1. 尽快熟悉业务

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

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

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

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

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

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

我刚来公司的第一周，老板让我把某页面的某功能去掉，我就直接去掉了，结果造成了一大堆用户吐槽：怎么这功能突然消失了？最后又马不停蹄地把这功能加回去。

老板可能只需要把功能换个地方或者是换种方式展现——关于目的，一定要问清楚再去做。

3. 做场景分析

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

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

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

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

4. 需求评审

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

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

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

• 这种方案做出来是怎么样的，有什么优缺点?有什么弊端。
• 如果无法知道做出来的效果。要说出自己的需求，这种方案要能满足需求。

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

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

5. 项目排期

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

三、项目中期

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

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

根据个人的经验来看：

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

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

四、项目验收

1. 新功能的验收

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

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

2. 产品迭代记录

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

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

五、其他

1. 定期汇报

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

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

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

2. 肯定别人

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

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

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

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

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

题图来自unsplash，基于CC0协议