启示录

思维导图总结请猛击：https://www.xmind.net/embed/FAMb/

评估产品机会： 1.产品要解决什么问题（产品价值） 2.为谁解决这个问题（目标市场） 3.成功的机会有多大（市场规模） 4.怎样判断产品成功与否（度量指标或收益指标） 5.有哪些同类产品（竞争格局） 6.为什么我们最适合做这个产品（竞争优势） 7.时机合适吗（市场时机） 8.如何把产品推向市场（营销组合策略） 9.成功的必要条件是什么（解决方案要满足的条件） 10.根据以上问题，给出评估结论（继续或放弃） 机会评估只讨论待解决的问题，而暂时无需涉及到具体的解决方案。 产品经理应了解必要的财务知识，对产品应有成本-收益计算。 产品对于产品经理而言分为两个阶段：探索并定义产品、产品开发阶段。可以采用流水线的方式并行开发产品，即在产品1.0版本的开发阶段，即开始定义产品2.0版本。 产品经理应该探索是否有用户需要产品，即寻找市场，让用户验证你的构思；其次，产品经理要探索能够解决问题的产品方案，它必须是有价值的、可用的、可行的，并请用户和开发团队来验证。 确定产品原则并按重要性排序：产品原则不是产品功能清单和界面、交互设计原则，也不依赖任何单独产品，而是整个产品线的战略指南，是公司的价值宣言。 组织产品评审团的难点在于既要为高官制定产品决策、监督产品流程提供透明的信息，又要避免高官插手干预产品团队的具体工作，比如亲自参与设计产品。 产品评审团根据四个里程碑来评审产品： 1.评审产品战略和产品路线图，请产品经理开始评估产品机会； 2.根据评估产品机会的结果，决定是否开始定义产品的解决方案； 3.评审产品原型、用户测试结果、成本估算明细，决定是否开始开发产品； 4.评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。 产品经理必须深入参与创建人物角色的工作，而千万不能外包。 不要再写传统的价值不高的纸质文档了，效果最好的产品说明文档，应以高保真原型为主，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。 虽然需求调研和产品设计可以同步展开，产品开发和测试可以交叉进行，但是用户体验设计应该在软件开发前完成。 推荐的产品设计方式： 1.产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。 2.邀请一位开发人员（比如架构师或主程序员）参与设计原型。 3.在开发产品前，产品经理和设计师必须通过让真实用户验证（测试）产品原型，来确认产品是用户需要的。 产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段，处理用户反馈意见。 敏捷开发： 1.产品经理即是产品负责人（product owner），他代表了客户的需求。 2.使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求文档。 3.产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期。 4.尽量把产品设计工作拆分成独立的部分，但也不能拆得太细，目标是设计出符合基本要求的产品。 5.产品经理的主要任务是定义有价值、可用的产品原型和用户故事。 6.让开发人员自主划分迭代周期。 7.产品经理和交互设计师必须出席每天的站会。 8.除非达到了产品经理的要求，否则不要轻易发布新版本，过度频繁更新版本会让用户感到不安。 9.在每次迭代完成后，产品经理应演示产品现状，以及下次迭代的产品原型，让大家看到工作成果，加深对产品的理解，增强团队对敏捷开发方法的信心。 10.在团队内展开敏捷培训。只有每位团队成员都真正理解敏捷方法，你才能把工作重心放在执行上，否则敏捷方法就只能停留在教条式的理论层面。 大公司都遵循一条潜规则——尽量规避风险，那么在大公司应如何顺利展开产品经理的工作： 1.了解公司制定策略的方式。 2.建立人脉网络。 3.臭鼬工程：工作之余做一些产品创意原型。 4.自己顶上：也不要凡事都指望各司其职的人帮你完成，有时实在没有人手就自己上。 5.有选择地据理力争：对事不对人，不要把对方逼到死角。除非这件事对你非常重要，值得你据理力争，撕破脸也在所不惜。 6.会前沟通，形成默契：在重要的决策会议上，如果有人公开反对你的提议，你会变得非常被动。 7.合理分配时间：不要被无尽的会议淹没；学会充分信任同事，让他们自己拿主意。 8.分享信息：许多人把它看成私有财产，藏起来不愿与人分享，其实有舍才有得。 9.向上司借力。 10.多向同事传播你的产品理念，描绘产品的愿景，介绍产品策略，演示产品原型，分享用户反馈信息。不要低估了内部宣传潜移默化的作用。让大家（包括没有直接业务联系的部门同事）不遗余力地支持你。

开发人员不擅长用户体验设计，因为开发人员脑子里想的是实现模型，而用户看重的是产品的概念模型。产品经理的目标是在最短时间内把握复杂的市场用户需求，确定产品的基本要求--价值，可用性，可行性。产品经理的主要职责分为两项：1）评估产品机会（product opportunity) 定义要开发的产品 2）探索产品解决方案，我主张采用简化的文档，围绕产品原型来展开这项工作。通常每五到十位开发人员配备一位产品经理。一位交互设计师大概可以支持两位产品经理的工作，一位视觉设计师可以支持四位交互设计师的工作。无论头衔或者组织形态怎么变化，我相信所有成功的产品背后都有一个全权负责定义产品的人。项目经理需要良好判断力，必须清楚何时催促进度，何时向上级汇报，何时需要收集更多信息，何时需要个别成员私下交流。判断力很难言传身教，只能靠自己积累经验获得我认为交互设计不能外包1：深入理解用户非常费时间，需要多个项目的经验积累。2：交互设计师必须现场深度参与项目开发，从立项到产品发布。开发和测试过程中会出现各种细节问题，必须有一名交互设计师迅速作出决定。3：产品的用户体验是公司的核心竞争力，必须在内部完成。如果公司内只有一名称职的交互设计师，视觉设计可以外包。开发人员帮助产品经理完善产品定义的方式有如下三种1：让开发人员直接面对用户或顾客，体会用户的困惑和疑虑，了解问题的严重性，这样好点子常常会随之而来，比如可以邀请一名开发人员参加产品原型测试。2：向开发人员了解最新技术动向，讨论哪些技术可以应用到产品中。3：让开发人员在探索产品的初期阶段参与评估产品设计，协助策划方案。产品经理常犯一类错误，即完成产品定义后，扔给开发团队，置之不理。这样做只会耽误协调需要与可行性的最佳时机，等到发现问题时，为时已晚。（全球化下）日益普遍的情形是软件架构师，测试经理，产品经理，设计人员留在公司总部、在产品管理上为开发团队预留20%自主时间，让他们自由支配。产品经理特质1）对产品的热情。热情是他们完善产品的动力，这份热情可以感染团队成员，激励所有人。辨别这种特质很容易，可以让应聘者谈谈自己最喜欢的产品及喜欢的原因，聊聊不同领域的产品和他讨厌的产品，问问对方，如果有机会，他打算怎样完善自己最喜欢的产品，热情是难以伪装的。2）用户立场。理想的产品经理不一定来自产品的目标市场，但是他必须融入目标市场。目标用户的经验喜好价值观知觉能力忍受程度技术理解可能与我们的大相径庭。对国际化或针对特定地域的产品，应该考察应聘者是否足够了解目标市场。3）智力。人的智力水平是无法替换的。4）职业操守。绝不适合贪图安逸的人担任。5）正直。不直接管理团队成员，需要通过行动影响，基于互相信任。6）信心 7）态度 8）技能9）运用技术的能力。出色的产品经理并不需要自己发明或者实现新技术，但必须有能力理解技术，发掘技术的应用潜力。10）注意力 11）时间管理 12）沟通技能。口头表达可以在面试中测试，测试书面表达能力则建议应聘者随身携带文字材料证明其书面表达能力。13）商业技能。我认为产品经理应该具备双语技能，这并非指中文和英文，而是指产品经理既能与程序员讨论技术，又能与管理层和营销人员讨论成本结构，边际效应，市场份额，产品定位和品牌行业经验重要嘛？以我自己为例，熟悉新行业达到自信制定产品策略的程度，只需要两三个月时间。年龄不是问题？今天二十五岁左右的人和我们的上网经验一样多。互联网兴起时，十几岁的青少年很快学会了成年人搞不懂的技术。其次，经验虽然需要时间积累，但其他素质，比如智力和对产品的热情则与年龄无关。怎样评估产品经理的工作？最近出现了一种考察业绩的新指标：用户净推荐值（net promoter score, NPS ) 见http://www.netpromoter.com 不应该把产品管理划分到开发部门。开发团队强调执行力，在强调执行力的组织里从事探索性工作是非常困难的。评估产品机会另一个棘手问题是如何评估市场规模。你可以求助于行业分析师，贸易协会，公司财务，再结合自己的分析作出判断。评估务必谨慎，避免浮夸，不是所有产品都有十亿美元的市场。要搞清楚产品的依赖因素和约束条件。钱花在哪儿，据我了解，多数产品经理（尤其是技术出身的产品经理）对产品（或公司）的盈利模式理解非常有限。（多跟财务人员沟通，私人友谊）产品探索所有的公司都会执行探索产品的流程，只不过有些公司不是利用产品原型完成这项工作，而是孤注一掷，用实际产品搭上全部开发时间进行产品探索。他们开发的是一款非常昂贵的原型，让不知情的用户掏钱参与原型测试。这些公司需要一两年时间（发布几个版本）才能盈利。产品原则仅仅罗列出产品原则还不够，还要按原则的重要性排序。建设性的辩论不可避免，学会忍受。产品评审团的构成首席执行官/首席运营官/部门总经理产品管理总监/副总监用户体验设计总监/ 副总监市场总监/ 副总监开发总监/ 副总监网站运营总监/ 副总监 客户服务总监/ 副总监产品评审还应该回顾，分析产品上市后的表现。可以在产品发布3-6个月后，请产品团队汇报产品的市场业绩表现，产品评审团所以反思之前的决策是否明智，今后应该如何调整。何时估算项目成本解决方案前粗略分，根据项目规模（建议分成小型，中型，大型三个等级），再根据项目粗略估算项目成本，虽然这种估算与实际情况会有出入，但通常不会出现跨级别误差解决方案明确后详细可靠的成本估算才有意义。如果有若干致命人物公开声明使用过产品，并且表示很满意，就可以大大降低潜在用户的顾虑。我建议征集特约用户协助完成产品研发。在项目开始阶段至少物色六位积极活跃乐于分享的目标拥护。要求是他们在产品的目标用户中具有一定影响力。至于他们是否使用过公司原有的产品并不重要，只要他们认为未来的产品可以解决他们手头待解决的问题特约用户的人数绝对不能超过十个，否则产品经理不可能有时间和精力与每位用户深入沟通。我们容易把产品尝鲜者（early adopter)误当成特约用户。产品尝鲜者常常能容忍产品的不足和缺陷。不普适。如果是互联网产品，增加到10-15人市场调研市场部门夸大了市场调研的作用，而产品部门只看到其局限性。第一，设计调查问卷需要技巧和经验第二，调查结果为获得解决方案提供了一条途径，但不是解决方案本身。哪怕所有用户都喜欢X特性，我们还是可以通过提供Y特性更实际的解决他们的需求。虽然市场调研很重要，但我从来没听说过仅仅通过市场调研就成功定义出来的产品。Google, eBay, iPod, iPhone, FaceBook, MySpace都不是仅仅通过调研产生的那些建议只能用来修补现有产品的不足之处，不能用来定义新产品。1）用户不知道什么样的想法是可行的，多数用户对现有技术一无所知2）用户不知道自己想要什么，没见到实际产品，用户很难凭空想象自己需要什么3）人群聚集时容易冲动，互相影响，难以获取每个用户的真实想法，取而代之的是那些善于表达者的一家之言。人物角色user profile 确定典型目标用户类型, 在理解各类目标用户的特征基础上建立的人物原型. 人物角色有助于对用户类型的优先级进行排序, 识别需要重点考虑用户体验的地方. 高保真产品远型>> 各种形式产品说明文档当然仅仅有原型不够, 业务逻辑, 发布要求, 平台交付要求. 用例可做补充.补充说明文档建议用Wiki需求调研和产品设计交替，开发与测试交替敏捷方法里有个概念叫sprint zero, 产品经理和用户体验设计师利用这段时间先完成产品设计工作, 然后交由开发人员迭代开发. 这需要更详细定义待开发任务backlog产品团队不再试图定义最终产品，转而定义只满足基本要求的产品，定下就不改。产品原型测试要避开过于亲密的人和科技行业从业者。除非就是目标用户。你只有一次机会了解测试者未接触产品原型之前如何解决产品要解决的问题。如点评类，只提供空白浏览器，看他们怎么做。原型设计多少有些假设内容，如果直接让测试者使用原型，就无法获取这些宝贵的内容。使用过原型后，测试者虽然可以告诉你希望怎样改进现有产品，但无法再像初次访问网站那样思考问题。测试前不宜于跟被测者交谈过多，事先谈的越多，透露的产品线索越多，测试者就越不可能说出他们对产品的第一印象。测试时千万不要让测试者陷入吹毛求疵的态度，重点看能否轻松完成测试任务，以及是否喜欢功能，如果提出页面元素难看，去掉或换掉，就跑题了。多观察用户的操作，少听他们的抱怨。更新原型敏捷化，只要两三个用户反映同个情况就动手解决吧。平滑部署通常情况下，用户不喜欢变化，虽然他们也希望产品更完善，功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习，适应新的使用方式。快速响应阶段产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段。评估产品使用明确量化指标，优先级：页面访问量？注册用户数？访问停留时间？会员转化率？订阅数？广告收益？利用谷歌分析工具等。敏捷方法 http://www.agilemanifesto.org 1: 产品经理即是产品负责人2：规划周期缩短，反复迭代，使用轻量级机会评估方法3：产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保你们有足够的时间攻克难题。让交互设计师和视觉设计师提前设计产品，不能一边设计一边开发。始终让开发人员参与，及时反馈关于可行性，成本，解决方案的建议。4：尽量把产品设计任务分拆独立部分5：定义原型+user story 取代冗长文档。6：让开发人员自主划分迭代周期7： 产品经理和交互设计师必须出席每天晨会。8： 达到产品经理要求前不轻易发布新版9：每次迭代完成后展示产品现状，下个迭代周期原型，看到工作成果，鼓舞士气10：团队内展开敏捷培训大公司如何创新建议大公司产品经理多和业内活跃的创业型公司建立联系，从以往经验来看，创业型公司在选择收购自己的东家时，并不只看重收购价格，他们往往会选择有过合作关系的公司。大公司都遵循一条潜规则--尽量规避风险。苹果启示：硬件为软件服务，软件为用户体验服务，用户体验为情感服务，产品为真正的需求服务。产品中情感的作用从业者多理工背景，但我们的工作却和研究人类情感的心理学有关。每次开展原型测试，除了观察的测试者能否顺利使用产品外，还应趁机了解测试者的情感需求，是什么驱动使用产品，怎样才能更好地满足他的情感需求。许多情况下，你的竞争对手不是创业型公司或大型门户网站，而是大众线下生活方式情感接纳曲线《跨越鸿沟》提出技术接纳曲线根据消费者特征分为，技术爱好者，非理性消费者，理性消费者，超理性消费者，观望者。非理性消费者最值得产品经理注意。技术爱好者最没参考价值。打造平台产品的经验产品管理中难度最大，也最能体现产品经理实力的定义成功的平台产品。所谓平台产品，是指一类基础软件，应用开发者能在其基础上开发应用程序。

信心：刚刚接触工作的大学生很多都很自信，虽然这种自信很多时候来自于对自身状况的无知，但是这并不影响他们投入极大的热情到工作中，将自己的或者正确或者错误的想法传达给大家。但是工作了一段时间以后，一部分人收到各种各样因素的影响，了解的多了，被PK的多了，很多时候开始不自信了，尤其面对想法和leader有了分歧的时候，不能很好的表达出自己的想法，据理力争，而是容易直接听从leader 的意见。当然这里据理力争最好能在争辩之前彻底的理清自己的想法的优缺点，从各个角度出发比较一下自己的想法和leader的想法，不打无准备的仗，不然很容易浪费时间。如果最终听从了leader 的意见，也要清楚的知道为什么这个意见更好，自己的思考有什么不足。思考，反思以及沟通使我们会使我们进步更快，而不是一味的接受。时间管理：很多时候你可能一大早来上班，拼命工作一整天，深夜回到家却发觉到头来没有完成一件重要的事情。这种情况在新人中并不少见，经常听到人说：“感觉今天一直在忙，但是不知道自己在忙什么”。可能新人负责的东西比较琐碎，有些时候区分不了重要性，导致自己一天忙的团团转。从这么久的工作中，觉得可以通过以下方式来帮助自己管理时间：1、 每天下班前想想自己今天做了什么，明天要做什么，什么时候做什么，最好能有记录2、 我们的任务大部分来自于leader以及所负责的模块的一些事情，在1的基础上，一些突发的事情可能会打乱我们的计划，这个和产品管理一样，在每天的时间安排上空出一定的时间处理突发时间，来自leader的任务，最好每一件任务都问清楚leader优先级（有没有时间节点等，一般leader会在安排任务的时候大概说一下，但是不排除有的时候忘记了，我们安排任务的时候却必须要知道。）至于其他的一些“突发事件”，很多需要自己对这些突发事件的重要性进行把握，哪些事情可以一块处理等，有的事情并没有重要到需要你放下手中的事情马上进行处理（当然，很多“突发事件”的负责人肯定是希望你能马上处理，有的甚至会因此不厌其烦的找你，这个时候需要有自己的判断力，不能马上处理的事情最好能给相关负责人反馈一个处理时间，让他们放心）3、 有的时候leader给你的任务只是口头说说，回过头可能他也忘记了，但是你不应该忘记。随时随地，如果有事情需要你做，尽快的将此任务加入你的待做事情当中。4、 有的事情，如果你需要其他人紧急处理，那么千万不要仅仅邮件沟通，最好能直接面对面沟通，将事情说清楚，并且说清楚为什么需要紧急处理（因为你可能已经打乱了别人的时间安排，所以需要有足够的理由去说服对方）。沟通完毕，再发一封邮件给对方，提醒对方，并且在邮件中将事情描述清楚，抄送事情相关人员（包括对方的leader和自己的leader，新人是很有必要的），如果不是很紧急，可以在发送邮件以后，告知对方查收一下邮件，了解整个事情，并且反馈给你一个处理时间（下班前想今天做了什么的时候，把这些都记录下来，有反馈处理时间的，标上时间，并且在时间要到之前确认对方是否可以及时交付，如果不可以，了解原因，并且及时反馈给相关人员。没有反馈时间的，请亲自去找对方确认一下）