作者：苏杰
写在正文之前
所以我一直在酝酿，一直感觉没准备好，但越来越发现如果这样想我永远都不会准备好，因为所谓的完全准备好也就意味着我在各方面都已经到达顶点无法继续提高了，显然我是不希望有这样的一天的。
应该体现出的是“一个优秀的产品经理应该做到哪些”，而不是“一个阿里的产品经理应该做到哪些”；
产品经理做的事情，不似技术那般严谨，很多偏“艺术”的思维方式、做事方法必然只在特定环境下才适用。
我们应该养成一个习惯，当看到一个观点的时候，就有冲动去寻找与之矛盾的观点，然后通过对不同观点的分析找出背后的原因，从而更全面地理解某个事物。一个人成熟的标志之一就是心中可以容纳各种不同的思想而无碍行事。与君共勉。
自序
只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理。
一个成长中的产品经理，期待和同学们一起，用好产品改变世界。
1.2 我们到底是不是产品经理
产品是一组将输入转化为输出的相互关联或相互作用的活动”的结果，即“过程”的结果。在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。产品的狭义概念：被生产出的物品；产品的广义概念：可以满足人们需求的载体。
第2章 一个需求的奋斗史
用户说了很多需求，产品经理要“听用户的但不要照着做”，必须“明确我们存在的价值”是“把用户需求转化为产品需求”，这一过程即需求分析过程。产品经理要通过“给需求做一次DNA检测”，来“确定需求的基本属性”、“分析需求的商业价值”、“初评需求的实现难度”，从而计算出需求的“性价比”。
其实对于产品经理来说更重要的是“发现一个问题，然后设法将其转化为一个任务来解决”。
2.1 从用户中来到用户中去
人本主义心理学家亚伯拉罕•马斯洛（Abraham Maslow）提出了需求层次理论（Need-hierarchy theory），此理论将人的需求划分为五个层次，由低到高，并分别是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。
这时候老板肩负起了部分产品经理的职责，起到了采集用户需求并分析、筛选的作用
试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪，谁都不满意的四不象。
经历了这些对话，我想表达的就是，想了解用户，光靠空想是不行的，他们是真实的，是五花八门的，必须得真刀真枪地去研究他们。
有形的Persona存在的更大意义，可能并不是给创建者自己看，而是有新人进团队的时候，可以迅速了解用户，理解产品，同时忙碌的无法关注细节的老板也可以利用Persona迅速进入状态，保证他们也能像创建者一样，时刻心中想着正确的用户形象。
定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。
2.2 需求采集的大生产运动
但这些用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
用户访谈经常出现如下问题：第一，“说”和“做”不一致的问题。用户经常会骗我们，先看一个经典的索尼游戏机的故事。索尼找了一些用户来，问他们喜欢黄色的还是黑色的游戏机，结果发现说喜欢黄色的用户比较多。之后，索尼告知用户为了感谢他们的配合，将送他们一台游戏机，颜色可以任意挑选，而同样一批用户选择黑色的游戏机带回家的更多。很明显，有部分用户说喜欢黄色却带走了黑色的游戏机。用户倒不是想故意欺骗我们，而可能是：他们被问了自己也没仔细想过的问题，又不想回答不知道，就在现场编造了一个看似有理有据的理由，或者他们有讨好访谈者的心理，会回答他们觉得你希望听到的答案，而不是自己真正的想法[插图]。
为了用尽可能少的样本得到尽可能正确的结论，我会以增量的方式做访谈。举个例子，我会先访谈5个用户，得出基本结论，然后再访谈5 个，观察结论是否有改变，如果有改变，就继续加大样本量，或者思考问题是否合适？样本集是否合适？如果没有改变，就停止继续访谈，节省成本。
要解决这个问题，需要时刻牢记访谈的目的。如果发现话题不对，就赶紧往正道上扳，若发现多次都扳不过来，就可以考虑尽快结束了，用户很多，不要在一个不合适的对象上花费太多时间。当然，有时候用户侃得十分精彩，如果你不是很忙的话，听听长长见识也可以，这个就自行把握吧。
► 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。► 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。► 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。► 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。► 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。► 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。
无论是网上还是线下，作答时间最好不要超过10分钟，否则很多人看一眼就被吓跑了。开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放在中间；而有关被访者个人信息的题目一般放在问卷的最后，以免应答者在回答这些问题时有所顾忌，进而影响其他答案。
《长尾理论》里说到“沉默的大多数”，那么站出来的总是很少数，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”说的是，大多数人是没有明确观点的，尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群体的观点，随机的初始值决定了结果，这个时候你只有单独和跟风者交流，才会发现他根本不是那么想的。
它是UGC理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程
记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。
好在参加测试的用户对我们说了“Yes”，上线后数据分析的答案也是“Yes”，我们才没有因为缺乏经验而造成太多损失。在这之后，我再也不敢这么晚才做可用性测试，联想一下淘宝网“我的淘宝”曾经做过的改版、2007年底豆瓣为了庆祝注册用户过100万的改版、2009年百度贴吧的改版，都因为用户的反对声音太大不得已道歉、改回去，我们真的很幸运。
第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。
undefined
[插图]
[插图]
[插图]
2.3 听用户的但不要照着做
用户跟福特要一匹更快的马，福特却给了用户一辆车。
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。 产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。 需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
满足用户的需求，不一定要做新产品或者新功能，而是更应该想想是否有“四两拨千斤”的妙招。
我们后来发现还有其他的解决方案，比如电梯广告，不但可以转移用户注意力，减少抱怨，而且对写字楼来说，既不用花钱，又额外挣得一笔广告费；
举个例子，对于我经常做的软件产品，用户需求是“删除数据之前需要我确认，以免误删”，转化分析以后，我们给出的产品需求可能是“数据回收站：删除的数据进入回收站，如果是误删，用户可以去回收站找回数据”。
分类：可以分为“新增功能、功能改进、体验提升、Bug修复、内部需求”等。
有时候我们还在列表里增加一列“商业价值描述”，通俗点就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。
开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师。
绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。
2.4 活下来的永远是少数
这是一场公司内部的战争，每个产品的产品经理都要上场，打仗总是为了抢点什么，我们争夺的是下个月的人力资源，即总是不够用的开发工程师、测试工程师等。战场就是闻之色变的产品会议，而我们手上的武器，则是精心准备的商业需求文档。
按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。此外，各种职能的员工之间沟通顺畅，单线领导，开发的头、测试的头等都向产品经理负责。按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。此外，资源战争可以把“鲶鱼效应[插图]”从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。两种组织结构，给我“一攻一守”的感觉，产品在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就多用职能线来更充分地利用资源，因为在成熟的产品团队中，要做的事情通常比创业时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加的稳扎稳打，所以按职能线划分以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。
我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5人天”。
情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。
“少做就是多做”，阿里巴巴的马云也说过。
3.3 关键的青春期，又见需求
几年前看一个叫“Michael on Product Management & Marketing”的博客，它讲述了产品设计中的几种核心文档，我结合实际工作整理之后，形成了我心目中产品从抽象到具体的过程主要产出的文档：BRD、MRD、PRD和FSD。 BRD：Business Requirements Document，商业需求文档。这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、盈利预测等，通常是给大老板们演示的PPT，也就比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要为了获得认可，争取资源。 MRD：Market Requirements Document，市场需求文档。获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级，等等。实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。 上述两份文档都是给老板看的，里面偏商业的内容，我会在第5章“别让灵魂跟不上脚步”里做更多描述，接着往下看。 PRD：Product Requirements Document，产品需求文档。PRD是对产品功能的进一步细化，是PD新人写得最多的文档，也就是我说的“需求开发”过程。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述，更多内容在下一节详细讲述。 FSD：Functional Specifications Document，功能详细说明。比较像我们常写的用例文档，经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左、中、右对齐？保留几位小数？等等。有一点像“概要设计”。与此同时，硬件系统的设计、数据库设计、表结构设计等工作，也开始由架构师、系统分析师们编写了。 需要说明的是，每个公司并不会严格地写这么多文档，比如我在阿里待过的团队主要写BRD和PRD，我们说的BRD实际上包含了上述BRD和MRD的核心内容，PRD实际上包含了上述PRD和FSD的核心内容；而百度有的团队主要写MRD，包含了上述前三种文档的主要内容。有时候叫法相同内容不同，有时候叫法不同内容相同，关键是我们要知道写这些文档的目的，说清楚哪些事就可以了。
3.4 成长，一步一个脚印
我们会把“需求评审通过”视为项目中一个重要的里程碑，称作“需求确认”或“需求冻结”。之后进入开发阶段，如果还需要修改需求的话，不是不可以，而是要更加慎重，甚至是强制走一些需求变更的流程。这也是为了更好地控制项目风险，在信息充分的情况下，随着项目的进行，风险应该越来越小，否则项目必然有问题。
使用Quality Center相比Excel的好处在于，每个Bug重要的状态转换点，系统都会有邮件通知到相关人员，防止遗漏；项目中每个人在系统里的角色不同，权限不同，此软件可防止误操作，甚至是一些恶意行为，比如开发人员就不能把Bug状态改为Closed；所有操作都有记录，谁在何时做了什么，便于追溯。这些都有效地防止了人为因素导致的问题。
能安排在白天的工作时间固然好，但很多互联网产品为了避开用户使用高峰，必须安排在晚上进行，难免弄到深更半夜。我们很多同事工作完时都已经见到第二天早上的太阳了，这时候作为产品经理兼项目经理，还有一件重要的事情——别忘了给大家买夜宵！
之后，写一份项目小结，对于一个几周到两三个月的项目来说，比较合适在发布后半个月内完成。小结一下做这个项目的心得体会，比如碰到了哪些问题，原因是什么，怎么解决的，如何避免再犯；项目的资源评估是否合理，收获了哪些经验，如何提高准确度；根据数据监控的反馈，分析出了什么结果，项目的商业目标是否达到，等等。
搭车事件，是指项目范围的扩展，一般来说，5个开发工作日以下的零散小需求不参与产品会议讨论，所以搭车事件总是存在。
3.5 山寨级项目管理
这时候千万别自作多情地又增加一个模板，因为这不符合“奥卡姆剃刀原理”。用一次就束之高阁的模板，就像只制订却不执行的规定，只会反过来降低已有规定的权威性。
当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力。
产品会议：必须有，决定“做不做、做多少”实在太重要了，方向错了很可怕
任何情况下，我们都要做好手头的事情，确保“就算这事儿对公司来说又黄了，我也要通过做事有所收获”。
3.6 物竞天择适者生存
请赐予我力量，去接受我所不能改变的；请赐予我勇气，去改变我所能改变的；并赐予我智慧去分辨两者的不同。
4.1 大产品，大设计，大团队
产品，此处是狭义的，由我们平时说的“产品部门”，包括产品设计、用户体验、产品运营等部门来考虑，他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。
非常明显，Google是技术主导的团队，从一位在那里做过市场工作的女生那里了解到，工程师在Google拥有绝对的话语权，而市场人员的地位相对较低；Apple则是无可争议的产品主导型公司，它的设计已经拥有了一种气质，它的产品几乎件件都是艺术品，就算现在Apple做个手电筒，叫iTorch，我相信也能卖出不少；而Alibaba就是第三个方面——商业主导的了，商业的强势也说明了阿里为什么不招技术很强的应届毕业生，而Business Sense，商业感觉是在真实的商业环境中工作磨炼出来的。
《用户体验的要素》
这五轮，实在是很像互联网产品设计的五个层次：战略、范围、结构、框架、表现。
本能水平就是纯生理的视觉冲击，就像“第一眼美女”，看上去就喜欢，没什么好说的；至于行为水平，我认为就是《设计心理学》一书的主要内容，主要讲的是产品功能、与用户与产品交互层面的设计；而反思水平则是诺大师思想的又一次升华，通过《情感化设计》一书，把纯心理需求也纳入了产品设计的考虑范围。
简化：充分利用用户已有的知识，利用心智模型，利用标准化，利用一切。
矩阵型组织则是上述两种组织结构的融合，如图4-6 所示，就是前两年某段时间我身边的组织结构，横向是产品线、业务线，为了对客户负责；纵向是资源线、行政线，为了资源共享。如果说职能型组织比较适合防守型的业务，项目型组织适合进攻型业务，那么矩阵型组织就是全攻全守。但它也有很明显的问题：对员工来说，一面是部门经理，另一面是产品经理，这样的“双头领导”总是很让人头疼，那么这两种职位可以通过兼任来解决矛盾么？  图4-6 矩阵型组织 有一次培训的时候，老师给解答了这个问题，答案是否定的。产品经理主要管事，有成就感，像“猎人”，类比到军事上，就是对打仗负责，需要有攻城拔寨的能力；部门经理主要管人，有权力，像“农民”，对练兵负责，贡献技术与人，有防守与后勤的感觉。那么，部门经理如兼任产品经理，就会用权力来寻求成就感，或者在产品KPI的重压之下，放弃农民的责任去做猎人，造成行为的短视，主动或被动地忽视团队能力的提升。这是人性的弱点，无法避免，目标不同导致手段不同。在矩阵型组织下，部门经理和产品经理就应该各司其职，至于“双头领导”的协调，应该由用人的产品经理提供建议，养人的部门经理决定对员工的考核，同时培养每个人对事负责的态度。
4.2 游走于商业与技术之间
有一个很有意思的现象，PD团队的成员，原来做什么的都有，有做开发、测试的，有做市场、销售的，也有我这样毕业了直接入行的。而技术团队则绝大多数都是上学时学技术，毕业后也做技术的。从这个角度，我们就可以看出，PD作为整个团队的核心是合理的，因为PD团队的人员背景多种多样，可以和周边任何团队的同学顺利沟通，起到连接器和润滑剂之类的作用。
PD之前做什么不重要，我们必须是一个通才而不是专才。
所以由一个人最终来统一语言风格是很有必要的，而语言风格又是由产品想传达给用户的气质决定的，
在现实中，产品与运营却总是充满矛盾，经常看到他们吵得面红耳赤，这又是为什么呢？ 通常是因为运营的同学背着更直接的商业指标，比如年底前网站的PV（Page View）要达到1亿，用户活跃度要达到60%。大老板们的出发点通常都是好的，但传达到执行层面以后，就只是一个数字了，大家忘记了数字背后的目的。虽然说这样的简化、量化便于管理，但麻烦的是，数字总是有漏洞可以钻的，所以经常就是运营为了数字而数字。 如图4-18，是我身边的一个网站产品在2008年底做的运营活动，当时用了很多手段，有些甚至近乎“流氓”，可以看到数字是出现了爆发式增长，达到了PV的预期目标，但问题在于：PV并没有留住，两个月后再看PV的时候，发现和运营前没什么区别，数字背后的目的——增加网站用户数，并没有达到。  图4-18 运营的短期与长期效果 产品团队与销售团队也常常因为类似的问题而争论。这是运营的错，没分清目的与手段，只为提升PV拉了很多垃圾流量，而如果挖掘真正的用户则需要做更多工作——去寻找目标用户、去调研、去与产品团队合作；也是产品的错，那么多的PV，居然一点儿人都没留住；也许，更是数字惹得祸，老板们是否可以用更合理的数字来避免问题？比如追求注册用户数、活跃用户数等，而不是PV？也许，那些数字更难，或者看上去不会这么好看。
有人说史玉柱是最好的产品经理，他强就强在对用户、市场、产品的理解上，他可以为了卖脑白金和N个大爷大妈聊天，也可以为了做网游没日没夜地玩……看过他写的脑白金推广计划，确实有酣畅淋漓的感觉，如同一场战争的策划。
这个帖子确实带来了很多流量，但质量不佳。访问者中，新访客占到了约80%，远超出我博客整体50%左右的新访客比例，只看一个页面就离开的比例，即跳出率达到70%，也高出博客整体十几个点。
4.3 商业团队，冲锋陷阵
我们觉得某样东西虚只是因为对它不熟悉而已。
当自己对某个领域不熟悉的时候，做起事来总会把问题想象得很复杂，把自己知道的所有知识都用上，而真正的高手，是可以一下子就找出问题的关键，然后用最最简单的办法就搞定。
当自己对某个领域不熟悉的时候，做起事来总会把问题想象得很复杂，把自己知道的所有知识都用上，而真正的高手，是可以一下子就找出问题的关键，然后用最最简单的办法就搞定。
<aside> 💡 确实是这样，拥有大局观的人往往不会吧事情想的很复杂
</aside>
有的在原有版本的基础上，添加一些鸡肋功能做一个价格高出很多的“高价炮灰”，让消费者觉得商家真正想卖的那个版本特别实惠。一个特殊的例子就是在“抢市场而非赚钱”的商业目标指引下，主推免费版的同时还放出一个其实并不想卖的付费版本，以保持免费版的价值感。
卖个包子都可以有这么多的创意，我们看到，营销也不一定要一个劲地让产品在红海中搏杀，而是可以通过这些点子帮助产品在愈加同质和超竞争的市场中找到自己的蓝海。
服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值；销售部门是为今天的利润工作，把产品变成利润，争取更多的客户；开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖；研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先位置。
服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值；销售部门是为今天的利润工作，把产品变成利润，争取更多的客户；开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖；研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先位置。
<aside> 💡 很多时候 公司只注重当下的利润 这是不全面的
</aside>
服务的最高境界就是：用户使用正常的时候，绝不打搅，而当用户需要帮助的时候，电话立刻就响了。
4.4 技术团队，坚强后盾
有极少数热衷于技术的人，缺乏必要的责任心和使命感，做项目是为了钻研新技术，钻研新技术是为了更好地跳槽，把项目的成败放到次要地位，甚至在项目的最关键时候提出辞职以此要挟老板涨工资。碰到这类人只好自认倒霉，去找HR哭诉吧。
人性的弱点决定了在争论的过程中每个人都希望自己得到认同，而这点往往导致思路的变形，不再考虑产品怎么做更好，而是去想如何说服对方，并且，经常有同学会把对人的反感转移到对此人观点的反对上，这很可怕。
4.5 容易被遗忘的角落
刚从学生变成一个职场人士时，总会保留一些习惯，比如把老板当作老师，总是心存敬畏。几年下来，我的体会是，不要怕老板，或者仇视老板，而是要把老板当作最好的资源，“利用”他们促成自己不断成长
4.6 大家好才是真的好
有选择不如无选择：奖励或送礼的时候最好不要让接受奖励或礼物的人自己选择。不然的话他会有“我放弃了另外一种选择的感觉，患得患失反而不开心”，经典反例就是：奖励团队“海南游”或每人“现金2000元”。