一直都有写公众号的想法，可惜因为种种原因迟迟没能实现。前些日子遇到几个职场新人，表达了他们对从事产品经理工作的疑惑。简单沟通之后，让我觉得有必要整理一下自己的经历和思路，帮他们在职业规划上出一份力，于是就想到了公众号。

    我是误打误撞进入到产品经理这个职场当中的。2010年之前，我一直以为自己会变成一个码农。大学毕业之后，为了继续深造（逃避就业），选择了留学美国。在某不知名高校的研究室勤勤恳恳搞科研、写论文、编代码，一心想通过一篇专利敲开Google和Cisco的大门。那时候我的专业方向是视频编解码，导师是学术界红人，和斯坦福投资的某公司一起做一个联合项目，竞争当时H.264（现在已经是H.26X了）的业界标准。看似颇有前途的一个规划，由于当时家庭的一些原因不得不停滞了。于2010年中回到国内，赋闲在家数月后，终于由一位老友推荐进入到一家外企做了BA（需求分析师）。

    为什么我会选择做这个职位？坦白的说，那时候的我根本没想过择业的问题（最主要的是当时和我专业对口的公司并不多）。跟大多数的年轻人一样，为了混口饭吃。毕竟天天在家里面对父母，吃闲饭也不是个事儿。

    进入公司的第一天，我遇到了职场小白们都遇到的问题，“我来了之后能干嘛？”报道、领工牌、领电脑，和同事们寒暄几句，剩下的就是坐着工位懵逼了。虽然有新人培训和“师傅”带着，不过心里的疑问始终存在。以至于入职一个月后我都不太清楚自己的职责是什么。90%的过往经历和所学似乎都已经用不上了，焦虑和失落就是每天的主旋律。这时候我经常问自己一个问题：“我是谁？我从哪里来，要到哪里去？”

《一切都需要归零》

接下来半年，我做了这几件事。

疯狂了解关于需求分析师的一切，寻找这个角色和我之前经历的所有交集。

    虽然说90%的过往经历和所学似乎都已经用不上了，但是庆幸的是90%的工作也不需要特殊的技能和门槛。需求分析师就是这么一个角色。（没有贬低需求分析师的意思，反而因为这样的灵活性，跑道更宽了。）2010年，国内关于产品/需求分析的论坛和书籍不是那么丰富（也许是我孤陋寡闻），汲取知识的来源还主要靠国外的一些书籍和网站，例如：IIBA（International Institute of Business Analysis）https://www.iiba.org/ 。 《Writing Effective Use Case》是我读的第一本关于BA的书，为我后来培养需求分析、写作能力做出了“金钱可以衡量”的贡献。当然现在可读可看的入门书籍资料非常多（毒鸡汤也很多），既然从头开始就不可以避免的要去学习，花大把时间积累迟早有回报。为什么我又在这期间寻找和之前经历的交集呢？因为我想把那10%能用到的过往经历再深挖一下，找出来自己可以马上创造价值的经历和经验（这样就不用站在鄙视链的底端），运用到工作中，可以起到事半功倍的效果。就算不行，也会多一点跟同事的谈资。

观察团队，了解他们需要的而却没人愿意/没能力做的事。

    需求分析师就是负责分析需求、写需求文档吗？这个肯定是最低要求。那时候的我除了做好这些本职工作之外，我也会在工作过程中观察团队最需要的、最不喜欢的、最不擅长干的而又不得不做的事情。可能这些事我也不能全部解决，但是不影响我去分析定位，找到这些事和我的契合点。

    “马上做”和“值得做”是我快速体现在团队中价值的捷径。这些事可能并不隶属于某一具体的职能部门，所以也就不妨碍我去开展。（注意别踩过界，刷存在感和抢功劳的事也少做，低调的存在是你生存下去的前提，至少前期应该是这样。）举个例子：当时我加入的团队成员都比较年轻，拼劲足，喜欢内部沟通，可是因为语言（英文）的原因很难和国外的团队沟通。我当时除了自己写需求讲需求外，也帮着一些同事分析其他国外需求分析师的文档，然后负责把一些问题归集，代表他们去和国外团队沟通，最后同步给他们。“别人不会，我会”这件事让我发现自身在团队具备“沟通力”的优势，可以体现“桥梁”的价值。“别人不愿意，自己会”体现在哪呢？刚开始写需求文档的时候，参考过很多的模板（包括前面提到的Writing Effective Use Case），但是不可避免的开发测试团队对文档的理解产生各种分歧（这个问题至今也不能完全避免），所以在需求文档中，我们（当时的一个产品经理也有这样的想法）添加了一段类似“伪代码”的流程描述，通过技术视角的“IF，Else”把一个业务和产品逻辑尽可能的描述清楚，其中对流程、校验、数据的要求和严谨程度可想而知，也带来了巨大的工作量，没人愿意做这件事，不过自己做了也就体现出了价值，产品质量明显提升，Bug率很低。

发掘自己的优势和能力，重新定位自己的Skill Set。

    在这半年，我还做了一件事就是思考自己到底有什么潜力值得培养。除了上面说到的沟通力，我发现工科背景出身可以更好的站在技术视角来看待问题，以更清晰、更完善的方式呈现自己的产品需求设计。也许我没机会成为一个技术牛人和架构师，不过也不妨碍我培养新的技能。所以我给自己定了一个新的能力养成目标 “沟通力”+ “分析能力”+ “写作能力”(主要是Technical Writing)，作为我立足的第一步。

如何体现你的价值？

    我觉得对于一个职场新人来说，不用因为这个问题过度焦虑。因为既然你能通过面试，就说明公司看到了你能带来的价值（或者有值得培养的潜力）。有人问我：“我是一个应届毕业生，刚开始做需求分析师。不懂技术、业务不熟、需求分析也不怎么懂。能给团队带来什么价值？”做最基础的工作也能创造价值，例如：画一张清晰的线框图，写一篇用词恰当语法准确的文档，给需求分类打上标签。。。看似简单的一些事都能让其他人看到价值（让我惊讶的是这些小事在很多所谓资深的产品人身上竟然都看不到）。简单的说，不要怕做一个“Office 碧池”，至少在职业初期不要排斥，看似无聊和枯燥的事情恰恰是最能锻炼人的。团队对于小白的容忍度还是比较高的，也有大量可以学习的时间和机会。利用好这段时间多问多看多学，注重积累。审视一下自己的特点和优势，重点培养。我花了大概3年时间在琢磨怎么做好需求分析和写好需求文档，甚至有时候为了推敲是否应该用“should”或者“would”而反复修改，可能有人会觉得这是一种文字洁癖。不过从我收到的反馈来看，大多数人都肯定了这种做事的态度。勿以“事”小而不为。

《伞兵现象》

    2010年出版的那本“人人都是产品经理”让很多在IT和互联网行业的一线码农们集体高潮了一次，发现自己还有成为“经理”机会。近些年在某些自媒体和培训机构不负责任的宣传下，大家对产品经理这个职位的认识出现了很大偏差，甚至于从业人员也有滥竽充数的现象，做着挂羊头卖狗肉的事。产品经理的定义比较广泛，我个人比较喜欢《The Product Manager's Desk Reference》书中的介绍，大家有兴趣可以看一下。各行各业都存在产品经理，目前关注度最高的可能就是IT和互联网行业。 成为产品经理的动机是什么？可能在很多人早期的职业规划中都是不存在“产品经理”这个选项，我自己也不例外。

    2013年的某一天，我被老板空降到了产品经理的位子上。像其他大多数产品经理一样，我也是被空投的伞兵之一。如果大家遇到一些年级比较大的产品经理（40+），他/她99%的可能性也是被空降到这个位置上的（也可以主动跳伞）。早期软件行业的产品经理基本都是从其他岗位转岗过去的，研发、市场、销售、设计甚至客服团队都可能是空降的来源。相比较其他空降的产品经理，我之前的从业经历似乎相关性更大。既然是“空降”那就不可避免要谈到“存活率”，很多空降姿势不对的“产品经理”候选人刚落地就“阵亡”了。还有挂在树上，坚持不求救和自救的，没多久也挂了。看到和听到过很多类似的故事，我对自己这次空降也就额外的注意。为了提高我的“跳伞存活率”，我做了如下准备：

从心理上正确对待“产品经理”的概念

    无论你相不相信，很多人是奔着这个title从事这个职业的，觉得“经理”属于中层干部，可以对别人呼来喝去了。首先明确一点，大多数的一线产品经理是不管人的，该干的活还要自己干，甚至干得更多（也就还是那个office碧池）。产品经理可能还要身背巨大的业务压力，以及向上管理，跨团队沟通的责任。在某些外企的组织架构中有可能BA是汇报给产品经理的（我当时的情况就是如此），所以也有可能承担一些管理职责。幸运的是当时和我一起工作的BA团队非常专业和优秀，并没有让我在团队管理工作中花太多精力。

评估当前职位职责和产品经理职责的差别

    虽然我做了3年的需求分析师，但是并不代表我能胜任产品经理的角色。分析需求和写需求更多是把既定产品概念具体化了，是一个执行的活。那时候我可能更像是导演旁边的副导，在剧本和主演已经定了的时候，也就只能根据剧本和导演的要求去找找临时演员。所幸的是之前我遇到过很多优秀的产品经理，在与他们共事的过程中学到很多经验，这时候就有了用武之地，可以快速复用，弥补这些差别。我一直觉得需求分析师是转型产品经理最容易的角色，需求分析师的沉淀和积累90%都是产品经理也应该具备的技能。相对于其他空降的角色来说，职责只是扩大了，而不是完全不同了。对于其他岗位空降的产品经理，也并不是说不能存活。可以参考现在比较流行的“业务型”、 “用户型”、“平台型”产品经理的概念，其实就是为了更好的让不同背景的产品经理适应和定位。例如：市场和销售背景的产品经理也许就会被定义为“业务型”。从这点考量上，我不赞同没有经验的毕业生从事产品经理的岗位，选择一个可以沉淀积累的起点，避免人浮于事。

学会接受不完美

    大多数人成为产品经理之后，必定是想大展拳脚的好好干一番事业。现实往往都是残忍的，千万不要带着“拯救世界”的心态做产品。管理层的战略可能是懒惰的，会直接影响你战术的发挥。技术团队可能不喜欢陪你拼命迭代，他们就是来打工赚钱的，没空跟你一起造梦。你接手的也可能是个垃圾产品，但是好死不死的市场份额巨大，老板让你在重构的基础上想办法继续维持老产品。当时我接手的就是这么一个在巨大市场份额和盈利能力下快速奔跑并且即将散架的ToB软件产品，因为它的架构太老，耦合性太强，配置点太多，业务流程太复杂了，以至于我们都不知道如何下手去改造它。经历了多次改造失败后，我试图劝说管理层放慢改造的脚步和认识鱼与熊掌不能兼得的道理。实际上也为我自己增加了落地存活率。接受不完美不代表不努力做好一个产品，而是说要在当下认清现实，做出适当的调整。让一个产品生存下去远比把它做完美更重要。

《写在最后》

    从2013到2017这四年里，我基本都在从事产品经理相关的工作，也慢慢觉得自己成为了一个真正的产品人，摸到了一些门道，也逐渐觉得当下的工作缺少挑战性。于是我膨胀了，在2017年做了一个让我“至今不后悔但是也大概率不会重复的决定”— 入职某宝。BAT可能是产品经理打怪升级的圣殿，也可能是自我摧残的最佳选择。到底是好是坏，众说纷纭，我也不做判断。重要的是任何一段经历都会带来收获，这段经历也不例外。通过这段经历我结识了很多志同道合的人，收获了一帮有情有义又不失才华和专业度的朋友，看到了从来没有机会接触的业务形态和惊艳的产品设计，当然吐槽点也很多。在众多值得回忆的片段中，我深刻的记得在即将撤出一个产品项目时，大家为我举办了一场欢送会。有人提议每个人用一个词来形容我，五花八门什么都有。一位合作了多时的架构师送给我一个标签：“Influence（影响力）”。我至今觉得这个标签是对我作为产品经理最大的肯定，也是我之前一直都没有意识到应该去培养的能力。“Influence（影响力）”在我看来是产品经理职业成长的最好标记，也是我顺利从大厂毕业的合格证书。作为一个职场新人，如果有机会的话，可以去大厂看看，毕竟简历也是要刷的。（如果本文阅读量过百，下次我就讲讲这段经历。）

无论你是产品的职场新人还是伞兵，下面的建议或多或少都可以帮到你：

    自我管理比向上/向下管理重要。自我管理约束的对象是自己，带来的结果是自我能力的提升。作为一个新人，重在提升自我。向上管理也重要，一个一直需要被向上管理的领导似乎也不值得长时间跟随。同理，假如你带团队，面对问题、解决问题，不要“逃避式管理”。

    别让战略上的懒惰限制了你战术的发挥。假如你可以制订战略，那恭喜你。但很多时候你并不是决策者，也没有话语权。战略制定者有时候是懒惰的甚至是愚蠢的，尽一切可能在一个懒惰、愚蠢的战略方针中，做出经过思考、分析、数据驱动的战术决策。假如你还能做到用“战术上的勤奋掩盖战略上的懒惰”，你也就离升职不远了。

   别让“金钱”使你沦为螺丝钉。对于职场新人来说，“物质回报高”是找工作的重要考量因素（至今也是我求职的要素之一）。但是千万不要变成唯一因素，如果有一天你发现在重复造轮子拧螺丝，你就应该考虑离开了。持续培养自己的核心竞争力才是王道。当然，如果这份工作可以让你在40岁之前财务自由，那另当别论。总有一天你会离开，除了你赢得的物质报酬之外，最值得带走的就是“思考力”。

----------------------

本文属于转发

原文链接：https://mp.weixin.qq.com/s/0xABExANjudcy2dI7y-uCg