编辑导语：本篇作者分享了自己从毕业后选择做产品经理，到短时间内快速成长，到突然经历行业剧变，再到一个月内迅速跳槽新行业的全过程。推荐给还在产品经理职业初期的童鞋阅读，希望对你有用，一起来看一下。

一、我为什么选择当产品经理？

1. 误打误撞进入产品领域

先说一下我的专业背景，985师范院校本硕学历，专业是心理学中的心理测量方向。研三时候，我已经决定不继续搞学术而是进入职场工作后，曾在一个投资机构的投后管理部门实习，帮助对该机构的投后企业进行人力测评、人才盘点等工作。

随着业务的发展，团队期待能够开发一个给公司投后企业使用的人才管理SaaS平台，因此招了一个资深的产品经理进入团队，配合设计外包和开发外包进行平台开发工作，我也作为实习生开始正式接触产品经理的工作。

回忆起来，这是一段相当宝贵的经历，也奠定了我后面选择做产品经理的基础。一方面，我既是提需的业务方，又是接需求的产品经理，我能知道从业务角度需要哪些功能，同时也在学习如何设计和产出这些功能，是业务和产品之间沟通的桥梁。

另一方面，这是一个从0到1的项目，从最开始的需求分析、竞品调研、产品规划、到需求评审、项目跟进、以及上线后的版本迭代，每一步我都有参与其中，并且在与开发和设计沟通的过程中，涉及到心理测量专业知识的部分，也是由我来主导的，大大锻炼了我的沟通能力。甚至我们当时没有专门的测试，就由我来主要测试所有功能，到最后平台上线，正式投入使用的那一刻，我真的获得了莫大的成就感。

那一刻我知道，这是我喜欢的工作。

这一段经历也是我职业的转折点。

突如其来的疫情打乱了每个人的生活，我之前所在的团队也受其影响没了headcount，没办法，我只能在已经错过了秋招和春招之后重新找工作。

而这一次，我不再看和人力测评相关的工作，而是专注在找产品经理相关工作上面。结合自身传也背景和职业兴趣，我选择了当时还如日中天的在线教育领域，开始了我的职业生涯。

2. 选择继续做产品的理由

在实习过程中，我发现有两个方面让我想要转行成为产品经理：

1）职业兴趣

以前大学期间学习职业心理学课程的时候，就有给自己做过霍兰德职业兴趣量表，我从那时候就很看重工作能够给我带来的成就感，而产品正是能给人带来很大成就感的职业，再加上比起做学术，产品带来的成就是快速的、即时性的、看得见摸得着的，不断的正反馈会促使我更享受其中；其次，比起跟文件或代码打交道，我更喜欢跟人打交道的工作；再次，我不喜欢一成不变的工作，更喜欢富有挑战性的工作内容。

2）个人能力

从个人能力上来说，我在学校做过较多的学生工作，有着比较丰富的管理和协调沟通经验；同时，因为要处理很多繁杂的事务，所以也培养出了我同时处理多项任务的多线程工作能力，这些都能帮助我更快速地上手产品经理的工作。

总的来说，我不只是因为一时的喜欢而选择产品，而是衡量了“我能不能做”和“我适不适合”这两点后做出的决定。

以上只是我个人的心路历程。产品经理分类丰富，偏B端和偏C端的产品都会需要不同的特质，关键在于你需要知道这是否是你喜欢的工作，对于还在学校的同学来说，通过实习去体验是最快确定是否喜欢这份工作的方法，哪怕是试错，排除错误选项也是很大的收获。

二、入行一年，我收获了什么？

我所在的公司不算教育互联网大厂，但属于在线教育领域中发展较快、细分领域的top，对教育测量比较重视，而我的学校和专业背景与此正好契合，再加上疫情原因，当时的岗位相对较少，因此最后选择了这家公司作为我职业的起点。

教育公司的团队氛围很好，人人都有一颗爱教育的心，但对于产品经理本身而言，并不是一个特别好的选择。

这里没有成熟的培训体系，也没有专门的mentor带我，交接的同事也只是给我些许指导后就忙自己的去了，所有一切都全靠我自己摸索和野蛮生长，就连第一次跨部门需求对接也是我自己一个人去的，当对面业务方说着一些业务相关词汇和描述的时候，我感觉自己就像是在听天书一样，靠一些社交牛逼症撑完了整个对接会。

第一次需求评审的时候，我整个人声音和手都在抖，甚至还听说有开发同学在背后吐槽我能力不行……那时候的青涩还历历在目，最近快离职的时候与同事告别吃饭，他们都说，觉得我不像是只有一年经验的产品经理，这一年里简直进步神速。

我想，我一定能从这一年的工作中找到我快速进步的原因，帮助我在下一份工作中做得更好。

1. 产品工作方法论

在过去一年时间里，我沉淀出了一些比较完整的、适合我自己的工作方法论，从需求对接、到需求分析、设计、评审、项目跟进，到上线和后续迭代的全流程，在这一年中也经历过很多遍，很多时候你觉得自己已经熟悉了这些内容。

但真正自己做的时候，就会发现自己每次都会踩到不同的坑上去，甚至同一个坑不止踩一回。但是咱们不能只踩坑呀，踩坑之后的总结就是我们形成属于自己工作方法论的过程。

下图就是我自己总结的工作方法论，以及每一步中的注意事项。

里面有几点需要格外注意：

1）在需求沟通阶段，和业务方对接时一定要多问几句“why”，这个需求的背景是什么？想要达到的核心目标是什么？如何通过数据来验证这个需求的价值？出了需求方提出的方案，是否还有更好的方法达到这个目的？其中有两点是刚做产品的时候容易忽略的问题：

① 完全跟着需求方提出的方案走，而不思考是否还有更好的方案，关于这点在产品届一直有个比喻我觉得很对，就是当有个人说他需要苹果的时候，不一定是他真的需要苹果，他可能是渴了，那水行不行？他也可能是饿了，那烧饼行不行？还有可能他就是想吃水果，那梨子行不行？这就是需求分析，多问几个为什么，发掘用户/业务方的真实需求。

② 如何通过数据验证需求价值，往往是最容易被新手产品忽略的一点，很多时候只是埋头做功能，却忽略了如何通过数据去验证，最后复盘的时候无法体现工作的效果和价值。解决方法是在需求沟通阶段就要将数据验证考虑清楚，如果有拿不准的地方要多向开发同学请教。

2）在需求设计阶段，要追求快、准、狠，善用自己熟悉的工具加快产出速度，在这个阶段容易遇到的问题是，当自己手上同时有其他不同进展阶段对项目在跟进，由于需要处理许多零碎的问题和开会，往往没有整块的时间写需求文档，从而导致项目进度延后。解决方法是将琐碎的事情集中到一个小时内处理，空出整块的时间进行需求产出。

3）在需求内审和评审阶段，若在一审后需要修订并再次评审，最好是在当周进行二审，尽量不要跨周，不然过了一个周末很多细节就都忘记了，最后只会给自己挖坑。如果出现不得不跨周的情况（其实还挺常见），最好周五晚点花点时间整理本周待解决的问题，并在周日晚上或周一早上列入本周计划中，避免很多问题因为假期不了了之的情况。

4）在项目跟进阶段，养成良好的周站会或日站会的习惯，产品需要时刻跟进开发测试进度，避免出现项目延期等情况。

5）在项目上线后，复盘和数据验证是很重要的一环，刚开始做产品的时候容易“做就做了”，没有项目复盘也没有数据验证，做下来没有任何收获。项目复盘能帮助自己总结经验，避免再犯同样的错误，也能够帮助整个产品/开发/测试团队回顾整个项目过程，加强团队凝聚力。数据验证很多时候也会被业务忽视，但产品需要清楚自己做的每一件事都达到了怎样的效果，不论是自我成长还是年中/年底述职、跳槽找工作都有用。

需要说明的是，我之前所在的团队是有自己单独的产品、前后端开发、设计和测试的，且部门内不同业务线的开发和测试也都相对固定，不存在与其他组抢资源的情况，整体开发流程也是瀑布流形式。

但我也有了解到一些大的产研团队会采用敏捷开发的方式，以双周为单位进行评审和迭代，因此我当前的工作方式不一定适用于所有团队，一些通用的经验仅供参考。

2. 如何快速成长

在前司自己摸索和野蛮生长的过程中，我也总结出了一些帮助自己快速成长的方法，在这里分享给大家，尤其是新人产品同学，在没有一个尽责的mentor带你的情况下，以下这些方法或许能帮助你更快地成长：

1）模仿

跟所有物种的成长路径一样，模仿永远是超越的第一步。找到一个好的参考对象，不论是你的mentor、同事还是领导，甚至可以是合作的业务方，观察他们的思维方式和做事习惯，找到觉得“他好厉害！”的地方，并思考如果是自己来做这件事会怎样去做。如果可以的话，最好能够及时记录下来。

（第一次作为需求方要其他产品配合的时候，记录下的觉得其他人做得好的地方）

2）练习

只记录下来是不够的，还需要有意识地、反复地练习，将一些好的地方融入到自己的日常工作中，把其变成自己方法论中的一部分。

可以通过制定计划，比如“我想要提高xxx方面，在下次xxx的时候要注意什么”，等下次发生之后回头看自己做到了没有，可能没法一次性养成习惯，但需要知道自己为什么没做到，下次如何改进。

3）及时寻求帮助

上面也有提到，我并没有专门的mentor带我，同事也只是敷衍了事，遇到困难了应该怎么办呢？出现紧急情况，自己无法担责怎么办呢？等等这样的问题，一定不要想着全部自己处理，不要怕挨骂，及时与领导沟通，从上级那里获取帮助，后续再从中获取经验教训都行；学会先把情绪放下，当下解决问题才是最重要的。

4）养成定期计划和总结的习惯

① 工作记录

对于新手而言，记录下自己每天做了什么、有何经验和收获是非常重要的，特别是遇到坑和障碍的时候，更能够快速成长。我刚开始的半年，每天的工作记录都会写好长，现在回头看也是很感慨当时自己怎么会想那么多有的没的hhh。

② 定期计划和总结

以周为单位制定计划，记录每天的工作进度，每周下来进行总结，比如我会在每周五下班前整理下自己本周待解决的事情，免得一个周末后就忘了；每周日的晚上，抽出半个小时来列出下一周的工作计划，这样周一早上能够更快地投入当周的工作中去。

在每完成一个项目后，还可以项目为维度进行整理，可以用STAR法则来帮助理清思路（参考文章：《STAR法则，在产品设计的应用和思考》）。

3. 工作中的避坑小技巧

1）与业务沟通

① 学会拉群

避免产品单人对多点沟通同一件事，这样效率又低还可能让自己成为传话筒，最好的办法是将同一个问题的所有相关方拉到一个群里，同步询问和周知各种事情，或者让某两方自行对接。

② 会议记录

不论是再小的会，也一定要有会议记录和会议结论，最好是能够以文字形式发到会议群中，让所有参会人员进行二次确认，确保不会有细节遗漏，也可以避免一些甩锅的情况。

2）与开发沟通

① 了解技术

产品不需要写代码，但也不能完全不懂技术，一开始我连QA是什么都不知道（因为实习时候都是产品自己来测试）。

② 不强硬也不盲从

是产品总会出现和技术意见不一致的情况，但咱们需要明确的是，我们的目的是一致的。

4. 实用工具

这一趴最后，介绍下我的爱用工具：

• 原型图工具：Axure/Sketch，Axure更注重页面之间的交互，而Sketch能帮助你在和设计交流的时候更加便捷，可以根据需求或者电脑系统（Sketch只能在MacBook上用）的类型进行选择。
• 流程图工具：Process on，优点在于在线编辑、无需下载，缺点在于可创建的文件数量较少，需要定期清理。
• 思维导图工具：Xmind，非常好用的整理思路工具，养成在复杂项目之前用xmind整理思路的习惯，也能很好地锻炼自己的逻辑思维，比如我在写这篇文章之前就会先用xmind理一下思路，不然就会越写越放飞自我。
• 笔记工具：
  • 印象笔记：优势在于点击侧边栏目录即可切换文档，不需要单独打开新的窗口，适合即时性的记录和查找翻阅，但不适合长篇的沉浸式写作，因此我一般会用印象笔记来记录日常工作、规划；同理，Onenote也可。
  • 石墨文档：页面干净简洁，功能齐全，适合进行长篇沉浸式的写作（比如本文），我一般在写工作总结或者整理面试资料的时候会用到石墨文档。
• 项目管理工具：飞书多维表格，当有多个项目在不同进行阶段的时候，可以用飞书里面的多维表格模板进行管理；其实excel也能达到同样的效果，软件有一定的局限性，excel可以做一些个性化的事情（前提是要会做）。

三、当行业发生剧变，我们将何去何从？

1. 当风停了

有一句在互联网行业中流传已久的老话说得好，站在风口上，猪都能起飞。

那当风停下的时候呢？

我毕业的2020年，在线教育正如同坐火箭一样飞速发展着。互联网行业的发展改变了传统教培行业的形态，越来越多的人和资本开始进入在线教育，越来越多的家长和孩子开始使用线上教育的产品；疫情的到来更是为在线教育添了一把火，有风助力，燃料充足，前景一片灿烂。

而2021年7月，风停了。

很难说明这段时间的心情。从4、5月份开始很多事情开始有了苗头，当时大家都还只是心存侥幸，觉得铁锤不会落到自己头上，或者就算开始管制也不会有多大影响，但是当看着身边的同事一天之内少了很多的时候，心态已经不同了。

我看似很幸运，公司大裁员的时候留了下来，但是留下来不一定真的幸运，纠结再三，我还是决定跑路。

2. 我的思考与选择

当政策出来之后，大家都说“快跑”，但我是有过犹豫和纠结的，最主要的原因是，我放不下自己的专业背景优势。一旦离开教育，我的专业背景优势将会不复存在，而要完全凭借自己的产品能力，竞争压力一下子增大。

另一方面就是手中还有自己付出了许多心力的项目没做到最后，做产品还是希望自己的孩子能顺利出生。当时也找了很多人聊这件事，并在跟他人讨论的过程中，逐渐理清了自己想要什么：我还是决定继续做产品，如果没有专业优势，我就去大厂学习加倍锻炼自己的产品能力。

当决定好了离开教育行业之后，我就迅速开始写简历和投简历，并利用上班前后和午休时间进行集中面试。不得不说面试过程比我想象中顺利很多，我大概8月初投简历，8月中旬开始面试，到9月中旬就已经拿到了2家互联网大厂的产品offer。

因为比较想快速转行，所以没有等待更多的机会，在2家中选择去了一个涨薪50%以上的大厂（之前的起薪比较低，所以薪资也是我重点考虑的方面）。9月中旬提了离职后，花了大概一周的时间交接完毕，顺利在十一之前入职了新公司。

如果有人想看我的简历准备过程和面试经历的话，欢迎给我留言，我下一篇文章可以详细分享下这部分的内容～

四、尾声

终于逼着自己把这篇文章写出来了。

在刚工作的时候，我跟我前领导说，希望自己也像其他人一样在人人都是产品经理上写文章，将我自己做产品的心得经验分享给别人，如果有人也想入行产品的话，能够从中得到一星半点的帮助，我就很知足了。憋了好久，终于趁着离职交接期间把这个孩子生下来了，也没有辜负我之前的承诺。

写完回头看真的好啰嗦啊我，比起别人干货满满的分享，我这篇废话太多太杂。

希望读到这篇文章的人，能够体谅下我不成熟的总结，如果有共鸣或者建议的话也希望能够给我留言，大家一起讨论和进步～

本文由 @一颗蛋_ 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于CC0协议