【产品经理】谷歌与亚马逊如何做产品
【产品经理】谷歌与亚马逊如何做产品谈到沟通，大部分人首先想到的可能就是当面形式的一些沟通，比如1对1交谈、会议、汇报演示等，而实际上除了我们所熟知的这些沟通方式之外，还有很多其他形式的沟通也贯穿着我们工作的始终，比如邮件、PRD文档等等。既然沟通如此之重要，那么问题来了，作为一名产品经理，该如何掌握沟通这门卓越的技能呢？Chris Vander Mey在他的这本《谷歌与亚马逊如何做产品》中以会议作为切入口，阐述了他的一些观点。
会议，对任何一家公司而言都是一种极为常见的沟通方式，而对于一名产品经理来说更是家常便饭，需求评审会、需求优先级排序会、项目排期会、客户访谈会、公司例会、部门例会……大多数产品经理似乎每天都被各种无休止的会议所缠绕，然而，大部分的会议效率是如此之低下或者毫无意义，但大把的时间不得不耗费在里面。那么，面对这样的一种窘境，作为一名产品经理又该如何应对呢？对于这个问题，作者Chris提到了一个关键技巧：尽可能少开会，但不能不开会。会同笔者的一些实际经验，我将Chris的观点整理如下：
第一步，当不是必须要开会时，学会用邮件替代效率低下的会议
工作中有很多的事情，其实根本不必开会，一封好的邮件有时候可以替代好几场效率低下的会议。既然邮件如此重要，那么问题来了，产品经理要如何写好一封邮件？Chris在书中提到了以下五点：
像记者写新闻一样写邮件
优秀的记者，会将他们想表达的最重要的事情放在文章的开头。因此，对于邮件而言，拙劣的邮件会将理由和辩解放在前面，匆匆扫过的阅读者永远不知道你在为什么而道歉。
使用精确的增量表达法
将某个变量增加或减少xxx（差值），即从（开始值）增加或减少到xxx（结束值）。例如：我们不得不将发布日期延后2周，即从8月7日延后至8月21日。
分点阐释原因
优秀的发件人将他的逻辑依据从视觉上划分成多个点进行阐释，从而人们可以轻松地发现要点。另外，各点之间的行间距是很有意义的，适当的留白能帮助你清晰地分隔出邮件中重要或特殊的部分。
立即停笔，你已经写完了这封邮件
到这里你的邮件就写完了。或许你还想给你的逻辑一句再添加一点数据，或许你还想通过其他内容来证明你的逻辑多么真实，但是，真的不需要这么做，因为忙碌的高管可能会在他的手机上阅读这封简单的邮件，然后迅速转到下一封，他们根本没有那么多的时间去读你的长篇大论。
设法用建议替代质疑
建议更容易被人接受，因为建议能让他人挑挑刺，而质疑是直接冲着他人的，会加剧他人的抵触情绪。
考虑受众的感受
考虑他人的感受不是一件轻松的事，但很有必要。如果你作为管理层写邮件给你的下属，你必须将邮件写得善解人意。
第二步，当不得不开会时，你需要学会有效应对五种不同类型的会议
团队会议
频率：一周一次，每次30-60分钟，提前发布议事日程；
目的：促使团队坚守使命，并就当前一些悬而未决的问题达成共识；
切记：团队会议开比不开好，哪怕这个会议超级简短，因为它使得团队有机会以一种不同的方式聚集在一起，它还提供了喘息的时间。
站会
站会往往快捷、高效，因为每个人离开了他们的电脑，并没有那么舒服地站着，因此会议不得不尽快开完。每人汇报三件事：
昨天做了什么
今天要做什么
遇到的问题
1对1会谈
1对1的会议非常适合主管之间一起坦率的进行交流并公开问题，在会议过程中完成工作是1对1会议的精髓之一。请安排每周或两周与所有主管开一轮1对1的会议，即便及觉得没有必要。
产品评审会
评审会大多有大老板参加，而对于产品评审会，首要目标就是让老板们认可你的产品方向，让他们知道你的最新进展并提供给你反馈。会前先想清楚你要传递的确切信息，然后尽可能清晰、简洁地传递出去。由于这些与会者大都很忙，最好将你的会议控制在30分钟之内。
头脑风暴会
它的目标是收集尽可能多的想法，遵循4个基本规则，让会议带来更多创造性的效果：
不要在头脑风暴过程中批评他人的想法
说“是的，嗯……”
通过结构化来促进讨论
在头脑风暴结束时明确告知大家头脑风暴结束了
第三步，当需要你来组织时，学会如何组织好会议
允许改变开会的目的
开会有三大目的：解决问题、搜集信息、传递信息。一般会议都只为其中一到两个目的。开会的目的是可以改变的，千万要记住这一点！
拒绝在团队会议中发泄负面情绪
所有的危机都是最好的教育机会，比如当团队成员开始抱怨的时候就是一个机会。当某人在团队会议中散发出强烈的负面情绪并完全不顾及他人时，你需要眼里批评这种态度，但允许他在1对1的会议中发泄情绪。
使用鱼骨图等工具来解决问题
在团队会议中，当试图解决一个问题时，最有效的方法就是持续不断地问“五轮为什么”，直到找到根本原因，而鱼骨图就是最好的工具。
会后立即发出主题纪要
超过5个人参与的会议最好都在会后立即发出会议纪要，因为这样它的作用才能最大化，你的团队餐能感觉到他们是会议的参与者和下一步计划的执行者。不要过于担心纪要的准确性，因为人们会纠正你的错误的。
第四步，当需要演示时，学会如何做好一场演示
将演示时间控制在15分钟内
即便你幸运地被安排了1个小时或更长的时间，也一定记住对于一贯忙碌的高管来说，每个会议他们只有15分钟专注于你所讲的内容。30分钟内完成一次陈述一般遵循如下时间线：
第0-5分钟：等待，似乎每个会议都有5分钟左右的延迟
第5-15分钟：进行演示
第15-25分钟：讨论、答疑
第25-30分钟：重述结论和重要反馈，并就后续计划达成共识
永远传达且只传达一个信息
三大理由证明你为什么应该每次会议只传递一个信息
试图传递两个信息可能会导致彼此混淆；
在讨论过程中，你的脑海中会有两个想法左右互博，兼顾两个信息的传递会让你难以掌控会议；
你只有15分钟进行演示，你没有时间传递更多的信息。
讲故事
人们喜欢听故事，故事有代入感，能将你要传递的信息与真实的生活链接起来，配合故事演示，往往能取得更好的效果。讲故事可以帮你实现五大效果：
将创意与个人生活关联起来，从而是听众产生代入感。
让观众跟着你的节奏走。
提供了一个人们都能理解的具体的例子。
描述了你将要解决的问题。
描述了你的解决方案将如何提升用户的生活品质。
制作“综述单页”
综述单页包含了你所要演示的关键因素，通常是演示文稿的第一页幻灯片，它应该包含四大块内容：
你想讨论的东西是什么
机会在哪里
提供的解决方案
成本和实施时间表
重点演示用户体验
重点演示原型图，为了从外部用户的角度来描述你的原型，请首先说明首要用户目标而非描述特性，然后你可以指出用户体验是如何满足这个目标的。
极度专注倾听
如果到目前为止你都是按照流程走下来的，那么只剩下最后一个不可或缺的工作了——倾听。你需要注意分辨反对意见的细微差别，看看哪些是不可通融的，哪些又只是抱怨。
后记：
打从担任产品经理的第一天起，就感受到了产品经理这个职位所面临的巨大挑战，在实战中不断地历练自我的同时，要想更快地成长，还需要磨两把刀：第一把刀就是“学习”，第二把刀就是“思考”。得益于网上众多圈内人士的推荐，我很轻松地筛选并购买了一些经典的书籍进行学习，《谷歌与亚马逊如何做产品》就是其中一本，全书干货很多，我把我所学到的一些感触比较深的内容做此梳理，希望可以引发各位看官的一些思考。
猎豹移动CEO傅盛，360手机助手高级总监陶伟华，联合推荐。希望对你在产品的理解方面有所提升~
本文是《谷歌和亚马逊如何做产品》的学习笔记。
全书分为两个部分。第一个部分是关于在亚马逊和谷歌做得最好的团队，是如何交付软件的。作者按照项目开始到发布的顺序来安排章节，包括用户需求研究、用户体验设计、项目管理、测试、发布等。
第二个部分是关于团队成功交付所需要的技术积累，最佳实践和技能。
产品开发过程中的几个阶段
1、确定正确的产品方向
2、尽可能清晰详细地定义产品
这个过程需要10个步骤，包括撰写新闻稿，创建并不断更新FAQ文档，撰写功能需求文档等。这个步骤后，工程团队就会对项目形成统一的认识，管理层或投资者也会了解产品的基本形态。
3、设计用户体验
你需要从用户的角度出发，和设计团队不断沟通，反复迭代。你应不断提出问题，促使设计团队围绕着产品使命展开工作，并且保证工程团队和设计团队保持密切合作。
4、做一些基础的项目管理工作
不要太多也不要太少，当工程团队开始编码后，你需要跟踪交付物的进展，指出问题以及控制项目范围。
5、开始测试
随着各个功能的代码块陆续提交，产品的初期模型开始形成，测试团队的工作也开始了。作为团队主管，需要主导bug的处理并谨慎决定哪些可以容忍，哪些在版本１发布之前必须处理。
6、建立一套衡量产品成败的指标
7、正式发布产品
这个时候市场营销和公关文案要已经确定好。
使命感
使命感不应该成为一个口号，一个卓越的使命需要完全符合一下三个要求：
1、能够唤起人们的兴趣，团队成员辛苦加班的时候想起这个使命的时候应该让人振奋。
2、提供能够指明方向的原则，而不是永争第一这样的鸡汤。比如亚马逊一个负责个性推荐的口号"带给客户更多的惊喜"，对于特定团队来说这些标语都是很好的标语。
3、为了让团队更容易记住使命，可以印在T恤上。
创始人或者项目负责人对于产品本身价值观不能模糊不定，运营/渠道/融资烧钱确实很重要，产品本身的使命也不能忽视。
应该服务好自己的目标用户，然后凭借口碑来传播，而不是一味的过度营销。贝佐斯说过“以用户为导向，而不是以竞争为导向"，改动一下"以用户需求为导向，注重各个渠道的分发”。
产品定义
《精益创业》一书中充分论证了，为什么应该构建一个最小化可行产品。通过把它提供给一定量的用户使用，你可以验证之前关于客户问题的臆断是否正确。当迭代越小越快时，你甚至不需要花过多的精力去猜测用户的需求，而是更多按照用户告诉你的去做。
1、撰写新闻稿
亚马逊喜欢这个不同寻常的第一步。新闻稿是一篇脱胎于策略的文章，篇幅不超过一页。
2、创建并不断更新FAQ文档
主要用于记录一些争议点和重要细节。你可以花一个小时搭建框架，然后在开发过程中以及花一个小时搭建框架，然后在开发过程中以及上线后抽一些“业余”时间更新维护。
3、绘制线框图或流程图
线框图和流程图是产品的可视化描述，在讨论或答疑中使用可以让观点更清晰。绘制可能需要一天到一周不等的时间。
4、撰写产品单页或10分钟的演示文稿。
这是写给高管或投资人看的产品介绍文章，需要把控好介绍的详略程度。
5、API文档的制定。
6、撰写功能规范文档。
7、邀请设计团队和工程团队主管参与产品评审。
8、命名，定价以及预测收益。
9、向管理层汇报。
发布
发布不仅仅是将代码上传到服务器，这里有几个重要的发布步骤，遵循它们可以保证发布质量。
1、对改动说不
行业内有一句格言“发布手中有的，而非脑中所有的”，这也是扎克伯格在各个访谈中反复强调的。因为交付一个过得去的产品，比为了追求完美而什么也不交付要好。这个道理大部分人都认同，但执行起来却很难，因为产品做到什么程度才算过得去，并没有明确的衡量标准。
2、开启作战室，营造紧张气氛
在这个节点应改开每日例会，并且允许与会者在会上争论一些问题。因为这个时候效率是最重要的，有些问题最好马上解决就好。
3、核查发布清单
要想出色地完成发布，你需要拟定一张发布清单。这份清单的目的，在于确保软件发布中所有需要跟进的事项，都被安排有序且被详细描述，而且还能促进团队内部成员之间的交流。
4、再次审核各个平台的宣传文案以及进一步明确分发渠道
5、经历过内部员工和特定用户测试后发布软件
发布特性的方法是借助一套实验性框架，它允许两个版本的代码在服务器中运行。如果仔细观察谷歌和亚马逊等主流网站改版，你会注意到有些用户体验到的产品和其他人不一样，这是因为这些网站都使用了实验性框架来部署和测试特性。亚马逊称这样发布为Weblabs，可以通过新版本界面的操作数据以及反馈来改进产品。不要在周五或者临近假期发布。
6、应对发布带来的影响，对用户的各种反馈以及得到的数据进行分析以调整策略。
**** Hidden Message *****
谢谢分享！感谢无私分享！ 我路过..弱弱的冒个泡！弱弱的冒个泡！弱弱的冒个泡！ 我是来刷分的我是来刷分的 学习了，不错收益 匪浅 写的真的很不错 写的真的很不错写的真的很不错写的真的很不错 谢谢分享！我是个凑数的找到好贴不容易不知该说些什么 我是来刷分的 楼主辛苦了！写的真的很不错
页:
[1]
2