产品经理的三年叙事与协作思考

　　产品经理和研发工程师的关系经常被大家调侃，可偏偏就有同时受到研发和设计都喜欢的别人家的产品经理，沟通协调、对接需求、项目把控面面俱到还有好人缘。有没有人天生就是产品经理？产品经理的工作就是写需求写需求和写需求么？顶级公司的产品经理都是如何锻炼技能，提升思考能力的？
　　我的Facebook轮换制产品经理经历
　　我在美国的私立文理学院PomonaCollege读的本科，学计算机和经济双专业。之前在Atlassian还是小公司的时候我给他们做过产品营销，还有曾在微软做过产品经理的实习的经验。
　　因为这些经历，很自然的在大四的时候收到Facebook从领英上发的邀请，邀我去参加他们轮换制产品经理的活动，我也从那时开始了解轮换制产品经理的项目。
　　经过了三轮电话面试和三轮终轮面试，很幸运的在两天之后就拿到了他们的offer，也是第二个进入这个项目的中国人。当年我也被麦肯锡和波士顿咨询公司的美国办公室录取做咨询师，经过非常艰难的决定，最终选择了去Facebook做产品经理，现在看来这个决定是很正确的。
　　我们那届一共有12个人入选这个项目，其中的10个应届本科毕业生大多毕业于斯坦福、麻省理工、伯克利这种工科名校，还有2个是哈佛和斯坦福的MBA毕业生。
　　进入Facebook之后，我首先在Instagram，FacebookPage和视频广告三个产品进行轮换，每个时间是半年。从这个项目毕业之后我就去了视频产品工作，到现在已经是三年的时间了。
　　轮换制产品经理项目非常有意思，Facebook从2012年开始这个项目，当年的很多人现在已经成了高级产品主管的公司中流砥柱，负责很多重要项目。
　　其实我们也是借鉴了谷歌的产品经理项目的模式，Yahoo的前CEO玛丽莎梅耶尔曾经在谷歌担任产品经理，她建立了谷歌后来闻名遐迩的产品经理项目，每年在全球挑选和培养三四十个刚毕业最聪明的年轻人，让他们一上来就直接开始带团队管产品。
　　这些年轻人会得到对公司成功非常重要的顶级项目，并且会有专人对他们进行各方面的培训，还会组织一次环游世界的游学，玛丽莎亲自带领他们和世界各地的用户交流，拓展他们的视野。
　　红杉资本的首个女性高级合伙人JessLee之前担任Polyvore公司CEO（被雅虎2亿美元收购），就出身于玛丽莎开创的这个谷歌产品经理训练营，在谷歌担任了4年的产品经理。这个项目还出了下述著名产品经理，堪称人才辈出。
　　Dropbox的产品总监JeffB
　　融资上亿美元的任务管理创业公司Asana的创始人JustinR
　　被Salesforce以7。5亿美元收购的Quip创始人；
　　曾任Facebook首席技术官的BretT
　　AB测试公司Optimizely的两位创始人DanSiroker和PeteKooman等等。
　　我个人在参与Facebook的产品经理项目一年半的时间中，快速跟进各种类型的产品，需要很快适应不同的团队。比如Instagram当时就是有亿万用户的产品，FacebookPage则是针对中小企业的商业产品，而视频广告是针对广告商的诉求，这些产品目标群体，成熟阶段和团队文化都差得非常远。
　　在这个过程中我看到了进展缓慢、杂乱无章的团队，与有效率有激情的团队之间运营和管理模式的区别，这帮助我在现在管理团队的时候能够趋利避害，绕过很多坑。
　　从进入这个项目一开始，我就担任产品经理的工作，也就是说团队的人不论多高级的工程师都自然地把我视为团队的领导，虽然在那个时候，我还是一个没有多少工作经历的黄毛丫头。
　　所以一开始真得特别有挑战，亚历山大。开始负责的第一个产品是一个比较小的功能，后来我的项目一个比一个大，做的决定一个比一个多，工程团队也一个比一个大，这也是Facebook有意设计的一个循序渐进的过程。
　　公司非常注重这个项目里的年轻人，所以特意安排我们参加一个为期两周的世界旅行。我们去了南美洲和非洲的三个国家，去和不同文化环境下的Facebook用户沟通，了解他们的不同诉求，去感受网络状况截然不同的、经济条件千差万别的人们怎么使用Facebook。
　　这是公司的传统，每一届的轮换制产品经理都会和公司高管一起去三个不同的国家，增强他们的国际视野。而通过这个过程，我们也能很好地和其他的年轻产品经理们增进友谊，是一笔宝贵的财富。
　　不同公司内产品经理文化的异同
　　我曾在Facebook、Instagram、Microsoft等公司工作过，关于产品经理文化的异同，我认为可以大概这样区分：
　　在Facebook，非常注重工程导向，喜欢用数据说话。很多产品功能的设计和发布与否的决定，都取决于成功数据指标。这包括短期功能指标也包括长期产品线成功指标。我们有非常强大的数据分析和AB测试系统，能够非常清晰地了解新产品在世界各地的使用情况，也有非常聪明的数据科学家帮助我们发现数据中有意思的地方，从而改进产品策略。
　　Instagram相对而言，是一个很注重产品体验跟设计感的公司。产品经理们喜欢从用户的内心体验和诉求出发，去思考产品的功能如何满足这样的诉求。产品设计师在公司具有很大的影响力，尽管数据很好看，但是如果体验本身不符合Instagram的产品形象，可能也不会发布。
　　Microsoft更流程导向。公司毕竟已经非常大了，各方面都有成熟的流程和要求。这可能导致项目进度没有Facebook这么快，但是在文件信息存档方面优于Facebook，即使一个产品换了产品经理，也能很快了解产品进度和相关信息。这方面，Facebook更喜欢口头做决定，很多决定没有落实在纸上，进度虽然快，但是一旦调换产品经理，新来的人需要花很久时间才能跟得上。
　　关于面试
　　我比较在乎面试者的产品感和分析问题的能力，其实在这两个方面，不同级别的产品经理我问的问题很相似，因为我觉得级别并不一定代表这两方面能力的高低。
　　我会让面试者从头到尾设计一个产品，看看他思考的过程，如何从用户需求出发，如何权衡取舍，如何设计用户体验。我也会让面试者分析某个数据突然下滑，有什么方式能够细化问题，如何找到问题的要害。
　　这些问题，都不需要面试者用某个领域的专业经验或者以前的工作经验来解决，我在乎的是他们如何思考一个新的问题的能力。
　　我认为非常优秀的面试者是一个非常好的思考者。比如一个简单的产品指标怎么定的问题，优秀的PM面试者会告诉我短期的小目标是什么，长期的大目标是什么。
　　比如一个帮年轻人找导师的产品，一个特别好的面试者告诉我，这个产品最重要的是帮助年轻人找到好的职业导师，从而帮助年轻人更好地提高自己。
　　长期来看，我们可以看这个年轻人的薪水有没有涨，和这个导师的联系频率；
　　短期来看，我们可以看看每个用这个产品的年轻人找到了几个导师。
　　产品刚发布的时候，之前的这两个指标都不重要，因为年轻人必须有导师搭理他们才会继续用这个产品，所以更重要的是年轻人给导师发消息后导师的回复率。
　　产品经理是天生的么？
　　我认为产品经理最重要的能力有三个，这三个能力我倒不觉得都是天生的：
　　第一是沟通能力，能够和不同性格风格的人沟通；
　　第二是影响力，能够让团队充满激情，鼓舞团队；
　　第三个是方向感，能够给大家描绘一个成功的产品体验长什么样，帮助大家编织一个可以付诸行动的梦想。
　　第一个沟通能力，来自于产品经理积极和不同的人聊天，对他们的需求和性格的敏感捕捉的能力；
　　第二个其实有点像销售的能力，能够鼓舞大家，我觉得多做其实也是可以提高的；
　　第三个，我觉得需要对其他学科知识的积极学习，对新生事物的热情，和不断学习的能力。这三个在我看来都不是所谓天生的，而是后天可以培养的。
　　从事技术的人一般有比较强的逻辑思考能力，有比较强大的分析思考能力的人会更擅长把控方向，这是一个可发扬的优点。可能会欠缺销售的能力和沟通的能力，这一点，我认为可以通过私下多和其他人沟通，积极参加一些组织活动来锻炼。之前运营的人销售能力和沟通能力比较强，但是产品感和方向感稍微略逊，还有就是可能对技术完全不了解，这也是可以通过后天的学习来提升的。
　　对于缺乏经验的选手，最重要的是突出自己已经有的优势。我们在乎他们的潜力，而潜力就是展示自己已有的优点，让面试官觉得是可以培养其他技能的。
　　所以对于技术也好还是运营也好，一定要先思考自己的优势和特点，如果把你放在人堆里，你的什么特点是可以脱颖而出的，然后在面试中淋漓尽致地体现这些特点。毕竟对于这类经验缺乏的选手，最重要的是让大家记住你，让面试官有这个人不一般的感觉。
　　产品经理的协作模式
　　与运营团队
　　我觉得产品运营对于产品的成功至关重要。很多人说产品运营的门槛低，什么人都能干。其实找到一个优秀的运营人才，非常难，有了优秀的运营人才，作为产品经理才能把自己的愿景付诸实践。
　　我以前认识一位非常优秀的运营人才，总是能另辟蹊径，把我产品功能的一些天马行空的想法付诸实践，制定合理的运营流程让这些想法能够投入实际。一个优秀的运营人才，让产品用最好的体验满足用户的需求。
　　在和运营团队的合作之中，我认为有以下几点需要注意。
　　第一，工作边界。一般我会和运营团队提早沟通，向他们介绍产品的计划，提前商量好合作的模式和负责范围，以及产品开发和运营团队各自的成功指标。尽早和运营团队进行合作，而不是等到产品发布的那个时候才开始合作，能够避免很多问题。
　　第二，给其他人机会。我个人的理念是，如果其他人有好的产品想法，即使看上去提的问题是产品经理会做的，我也会让这些人有机会展示。毕竟，我的团队有40多个各个职能的同事们，指望我一个人把所有东西都想到是根本不可能的，我觉得一个好的产品经理是能让团队里的每一个人都有能动性，思考产品经理的问题。我并不觉得他们提出产品经理会做的事情，就说明我这个产品经理当得不好，相反，我觉得能够激发团队能动性的产品经理才是好的团队领袖。
　　第三，我一直觉得内容运营和用户运营本身就是产品体验的一部分。比如当年Airbnb要是没有运营团队拍摄高质量的房屋照片，根本没有后来的客户增长和成功，我觉得运营团队本来就应该是产品体验的一部分，作为产品经理，我一直把内容运营或者用户运营想成是产品的一个功能，和增加一个按钮，设计一个留言板一样，都应该是产品体验的功能。
　　与技术团队
　　一个优秀的产品经理能够让工程师兴奋起来，满腔热情地投入到产品的开发之中。而这种热情一旦被激发出来，产品经理就不用担心工程师会拖延工期、消极怠工，相反工程师甚至会比你更积极。
　　想象一下，工程师催着你赶快出需求档案，催着你赶快思考营销策略，向你提出他的新功能的思考，这是一个多么事半功倍的合作啊。
　　在我的产品经理生涯中，至少合作过上百个工程师。见过刚毕业不久，满腔激情想赶快升职加薪的工程师，见过想解决最高难度的技术问题，哪怕产品没人用只要解决的问题高难度就高兴的工程师。见过一个满肚子主意，极其讨厌PM告诉他该做什么的点子大王。还见过一个有些害羞，很多想法憋在心里，但是其实特别希望自己有存在感的人。
　　最终我领悟到，作为产品经理需要先知道他们在乎什么，然后就知道怎么能激发这些人的能动性，并且该让什么人做什么样的项目。
　　想升职的工程师肯定喜欢做老板能看得见的项目，哪怕这些项目并不一定有多么高难度，帮助这些工程师在老板，面前出出风头，他们肯定对你死心塌地。
　　技术宅，那就强调一下这个项目的哪些技术问题别的工程师想想就头疼根本解决不了，满足他们技术宅的虚荣心。
　　点子大王，那就找机会表扬他点子很多，就算想法是你想出来的，和他交流的时候循循善诱，引导他说出你的想法，然后赞叹他的想法真厉害。
　　比如，如果你认为应该做一个在视频平台上做一个让用户能够发弹幕的功能，不要和点子大王说你负责做弹幕，而是从问题出发，说‘我们的视频互动性太低，用户都不喜欢发评论’，然后引导他自己说出来做弹幕的主意。至于害羞的工程师，当你在开会的时候刻意给他们表达自己的机会，他们绝对对你感激涕零，期待着和你继续的合作。
　　知道工程师要什么，想办法在现有的项目里给他们这样的机会，会让你们之间的合作事半功倍。所以现在每次和新的工程师合作，我都会约他们喝咖啡，聊聊天，扯扯家常，然后问问他们在乎的是什么，什么东西能够激发他们的激情，然后对症下药。
　　组织高效率的需求评审会
　　我觉得需求评审会的目的有这么几个。
　　第一，让全组人都了解产品需求解决了哪些问题，并且让大家相信这些需问题确实存在，而且确实需要现在来解决。我们会提前通过用户调研、数据分析等方式展示已有的信息，鼓励大家积极提问题和提出质疑，并且确保每个人都了解我们到底解决的问题是什么，为什么要现在解决。这是非常重要的，一定要在讲述需求之前先明确解决的问题。
　　第二，让全组人了解权衡取舍的评判标准。一般常见的情况是，需求有很多，根本没法在第一个版本就全部解决，这个时候我需要向大家展示每个需求的机会有多大，这方面可以参考相似功能、或者做一些估计的模型来估测产品的潜在机遇。
　　第三，让设计师或者工程师都有能够表达自己的质疑和问题的机会。提前判断项目的难点在哪里，比如，数据模型可能根本不支持这个新功能等，让大家有机会提意见。
　　现在有很多效率低下的评审会，我认为原因有几点：
　　第一是准备不足，并没有提前找到足够的数据和用户调研信息来佐证哪些需求的价值最大；
　　第二是，没有人管理时间。应该提前明确多长时间会要开完，然后当发现大家在讨论无足轻重的细节问题时，需要有人来说，我们这个之后对做需求决定没有直接帮助，所以之后再说；
　　第三是，邀请的人员有问题。邀请太多人，有些人从来没听说过这个项目，问一堆初级的问题浪费大家的时间。有些人其实并不需要做需求的决定，只需要决定之后告知他们即可。
　　第四是，没有提前讲清楚我们的会议要达到什么结果。比如这个会议的目的是明确解决的问题，制定出需求的优先级。除非这个功能做不出来，我们没必要讨论需要放几个工程师在这个项目上，工期估计可以稍后进行。或者比如这个会议的目的是做出决定时做A还是做B，那么没必要讨论功能C，他对这个会议没有帮助。
　　AI时代的产品经理技术思维
　　第一产品经理需要积极学习，掌握一些基本的AI知识，比如如何训练模型，要训练这个模型，大致需要提取什么样的信息，如何提取这些信息。具体的算法优化，倒并不见得要产品经理非常懂，我平时工作中需要的更多的是知道什么情况下需要用AI，MVP的模型怎么简化，需要得到什么样的信息，如何衡量模型的优劣。
　　第二还是要立足用户的需求。不能单纯为了用AI而用AI，还是需要从要解决的问题出发，制定产品的成功指标，然后思考AI如何帮助我们更进一步，更好的达到成功指标。而不是我们的产品要酷炫屌炸天，要用AI，所以从AI功能出发，看怎么样能适用于自己的产品，反而可能会忽略用户真正的需要。