《人人都是产品经理》万字书评——偷师大神:采集产品经理的72个黄金工作细节 (作者苏杰大神点名才敢发.剧透.慎点.)

小Y专栏
2018-04-07 看过

申明:我这篇笔记,如果不是原作者苏杰大神点我名,这么多剧透,应该不敢发。

《人人都是产品经理》作者:苏杰

细节01:赛道赛车/slash/斜杠青年

苏杰,首先是一位优秀的产品经理,他选择了“赛道”(即:互联网行业),也选择了“赛车”(即:产品经理岗),以确保自己“一专”的突出优势,辛勤耕耘了3年以后,在产品经理岗位成绩斐然,这也是《人人》出版的那年。与此同时,当年的苏杰大神,就已经是个“斜杠青年”,善于写作、笔耕不辍,各种写作、分享、培训,也是成功的缘由。

苏杰(作者简介):

浙江大学硕士,2006至2014年供职于阿里巴巴集团,一直担任产品经理。做过的产品有中小企业的管理软件、淘宝卖家的工具、淘宝的垂直市场、天猫会员体系/营销工具、大型活动、企业内在线学习、知识管理系统、移动社区类产品等,负责过阿里产品大学、阿里内部的创新孵化器等。

著有《人人都是产品经理》、《淘宝十年产品事》,创建了网络翻译团队“@七印部落”,译有《启示录:打造用户喜爱的产品》、《四步创业法》、《有的放矢》等书,乔布斯《遗失的访谈》等视频。曾在浙江大学开设《产品经理入门》选修课,并提供产品经理相关的培训服务。

细节02:需求定性——给需求做一次DNA检测?

在作者用“DNA检测”类比“需求分析”的时候,我原本不太认同、颇觉费解。基因检测技术的应用非常有限,目前仅在“祖源检测、遗传检测”发挥作用,除了“亲子鉴定”恐怕其他对于疾病、健康、性格的预言可行度堪忧。基因检测虽然看起来使用了很微观、精密的技术,但操作方法、分析维度依然很单一。

而“需求分析”需要去深度思考的维度、深度,恐怕有更多的要求。好在苏杰后文提到的“定性、定量”分析,提供了值得借鉴的方法论,主要的工具则是“需求列表”,采用“所属模块、类型、需求来源、用户需求、产品需求、价值和备注”等字段,全方位地对需求进行初步定性。

细节03:定性分析、定量分析

定性分析:用户访谈(开放性、深入)→可用测试

定量分析:调查问卷(封闭性、速度)→数据分析

细节04:用户访谈-策略

1.避免照本提问

2.关注访谈目的(即:探索行为原因、行为模式,多问为什么?)

3.别让用户想解决方案(通常:短浅、片面)

4.别让用户谈技术方案(通常:纠缠、表面)

5.避免诱导性问题(会得到无意义答案)

6.多让用户:讲故事、说场景(更生动、更细致、便于后期分析)

细节05:调查问卷-策略

1.时间短、速度快。(作答时间≤10分钟)

2.先普通问题>再敏感问题>后个人信息(安全感?)

3.多出判断题>多出选择题>不出问答题(封闭性?)

4.样本偏差(注意比例、人群、行为模式)

5.统计偏差(注意数量、方法、顺序偏差)

6.如何设计一份合适的问卷。(苏杰给出了例子,第51-52页)

细节06:如何做“可用性测试”?

1.流程:

(1)招募合适的用户

(2)用户使用产品完成指定任务/组织者旁观和记录

(3)测试结束后发表看法和感受/组织者记录和询问

(4)列出:可用性问题

(5)确定:问题优先级

(注:特别像测试流程的简化版,面向用户、更为随意。)

2.对策:

(1)建议提早做,切勿做太晚。(否则:发现问题,于事无补)

(2)建议简化做,但不能不做。(否则:闭门造车,自嗨自乐)

(3)测试的对象,是产品功能,非用户能力。

(4)注意优化测试的流程:

①轻松氛围;

②预告时间;

③不引导、不诱导;

④不打扰、不批评;

⑤赠送礼物;

⑥保持关系

细节07:产品改版是双刃剑!

一方面,改版的目的是升级产品、优化服务,从而获得客户、市场的高度认可。另一方面改版在客观上会挑战用户现有的习惯,所以需谨慎,要掐准时机、做对方向。

——案例:07年豆瓣改版、09年百度贴吧改版,都因为反对声音太大而道歉、改回。

细节08:怎么说≠怎么做

(用户的行为,很多时候应靠观察、而非询问。)

细节09:关于作弊成本?关于制度成本?

苏杰提到了如何增加作弊的成本,这种成本包含操作成本、机会成本、风险、记录等,会大大减少作弊行为的发生。与此同时,也不得不提另一个词,叫“制度成本”。

这也是很多管理者经常忽视的基本规律,总以为“大方向对,就可以做”,往往最终走向歧途、限于纠缠,没准“迂回走”效果更好。世界上最短的路,很可能不是直线。

细节10:用户需求≠产品需求

用户需求,未必适合转化为产品需求,我们需要发掘用户真正在遭遇的痛点、真正要解决的问题。

细节11:需求分析-流程

1.需求的记录和转化

(产品需求列表 字段:模块/子模块/功能/功能描述/商业价值/行业属性/优先级/开发量/性价比/其他备注)

2.确认需求的属性

(需求属性描述 字段:独立编号/提交人/时间/模块/名称/描述/提出者/提出时间/属于bug则另行管理)

3.确定需求的分类

(分类:新增 改进 提升 修复 内部/层次:基础 扩展-期望需求 增值-兴奋需求/非功能:环境性能 培训 维护 扩展)

4.分析需求的商业价值

(需求的卖点是什么?为用户提供什么价值?对公司提供什么帮助?通常是需求列表中最核心的部分。)

5.初评需求的实现难度

(因素:人力成本-工作量 开发成本-开发量时间要求 产品设计难度 开发技术难度 运维要求 推广要求 培训成本)

6.最后:性价比

性价比 = 商业价值÷实现难度(简化为开发量)

细节12:“雪中送炭”与“锦上添花”

关于需求分类,参见“KANO模型”的需求满意度曲线。

细节13:BRD如何写?

项目背景:我们在哪?为什么要做?要解决什么问题?

(附:摆事实、列数据)

商业价值:我们去哪?有什么价值?要实现什么目标?

(大老板最关注,可以预测数据变化、商业前景。)

功能需求描述:我们怎么去?

(通过做哪些事情来达到目标,把打好包的需求描述一下,可以用功能列表的形式表达,但最好能画出业务逻辑关系。)

非功能性需求:提一下重要的非功能需求,如果有的话。

资源评估、计划:要多少成本?

(老板要看成本,综合比较,才能做出决策。)

风险评估、对策:有什么风险?

(老板看待风险,视角更大,可以帮你把关。)

——PRD、MRD怎么写,其实作者也有讲到。

细节14:见山是山,见山不是山,见山还是山

文中“见山是山,见山不是山,见山还是山”的过程,对我来说还是很有感触的。我最开始做产品经理的时候,也经理了这样需求分析、评审、确认的过程,最后设计出的原型很多小伙伴觉得很普通,本来就是这样,应该就是这样,但事实上背后经历的讨论过程实际上是非常有意思、有意义的,它是一个很重要是思考、迭代过程,尤其是最后看似简单、实则精妙。

细节15:如何检查、筛选空盒子?(案例)

专家动用算法,老粗搬来电扇。——这个案例的真实性恐怕无法考证,但这个案例给人带来的震撼却挥之不去。少做就是多做,少做不如巧做,在这个案例上如此贴切。

细节16:心中有“树”

WBS:Work Breakdown Structure 工作分解结构

有句谚语:Any task can be achieved,as long as it's broken down into manageable pieces.(译:任何可以被分解任务都有实现的可能。)

细节17:工期的“三点估算法”

工作量=(最乐观+最悲观+最可能)/ 3

细节18:产品开发沟通(项目内)

1.项目晨会(开发经理召集,参与人为PD、UE、开发、测试等)

2.项目日报(发给团队全员)

3.评审会(分为需求评审、设计评审、TC评审、功能评审等)

4.项目变更申请

5.发布项目公告

细节19:时间点(时间) 里程碑(事件)

如何设置时间点、里程碑,才能让地图、路线更鲜活。(产品路标规划)

关于“速度”、“速率”和“里程碑”?

1.速度是一个矢量,要确定正确的方向。

2.速率是一种效率,要把握合适的节奏。

3.里程碑,是关键节点。里程碑之间,集中精力加速。

细节20:项目TRQ

苏杰提出的“项目TRQ”让人印象深刻,我也非常认同。

1.项目时间(Time)

2.项目资源(Resource)

3.项目质量(Quality)

包括苏杰把Q解释为"Quality + Quantity"(品质+数量)的做法,我也非常有触动。这与我之前在自己工作中总结的“时间点、负责人、任务量(数量、质量)”几乎完全一致。

细节21:三边六拍

1.边计划、边行动、边修改

2.拍脑门、拍肩膀、拍胸脯、拍桌子、拍屁股、拍大腿

(三边不可怕,怕的是反复无常。六拍不可怕,怕不吸取教训。)

细节22: UC文档的语言要求

无歧义、完整、一致、可测试

细节23:Agile 敏捷开发

(案例:老板项目)

T是给死的——但可以试着商量

Q是可变的——先放大再等被砍

R是丰富的——尽量多要留空间

封闭开发?

细节24:关于“项目外包”和“开发外包”的教训

1.确定合作模式、合作协议,明确权责利。

(权责利还需要对等。享受事成的好处,担负失败的损失。)

2.约定较为一致的工作方法、工作流程。

3.如果是项目外包,适合乙方驱动、乙方担负项目管理职责。

4.如果是开发外包,适合甲方驱动、甲方担负项目管理职责。

细节25:大团队(产品、技术、商业的“铁三角”)

1.产品团队

(1)心思缜密的规划师

(2)激情四射的设计师

(3)阴险狡诈的运营师

2.技术团队

(1)开发团队(架构、编码)

(2)测试团队(功能、性能)

(3)运维团队(数据库、服务器)

3.商业团队

(1)市场(针对市场、推品牌)

(2)营销(针对客户、做订单)

(3)服务(售前后支持)

——不要忘记支撑团队:财务、行政、法务、人力……

细节26:先僵化、后优化、再固化

——华为的任正非引进新管理体系时的策略

一个方面:商业行为准则,就是公司用正式的书面形式,告诉员工什么可以做、什么不可以做,如果非做会受到什么样的处罚等,公司通过这套准则让员工明白,这里的企业文化认为,什么是道德的什么是不道德的。

另一方面:制度的破坏者,也往往会带来创新。

细节27:卡洛曼壶(枉顾用户需求)

由法国艺术家卡洛曼(Carelman)设计,因此称之为“卡洛曼茶壶”。由于壶嘴和壶柄在同一侧,而几乎无法使用。但它却是一件被许多人珍视的收藏品。

但从用户需求看,属于经典反例。

细节28:关于“项目”和“流程”的体会

1.偶尔为之的事情,需要:可行解

2.经常为之的事情,需要:最优解

(这个总结超棒!)

细节29:接口人的设置

1.价值

(1)汇总问题,避免遗漏。

(2)过滤问题,避免重复。

(3)固定对象,熟悉程度高、沟通成本低。

2.要求

(1)资深人士

(2)沟通能力强

(3)认真细致

(4)及时高效

细节30:职能架构、项目架构

——矩阵架构?

细节31:产品概念图

(形式不重要、内容是重点)

1.产品外联关系——把产品看做一个系统,描述它与上下级系统、并列系统、用户、市场的关系,必要时勾勒出产业链结构。

2.产品内部关系——描绘产品内部的模块数量、模块之间的关系,以及不同角色在系统中的身份。不必涉及数据、信息架构。

细节32:文件、软件版本控制

公司内部频繁出现版本混乱,建议;version的标记数字升级为两位。即:从“V1”改为“V1.0”,如果版本的修改幅度不大、没有明显变化,可保持“V1.0→V1.1→V1.2→V1.3”的层级升级。

细节33:PPT 骗骗我?

曾被卫哲批评为“骗骗我”,在PPT制作的风潮还没有过去的时候,就已经有人酸酸地吐槽“工作不饱和的人”才做得出漂亮的PPT。这个问题,有空想想?

细节34:美第奇效应

在思想、观念和文化的交汇点上爆发出灵感。从这个定义出发,我们可以大致了解作者创作这本书的动机:当思想立足于不同领域、不同学科、不同文化的交叉点上,你可以将现有的各种概念联系在一起,组成大量不同凡响的新想法。“美第奇效应”,源于15世纪意大利美第奇家族及其在文艺复兴时期突发的创造活动。

细节35:如何跟工程师合作?

1.流程

超级理性的人更明白“没有规矩,不成方圆”的道理,工程师喜欢被规则管理,而非被人。需求的本性就是“总在变化”,因此需要流程化的规定来控制这件“恐怖”的事情。

2.沟通

避免情绪化,人性的弱点决定了争论的主体都想维护自己、说服对方,因此常常有人根据喜恶、立场做判断,这样很可怕。因此,正确的、有效的沟通方式很重要,要良性互动。

3.翻译

实际上工程师熟悉的语境语言,与老板、客户、运营、客服、市场、销售都不太一样,因此直接与他们沟通是有困难的,这就需要产品经理完成翻译,这就需要PD要熟悉开发、了解技术。

案例:基于事实沟通,说“你迟到一小时”,不说“你没有时间观念”。

细节36:领导是做人的艺术,管理是做事的技术。

艺术的关键,不在威、不在术,而在道。说白了,要让大家统一认识。你老板要让员工清楚地明白你的价值观,含:你喜欢什么?你讨厌什么?你支持什么?你反对什么?你最在乎的是什么?你的底线在哪里?让员工不用问你,就能够用你的标准去决策、执行和反馈。

如何落地?——就是让团队建立一致性,一支部队像一个人,反复强调、多次重申。

如何落实?——就是表扬、奖励你想推行的,批评、惩罚你想杜绝的。

管理的关键,不在三令五申、不在威逼利诱,而在技术手段。说白了,公司要设计一些流程、模板、话术,提供一些培训、技术、工具,来帮助员工完成手头的工作,并且达到公司想要的标准,不指望员工优秀、只确保员工合格。

如何落地?——从告诉大家合格标准开始,例如:面对客户的十不准、客户服务三原则。

如何落实?——要有各种技术、各种工具,提醒、提示、帮助大家完成。

(这段我自己写的,与苏杰大神一致。)

细节37:无授权领导

产品经理是否应该拥有管理权?

支持:管理权限利于拥有话语权/管理岗位利于获取信息/管理岗位利于争取资源

反对:管理岗位有很多行政工作/管理岗位容易脱离群众/管理岗位滋生领地心态

更好的思路:

设计管理、专业两条职业通道,让优秀的产品经理在“专业线”上拥有高级别,在“管理线”上拥有知情权,可以赋予临时的资源支配权,可以参与管理会议的讨论、决策,但不负责管理者的行政工作,继续与自己的团队小伙伴待在一起。

细节38:触及产品的灵魂

应该是第一次听到“触及产品的灵魂”这个表达,我向来是信文字的力量的,这个必到、确实贴切。在苏杰的分析当中,产品经理会经理三个境界:产品帮助我们→产品与我们互相帮助→我们帮助产品。

试问:作为2岁的产品经理,我在哪个境界?

细节39:阿里对员工的考核方法

坚持业绩50%、价值观50%

细节40:帕累托改进

帕累托最优是指在不减少一方福利的情况下,就不可能增加另外一方的福利;而帕累托改进是指在不减少一方的福利时,通过改变现有的资源配置而提高另一方的福利。帕累托改进可以在资源闲置或市场失效的情况下实现。在资源闲置的情况下,一些人可以生产更多并从中受益,但又不会损害另外一些人的利益。在市场失效的情况下,一项正确的措施可以消减福利损失而使整个社会受益。

细节41:推荐分析方法:$APPEALS分析

$APPEALS是一种了解客户需求的、确定产品市场定位的工具。一般是使用在市场规划和产品规划的细分市场中,因为可以从多个维度,不同的权重来分析需求,所有$APPEALS一定会联系到细分市场,联系到竞争对手,涉及到差异化分析和蓝海的价值创新(减少,增加,剔除,创新)。差异化可以说是理解市场和分析市场中的一个重要内容,只有清楚了差异化才能够树立自己产品的核心竞争力。

$APPEALS方法是IBM在IPD总结和分析出来的客户需求分析的一种方法。它从8个方面对产品进行客户需求定义和产品定位。具体如下:

$-产品价格(Price);

A-可获得性(Availability);

P-包装(Packaging);

P-性能(Performance);

E-易用性(Easy to use);

A-保证程度(Assurances);

L-生命周期成本(Life cycle of cost);

S-社会接受程度(Social acceptance)。

细节42.:Persona文档?

用户画像。(参见笔者简书文章)

细节43:苏杰写博客

1.写作(内部工作)——参照开发计划

2.发文(外部工作)——参照发布计划

细节44:苏杰谈开会

1.明确目的

发会议邀请,预告会议提纲(提要会议的内容、流程、要求)

2.会前准备

资源确定事小:会议室、投影仪、白板、纸笔、网络、音控

人员确定事大:必选、可选。既不漏要人,也不请闲人。

(原则:大会决定小事,小会决定大事,全员会议干不了事!)

3.提前通知

4.会中:提前准备,明确主持人、记录人,民主集中。

5.会后:提供纪要,明确决议、任务、遗留问题,邮件群发。

(参考《罗伯特议事规则》的实用民主集中制:所有人提供意见,少数人讨论,一个人拍板。)

细节45:达摩克里斯之剑

达摩克利斯是公元前4世纪意大利叙拉古的僭主狄奥尼修斯二世的朝臣,他非常喜欢奉承狄奥尼修斯。他奉承道:作为一个拥有权力和威信的伟人,狄奥尼修斯实在很幸运。狄奥尼修斯提议与他交换一天的身份,那他就可以尝试到首领的命运。在晚上举行的宴会里,达摩克利斯非常享受成为国王的感觉。当晚餐快结束的时候,他抬头才注意到王位上方仅用一根马鬃悬挂着的利剑。他立即失去了对美食和美女的兴趣,并请求僭主放过他,他再也不想得到这样的幸运。

达摩克利斯之剑通常被用于象征这则传说,代表拥有强大的力量非常不安全,很容易被夺走,或者简单来说,就是感到末日的降临。

细节46:电子菜单设想、群发短信求婚

电子菜单的想法,2010年苏杰戏谑地提出,2018年已被二维火实现。而苏杰说过的“一呼百应、短信求婚”的案例,就是我本人当年的求婚流程之一。很感慨,这或许就是冥冥中走上产品经理这条“不归路”的缘分了。

细节47:团队中应该有哪些人?

1.经验(√)熟悉产品(×)。——此类不靠谱

2.经验(×)熟悉产品(√)。——此类不靠谱

3.经验足,且熟悉产品。——此类不存在,只能自己上。

细节48:关于探索世界

苏杰所描述的“点亮一盏盏知识的小灯”是个非常贴切的比喻,世界如他所说对每个人来说都是未知、黑暗的,在最开始的时候人们肯定无法看到全貌,点灯、学习,才会不断修正对这个世界的认识。而修正的结果,则必然发现世界越来越复杂,而进一步的探索,尤其是“关键的灯”被点亮以后,真正智慧的人一定会发现世界原本是一个互相关联的整体,从而看到整体、看到系统,也探知更多的底层逻辑,也就成为那个最强悍的人。最后,我们才能明确自己在哪里,想要去哪里,以及如何在知识地图上选择合适线路。

细节49:沟通

1.个体沟通

(1)四象限法(重要/紧急)

(2)辅助使用(主要/辅助)

2.群体沟通

(1)群组

(2)邮件

(3)公文

(4)会议

(含:电话会议/视频会议)

细节50:Don't make me think 原则

用户不喜欢思考,越简单,越幸福。

细节51:听用户的但不要照着做

用户跟福特要一匹更快的马,福特却给了用户一辆车。

细节52:分析师价值

伟大的需求分析师,可以无视用户想要的东西,去探究他内心真正的渴望,再给出更好的解决方案,或者说是用户真正需要的东西,这就是本节标题的意思——我们存在的价值。

细节53:精力分配

情愿把一半的功能做的尽善尽美而不是把全部的功能做成半吊子。

细节54:多快好省

做项目的目标无非是多快好省:范围大、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的,有理智的老板们也都明白这一点,所以我们通常是在上述4个要求中做平衡。

上面所说的目标对比经典的项目TRQ:项目时间(Time)、项目资源(Resource)、项目质量(Quality),几乎一样。一点小区别就是Q(质量),我觉得把Q解释为“Quality+Quantity”(品质+数量)更准确,而我所经历的项目,Q更多的是表达Quantity(除非有特殊情况,“品质高”这点是不会舍弃的,所以可变的是项项目范围)。

综合一下,我们做项目的本质就是在保证品质的前提下,在时间要求、人财物花费、项目范围三点上做平衡?

细节55:个人核心竞争力、团队核心竞争力

当年的“英雄”把自己的个人经验转变为显性知识表达出来,而对于经常做的事情,就可以用流程这种形式固化,后人在做这些事情的时候起码不会太无助。在这点上,规范、模板的作用也类似,这就是团队的核心竞争力。

个人的核心竞争力,就是把显性知识转化为隐性知识的能力。

团队的核心竞争力,就是把隐性知识转化为显性知识的能力。

细节56:需求的本性

需求唯一不变的,就是“不断变化” ^_^

女人唯一不变的,就是“不断变化” ^_^

细节57:销售与渠道

苏杰在文中提到,到了2008年“e网打进”销售火爆,出于工作需要,我浏览了一些渠道相关的书籍,说说相关的体会:

1.先来点基础知识,销售有两大模式:直销VS分销。

(1)分销要通过渠道,渠道又分代理和经销。他们的区别是“代理”赚佣金,没有产品所有权和库存风险;“经销”赚差价,产品所有权发生转移,比如批发商。

(2)现在网络上的付费产品,生产商和消费者之间有了互联网的连接,更容易直接接触,加之网络支付等服务的成熟,所以网络个人应用,大多数都采取了直销。

而我们的“e网打进”是面向企业用户的,而国内中小企业现在相应的知识和意识还略显落后,所以我们选择了渠道销售。

2.在渠道战术的推拉方面,介绍如下:

(1)所谓“推”是集中力量做渠道工作,用髙额利润去刺激渠道主动推销产品,快速抢占市场;

(2)而“拉”是通过PR、广告、传播等手段启动市场,刺激消费者,促使渠道来找厂商。

推适合企业规模小、技术含进高、销售过程复杂的产品,一般来说:新产品推,老产品拉。“e网打进”用的显然是推的方法,其驱动路线是“厂商→渠道→终端用户”。

——对销售和渠道的话题,我作为外行不再多言,冋到产品设计的角度说几句。

第一,通过渠道销售的产品,新增功能和改动功能的时候,还需要额外考虑公司内渠道管理人员的培训成本、渠道商的培训成本,要他们把一个功能说明白很不容易。

第二,既然选择通过渠道来销售,就说明终端用户对互联网的应用能力不足,所以相应的设计思路也要转变。

第三,在渠道终端的用户一般是企业,企业用户与个人用户的差异也不得不考虑。比如支付,企业用户就会有开发票的问题,不能只简单地考虑网上支付途径。

第四,由于渠道的介人,多级的定价,分成比例,开发票的流程,渠道政策都要有相应的系统支撑。

细节58:市场切入

比如针对个人用户,可以根据地域、年龄层次、收入水平等因素来划分,根据企业用户,可以根据员工人数、年收入、所属行业等因素来划分,然后找到我们有机会切入的小市场。任何产业发展了这么多年,必然形成了很多细分的小市场,如果一开始就想一口全部吞下,是注定要被噎死的。

这个观点,和《从0到1·揭开商业和未来的秘密》是一致的。

细节59:高层定向、中层分解、基层执行

如题,每个层级都有自己的工作重点,不求互相体谅,但求一以贯之。

细节60:远视者把目的当手段,近视者把手段当目的。

KPI的量化原本只是实现目的的手段,是未来简化执行、简化管理、简化考核。但总被一些“糊涂蛋”无意曲解,被一些“聪明人”有意利用。甚至被一些管理者看做目的和获得无知利益的抽买,片面追求数字,甚至不惜做违背企业大战略的事情。

细节61:长期目标与短期目标的均衡。

人生很长,不要以百米冲刺的方式跑马拉松。

但任何时候,请记得:立即响应,快速执行,及时反馈。

(上述12字方针与速度无关,与态度有关,但最终将决定速度和效率。)

细节62:产品经理的缺乏

这个社会挺缺产品经理和设计师的,说到底,是缺少热爱升华的人,这是我们的机会,也是我们的时代。而产品经理的缺乏,本质上是因为大多数人避免作“有深度的思考、有价值的挑战”。

细节63:热爱生活

热爱生活的人时刻充满激情、能力和创意。

细节64:“想做、要做、能做”

理想是“想做的事”,现实是“要做的事”和“能做的事”,理想和现实总是有差距的,这也是我们一生最大的问题。只有理想没有现实是空想,只有现实没有理想是傻做,所以,我们其实一直在把理想和现实从两边往中间凑,努力改变环境、锻炼自己能做“想做的事”,也努力说服自己想做“要做的事”和“能做的事。

热爱生活,可以帮助你把“要做的事”变成“想做的事”。学会思考,不断提升自已能力,可以把“要做的事”变成“能做的事”。寻找理想,就是把“要做的事”、“能做的事”都整合成“想做的事”。我们不断努力扩大“想做、要做、能做”三者的重合部分,这就是你的理想,也是你的核心竞争力,别人学不来的。

细节65:什么是“教育”?

“教育”一词在现代英语中是“education”,源于拉丁文“ educare”。“education”是个名词,它是从动词“educere”转换来的。而“educere”是由前缀“e”与词根“ducare”合成的。前缀“e”有“出”的意思,词根“ducare”则为“引导”,二者合起来就是“引出”,意思就是采用一定的手段;把某种本来就潜藏于人身上的东西引导出来,从一种潜质转变为现实。

所以说,“教”是为了“不教”,是为了激发其自我反思、自管理的能力,当开启一个人的心智之后,他就可以自我发展,成为一个独立的人。

细节66:性价比

工作中要做的事情往往是追求“性价比”而不是完美。

细节67:沟通的目的

沟通不是为了说服,沟通是为了更好的认识世界。有效的沟通最终是“合”,而不是谁战胜谁,每次沟通都是一个大家互相帮助,共同提高对世界的认识的好机会。

细节68:什么才是产品经理?

参考Josh Elman在自己的文章《Let’s talk about Product Management》中提到过一句话:help your team ship the right product to their users(即:帮助团队,面向用户,发布正确产品!)

(1)什么是“帮助团队”?

解释一下,产品经理确实不是一个人在战斗,在“产品团队”中有一堆人,这些人代表了公司利益(总裁、股东)、设计团队、技术团队、运营团队(其实广义上海应该包含客户)。“帮助团队”就是要在“体验、技术、商业”中作整合,对接团队、帮助团队、成就团队!

(2)什么是“面向用户”?

我刚入职的时候,就一直在推广一个概念,叫“使用者友好”,其实这本就是“交互设计概念”,比如:

UED(用户体验设计)

User Experience Design

UCD(用户中心设计)

User Centered Design

无论是关注用户体验,还是以用户为中心,其实都是在说一个意思:跟自己死磕,让用户暴爽!然而,更重要的,不仅仅是用户体验,而应该是用户价值!

(3)什么是“正确产品”?

1.满足需求

2.解决问题

3.好用

4.好看

5.群众说好

6.公司受益

(最关键:简单!)

而苏杰说:

虽然不是每个人都能以产品经理为职业,但在我看来,产品经理是一类人,而不是一个固定的头衔。任何人,只要能够发现问题并描述清楚,转化为一个需求,进而转化为一个任务,争取到支持,发动起一批人,将这个任务完成,并持续不断以主人翁的心态去维护,跟踪这个产物,那么,这个人就是产品经理。

细节69:如何看待用户批评?(案例:春晚)

每当有人骂春晚的时候,产品经理的思路应该像对待一个提需求的用户: 骂的人是不是典型用户?他的观点能代表多少人?他的影响力多大? 他是不是只是 “嗓门大"的用户? 他说的是不是解决方案?他的本质需求是什么? 把他的需求加人需求列表应该标什么级别?什么属性?想完了就会发现,事情并不是很糟,于是嫣然一笑发现定位没有问题,继续这么干。另一方面,看了又骂的人,首先不要急,春晚不可能突变,而且,一个本来就不是为你做的产品,你掺和个什么劲啊?

细节70:什么是成熟?

一个人真正成熟的标志之一,就是心中可以容纳互相矛盾的观点而无碍行事。正所谓:我绝不同意你的观点,但我将用生命捍卫你发言的权利!

每个人都在成长,但不是每个人都能收获成熟。

每个人都在进步,但不是每个人最终能变成熟。

细节71:什么是复杂?什么是简单?

当没有得到正确答案时,很可能是问错了问题。复杂是世界的一部分,但是它不该让人困惑。好的设计可以帮助你驯服复杂,不只是让事物变的简单,而是去管理复杂。

细节72:产品经理的标准(个人总结)

对市场、客户敏锐的洞察,快速确认需求;对产品周期、开发进程的准确预估;多角色、多场景进行广泛、细致、深入的产品调研;有水准的原型设计、需求说明;严格、有序的评审;项目流程和开发进度的科学管理;有序、高效的测试;按时验收、及时上线;有帮助的产品说明、有影响的产品推广、有效果的产品营销;用户反馈的及时收集、答复;有针对性、有策略性且持续不断的产品迭代。


写在最后:

感谢大神苏杰,让我有机会拜读《人人都是产品经理》这样的好书,从而整理、汇总了自己的心得和体会,希望这篇文章,与众有所裨益。

转型产品经理,是“从台前到幕后,从喧嚣到寂寞”,更是“从现象到本质、从执行到思考”,如果我一直干市场经理,恐怕一辈子也走不出自己的舒适区,我鼓励每个小伙伴都应该:和“路径依赖”说再见,去迎接:真正有深度的思考,真正有价值的挑战!

3 有用
1 没用

查看更多豆瓣高分好书

评论 3条

添加回应

人人都是产品经理的更多书评

推荐人人都是产品经理的豆列

了解更多图书信息

豆瓣
免费下载 iOS / Android 版客户端