【产品经理】谷歌与亚马逊如何做产品 讲座课程简介:
谈到沟通,大部分人首先想到的可能就是当面形式的一些沟通,比如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的处理并谨慎决定哪些可以容忍,哪些在版本1发布之前必须处理。
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、应对发布带来的影响,对用户的各种反馈以及得到的数据进行分析以调整策略。
课程目录:
01产品设计在硅谷——Amazon.mp4
02产品设计在硅谷——Google.mp4
03彩蛋:产品经理在硅谷.mp4
课程下载地址隐藏,下载需要支付