申明：这篇笔记，如果不是原作者苏杰大神点名，这么多剧透，应该不敢发。
细节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（用户体验设计）
UserExperience Design
UCD（用户中心设计）
UserCentered Design
无论是关注用户体验，还是以用户为中心，其实都是在说一个意思：跟自己死磕，让用户暴爽！然而，更重要的，不仅仅是用户体验，而应该是用户价值！
（3）什么是“正确产品”？
1.满足需求
2.解决问题
3.好用
4.好看
5.群众说好
6.公司受益
（最关键：简单！）
而苏杰说：
虽然不是每个人都能以产品经理为职业，但在我看来，产品经理是一类人，而不是一个固定的头衔。任何人,只要能够发现问题并描述清楚,转化为一个需求,进而转化为一个任务,争取到支持,发动起一批人,将这个任务完成,并持续不断以主人翁的心态去维护,跟踪这个产物,那么,这个人就是产品经理。
细节69：如何看待用户批评？（案例：春晚）
每当有人骂春晚的时候,产品经理的思路应该像对待一个提需求的用户: 骂的人是不是典型用户？他的观点能代表多少人？他的影响力多大？他是不是只是 “嗓门大"的用户？ 他说的是不是解决方案？他的本质需求是什么? 把他的需求加人需求列表应该标什么级别？什么属性？想完了就会发现,事情并不是很糟,于是嫣然一笑发现定位没有问题,继续这么干。另一方面,看了又骂的人,首先不要急,春晚不可能突变,而且,一个本来就不是为你做的产品,你掺和个什么劲啊？
细节70：什么是成熟？
一个人真正成熟的标志之一，就是心中可以容纳互相矛盾的观点而无碍行事。正所谓：我绝不同意你的观点，但我将用生命捍卫你发言的权利！
每个人都在成长，但不是每个人都能收获成熟。
每个人都在进步，但不是每个人最终能变成熟。
细节71：什么是复杂？什么是简单？
当没有得到正确答案时，很可能是问错了问题。复杂是世界的一部分，但是它不该让人困惑。好的设计可以帮助你驯服复杂，不只是让事物变的简单，而是去管理复杂。
细节72：产品经理的标准（个人总结）
对市场、客户敏锐的洞察，快速确认需求；对产品周期、开发进程的准确预估；多角色、多场景进行广泛、细致、深入的产品调研；有水准的原型设计、需求说明；严格、有序的评审；项目流程和开发进度的科学管理；有序、高效的测试；按时验收、及时上线；有帮助的产品说明、有影响的产品推广、有效果的产品营销；用户反馈的及时收集、答复；有针对性、有策略性且持续不断的产品迭代。
写在最后：
感谢大神苏杰，让我有机会拜读《人人都是产品经理》这样的好书，从而整理、汇总了自己的心得和体会，希望这篇文章，与众有所裨益。
转型产品经理，是“从台前到幕后，从喧嚣到寂寞”，更是“从现象到本质、从执行到思考”，如果我一直干市场经理，恐怕一辈子也走不出自己的舒适区，我鼓励每个小伙伴都应该：和“路径依赖”说再见，去迎接：真正有深度的思考，真正有价值的挑战！