◆ 内容简介
>> 第一部分主要讲述从粗略的点子到具体的方案，要经历的步骤。第二部分主要讲述如何落实方案，以及如何进行用户研究、需求分析和产品设计。第三部分主要讲述在落实方案的过程中要掌握的方法和管理技巧。最后一部分主要讲述产品经理在工作和成长过程中要考虑的一些问题。
◆ 自序
>> 只靠一个点子就能飞黄腾达、立业成功的想法是不切实际的，希望能让大家警醒。
◆ 第1章 点子与方案
产品经理对行业，市场，用户要高度的敏感。
>> 在产品尚未成型、什么都没有时，作为产品经理要有建立在对市场和用户的理解上的雏形方案。
>> 在产品尚未成型、什么都没有时，作为产品经理要有建立在对市场和用户的理解上的雏形方案。
>> 无论从用户角度，还是产品设计者角度，整个项目要满足需求这件事是可以运作起来的。
>> 产品模型是整个产品的根基，探讨的是需求实现的逻辑，并没有脱离需求的范畴。如果纸上谈兵似地讨论产品模型都发现走不通，那就说明需求层面的所有问题也就没有解决好。在不同的阶段，我们用不同的方式去做可行性的检验，这时的检验就像物理学中经常采用的“思想实验”。
>> 在产品从0到1的过程中，最先要确定的就是关乎需求的逻辑是否在产品上、商业上行得通。
对0到1的产品经理来自灵魂的拷问
>> 用户到底为什么要用你的产品？
>> 用户到底为什么要用你的产品？
>> 这里涉及两方面的问题：用户是不是有需求？你能不能满足用户的需求？
领导定一个结论，然后员工找各种证据证明这个结论可行。客观？不存在的！
>> 这是一个非常奇怪的方式，但也是很常见的错误：先想一个结论，再去找能证明这个结论的论点。
>> 这是一个非常奇怪的方式，但也是很常见的错误：先想一个结论，再去找能证明这个结论的论点。
>> 真正合理的产品逻辑是什么样的呢？就是需求能良好运转起来。
>> 做产品逻辑时应该掌握一种方法，那就是把所有想到的关系捋清楚，并且画成流程图或者结构图，在纸上运行一遍，看是不是可以跑得通。
>> [插图]
>> 市场的存在：指的是这个市场是否成熟。
>> 需求的存在：指的是需求出自臆想，还是真实的发现？
>> 用户的存在：指的是针对判定出的需求，用户群到底存不存在。
>> 提供的可能：对于单方的产品（比如像新闻客户端、搜索引擎）来说，服务和内容是我们官方提供的，那要考虑是不是从现实层面真的可以提供；对于多方的产品（比如像外卖平台、问答平台）来说，服务和内容则是由另外一端的用户提供，他们有没有意愿也是要考虑的。
>> 发生的场景：若是只说用户存在、需求成立，但却找不到发生的场景，自然也是不合理的。
>> 接受的意愿：很多时候我们的产品只考虑需求本身的合理性，而不考虑用户对它的接受程度。
>> 创业成功需要具备四个要素：团队、用户体验、成本和效率。
>> 效率：互联网带来的是信息化，信息化最大的价值就是提高了很多行业的效率
>> 成本：效率跟成本往往是对应的。
>> 体验：在当今消费升级的时代，体验也是很多产品的价值所在。
>> 产品经理在考量需求时，也一定要考虑到商业的层面。
社交电商是这么来的……
>> 很多做工具的产品都在希望能做内容，因为内容更有价值，它相比工具容易变现。而做内容的希望做社交，因为社交更有价值，证明用户在平台上互相产生关系了。做社交的想做电商，这就直接跟交易场景相关了。
>> 广告：互联网发展至今，广告依然是最大的蛋糕之一，也是最主流的商业模式。
>> 售卖：产品是明码标价出售的。
>> 增值服务：用户可以付费获得额外的服务、产品特性或者服务中的特权。
>> 佣金/抽成：主要是在信息或服务对接的多方平台
>> 企业服务：企业服务严格说其实也是售卖的一种。
>> 根据产品模型的特征可以匹配对应的赚钱模式。流量可观的，一般都尝试用广告的方式；有高质量用户的，可以考虑发掘他们的付费意愿；有数据或者渠道价值的，看能否进一步向第三方提供服务。
>> 没有经过演算的赚钱方法是没有意义的。
商业模式的启蒙书籍
>> 在讲解商业模式的书——《商业模式新生代》中，作者提到：商业模式涵盖了九个构件（Building Blocks），它们可以描述公司创造收入的逻辑。这九个部分分别是客户细分、价值主张、渠道通路、客户关系、收入来源、核心资源、关键业务、重要合作，以及成本结构。
>> 一个主要强调用户和市场上的逻辑合理性，另一个主要强调在经济和商业上的逻辑合理性。对商业模式来说，还存在一个重要的问题：商业模式不只意味着怎么赚钱，还要考虑清楚怎么花钱。也就是说，盈利能够覆盖成本的模式才是合理的模式，仅仅有盈利不能算有效模式。
很多公司拍脑门想出的点子是好的，但终究不考虑后期的运营成本会导致产品做的出养不出的窘境。
>> 说回刚才的话题。律师行业首先是小众群体，这样的用户群规模可能就比较小。从时间发展上来看，不会有太大的变化。如果要做需求，就只能是特别重的需求。其次，这个行业已经形成了自己固有的圈子和行事的模式（或者叫“潜规则”），想要突破很难，想要培养用户习惯也很难，所以做很重的需求，将会吃力不讨好。最后，即便是很重的需求做得够好了，那么想要拓展到律师行业外的领域，几乎也是不可能的。甚至在律师行业内的不同群体，大家需求的差别都会很大。
>> 想要进入的市场的状况是怎么样的？会发生怎样的变化？
市场竞争环境：所在的市场现在是怎么样的状况？是巨头和一大堆创业者都在打得火热，还是没人在关心、非常冷清？大家对这片市场的态度是怎么样的？
相关的技术：有什么技术会影响到这个市场的变化？在技术层面，对市场、产品的影响会有多大？比如会不会有一些发明颠覆市场的运作方式或者结构？
相关的政策：有没有相关政策会发生变化？是利好的还是利空的？
>> 面向的用户如何，会发生怎样的变化？
用户群体目前是怎样的？他们属于什么结构、有怎样的特征？这些属性会发生变化吗？对于不同年龄、不同领域、不同国家地区的用户，有没有拓展性？
>> • 产品逻辑的拓展性如何？
首先，对于当前的需求，可以实现的产品方案是单一的，还是多样的？对于这些方案，可以做的事情够不够多？是不是基于它们还能开展更多服务、实现更多功能？
其次，对于当前的用户可以满足的需求除了目前考虑到的部分，还有更多吗？如果用户沉淀下来，能否发掘他们更多的需求并满足？
最后，对于当前的垂直领域，可不可以扩展到相近的领域（比如从美甲到所有美容业）？如果扩展到这个领域，产品逻辑上可复用的部分是不是足够多？
>> 商业模型的拓展性如何？
赚钱的方式有一种，还是多种？每种商业模式的逻辑都成立吗？对于目前的用户，使他们成为付费用户或者说产生商业价值的可能性会因为某些因素发生变化吗？
>> 作为产品经理，尤其要清楚团队资源的状况。在当前的条件和资源下，到底哪些产品和功能是能够得心应手的，哪些产品和功能是会做得非常吃力的，哪些产品和功能又是遥不可及的，要有客观的判断，不要只顾着做“最好的”产品，却不考虑是不是有能力做这样的产品。
为什么是我们做？
>> 我理解你们的逻辑、明白你们的思路，我觉得非常合理也很科学，但是，为什么是你们做
>> 其一，你们有能力做出这个方案吗？能力可能是多面的，不仅是产品设计的能力，还有技术能力、运营能力，还包括资金的情况。其二，你们比其他人做有足够的优势吗？就是在各种所需的能力上，每项跟其他竞品团队的能力有多少差距？
记住这句话，考试重点！
>> 点子并不代表着任何意义。
◆ 第2章 找到产品核心价值
战略是支撑产品的基础，一切违背企业战略的产品功能都是徒劳。所以产品经理在定义产品功能之前一定要明确公司的战略是什么，部门的战略如何支撑公司战略的执行，只有这样才能明确哪些功能现阶段优先做，哪些功能可以延后，因为需求是无止境的，时间和开发力是有限的。
>> 核心价值其实就是战略层里包含的目标，也是最基本的底层支撑。
>> 核心价值其实就是战略层里包含的目标，也是最基本的底层支撑。
为什么要找到产品的核心价值
>> 第一，发现核心价值，能够选择综合考量下来最优的功能。能够创造价值的功能很多，但核心价值意味着对产品来说，这样的功能性价比最高，或者是最受用户认可、最有商业价值、对公司最有利。
第二，基于相同的核心价值设计的功能，逻辑统一。逻辑一致的功能可以互为补充，用户群体相似、需求也相似，能让价值产生增益。而零散的功能，成本高，往往吃力不讨好。
第三，有单一的核心价值能够让用户对产品产生认知。想要依靠多种价值打动用户在初创阶段往往特别困难。产品起初强调核心价值和核心功能，可以让用户更理解这个产品能解决什么问题。很多产品是大杂烩，用户可能都发现不了自己想要的功能，因此很快就流失了。
>> 核心价值的定义应当是，离开了它，产品就不能真正解决用户的实际问题。
典型的屁股决定脑袋
>> 大公司的工作流程是标准化的，职位和职权细分很清楚，就常常不会有人关注到全局或者整体，也不会有人特别在意可能职权覆盖不到的地方。
>> 大公司的工作流程是标准化的，职位和职权细分很清楚，就常常不会有人关注到全局或者整体，也不会有人特别在意可能职权覆盖不到的地方。
>> 只关心概念上的指标的产品经理，就会把焦点放在怎样去活跃用户、吸引用户上，而且会做得比较肤浅。
前半段同意，后半段有分歧。作者所提及的是针对于大厂KPI或OKR考核下的产品经理，一个团队的核心都是为目标客户服务的，而运营也是其中一部分，问题是多方面的，那么产品经理应该在多方面思考、协调和处理这些问题。
>> 产品经理关注的是真正解决用户的问题，而用户不够活跃，可能有多方面的原因，不能牺牲产品逻辑的一致性来完成运营目标。
我觉得挺好啊……只是我买不起房车罢了……
>> 如果让只关注黏性的产品经理来做，甚至会把各种好玩的东西塞进车里，把车打造成一个私人KTV、个人影院甚至娱乐室，然后留住用户再放各种广告……这根本就违反了整个产品的逻辑，结果就是用户未必能很好地解决他的问题，甚至可能会制造新的问题。
第一时间想到拼多多
>> 有的产品经理做的功能都要依靠黑魔法，先是硬塞入醒目的小红点让用户忍不住点击，等用户免疫之后，不得已又硬塞各种弹窗。等用户再次免疫之后，就再硬塞链式启动和大礼包，产品越做越可怕。
>> 用户的“量”不重要，“质”更重要。而要让用户真正跟你的产品产生很强的关系，自然就要看解决问题是不是够好、够快、够准。在解决问题的时候，要确保产品真正能满足用户需求。最尴尬的情况是，你费尽心思终于分析出的需求，精准无比，但做的功能却扑了个空。
>> 你认为的问题，别人未必觉得是问题。即使大家都公认是问题，你也不能保证，他们就觉得这个问题是必须解决的。
>> 在考虑我们产品的核心功能时，不仅要判断是不是满足了用户需求，还要判断是不是以超预期的方式满足了用户需求。
>> 我们把超预期给用户带来的愉悦感和实际的好处（成本更低、效率更高等）记作X，把用户转移产品的心理成本（对新产品的陌生感，以及尚未建立的信任感）记作Y1，把用户转移产品的实际成本（比如新产品注册花费的时间、转移资料花费的时间，以及像会员积分这样的实际损失）记作Y2。那必须保证X＞Y1+Y2，这样的产品才能让用户满意。
>> 发现产品的核心价值，就是发现如何解决用户问题的过程。好的产品能够解决用户的实际问题而不是故意黏住用户。
>> • 解决不了问题的产品，只能靠补贴和红包留住用户。一旦遇到更大的红包，用户说走就走。
• 问题解决得够彻底，下次用户会主动来找你。
◆ 第3章 MVP与痛点
奥卡姆剃刀法，是在完整的功能上做减法以实现最简化产品的目标。
>> 如无必要，勿增实体
这点有启发，因为我所理解的是让机器代替人工，而作者见到的MVP是可以用人工先来验证需求。是这个道理！
>> 去掉可人工处理的功能
在很多互联网产品的创业初期，都是人工去处理很多事务，比如外卖平台最早的做法，很多都是工作人员看到订单，亲自给饭店电话下单。那时候根本没有商家端的产品。把这些可以人工处理的功能丢掉，暂时用人力来完成，是降低开发成本、实现MVP的好办法。
>> 去掉可人工处理的功能
在很多互联网产品的创业初期，都是人工去处理很多事务，比如外卖平台最早的做法，很多都是工作人员看到订单，亲自给饭店电话下单。那时候根本没有商家端的产品。把这些可以人工处理的功能丢掉，暂时用人力来完成，是降低开发成本、实现MVP的好办法。
>> LTV/CAC＞3，即用户终生价值/用户获取成本＞3。所谓用户终生价值，指的是用户在使用产品的整个时间周期中与产品互动所产生的全部总计收益；而用户获取成本，指的是获取同样的用户，要花费的总成本。
Mark一下未来的日程
>> 每周看1000篇帖子或微博，看100篇博客，做10个CE（Customer Engagement，用户参与
>> 每周看1000篇帖子或微博，看100篇博客，做10个CE（Customer Engagement，用户参与
>> 在理论上成立，在实践中证明
◆ 第4章 深挖需求
>> Want（需要）和Needs （需求）来区分这两者，前者是“希望在产品中看到的功能”而后者是“确定的具体问题，留待产品解决的问题”。
>> 而我们讨论场景时讨论的本质是什么呢？我们讨论的会是很形象的一些描述。这里面包含了人物、时间、地点、环境及情节。我们要用场景来发现我们的用户是谁、他们会在什么情况下解决原有的问题、他们怎么解决这些问题的，等等
>> 对于不同的产品经理，看问题的角度会有所不同，而具体是从需求表层出发，还是从需求根本出发，那是看问题的层次不同。从人性角度去看问题，是更高的一种视角，能够知道表层需求的背后，反映出的人性需求。
>> 逐利心理
如果产品模型本身就能带来红利，那么就可以满足用户逐利的需求。
>> 两性吸引力
用合法合规的方式满足正常人都会有的色欲，也是很多产品在做的尝试。其实从广义上来说，色欲就是正常的两性关系的前置条件。
>> 懒惰
在很多情况下，互联网服务的确提高了效率，降低了成本。对于用户来说，会体验到越来越多方便和快捷，也满足了更多用户比较懒、不爱动、不爱思考的天性。
>> 虚荣心
虚荣心是最容易利用的一种人性：当你在逐利或者贪色的时候，你心里是清楚的。但追求虚荣的时候，往往都是不自知的。
>> 共情需要
共情，英文是Empathy，也可以翻译成同理心。原本是指设身处地思考，并且感同身受的一种能力。在这里，我想借用这个词表达一个人性上的需求，即我们希望体会他人的生活和感受的需求。
>> 社交货币
人是社会动物，社交也是很基础的属性。加强沟通的效率、增多沟通渠道、丰富沟通的方式是互联网时代很容易完成的任务。微信就是在这条路上的尝试。在很多年前，一条消息的传递非常麻烦，方式也很单一，尤其是多人交流简直是无法完成的事情。微信很好地满足了社交中的沟通需求。
>> 单纯的沟通是基础，有效地建立起社群，或者说满足某些用户的归属感是更高一层的要求。
>> 那么在互联网产品中社交货币是什么呢？答案就是产品传递出的“价值观”。
>> 安全感
安全感是马洛斯需求层次中很底层的一部分。在使用任何产品的时候，我们都会特别在意安全问题。有的互联网产品就是直接解决用户的安全需求，或者把安全作为核心的亮点来吸引用户的。
◆ 第5章 用户研究
>> [插图]
◆ 第6章 用户体验
>> 用户体验定义为“人们对于针对使用或期望使用的产品、系统或者服务的认知印象和回应”。
>> 可见原则
保证界面的内容可见、状态可见、变化可见。
>> 场景贴切原则
让功能操作符合用户的使用场景
>> 可控原则
用户要能对当前的情况很好地了解和掌控，足够自由。
◆ 第8章 需求管理
>> 我在工作中有三类需求绝对不记。
没说清楚原因的需求，不记。（“你做个XX出来，别管那么多。”）
不说清逻辑的需求，不记。（“啊，这里我也没搞懂，你先看看。”）
不是实际遇到的需求，不记。（“哎，我觉得可能有人会这样用。”）
>> [插图]
利用需求矩阵，通过优先级和成本双矩阵把控需求的高效执行。
>> 需求太多，没按时做完；需求有改动，导致了额外工作量，引起开发人员的不满；有新的紧急需求，导致发布延期。
◆ 第9章 工作流中的管理
管理是把事情做对，而领导是做对的事情。——彼得·德鲁克
>> Management is doing things right; leadership is doing the right things.
——Peter F.Drucke
>> Management is doing things right; leadership is doing the right things.
——Peter F.Drucke
>> 实现一个目的有很多方法，但往往会选择最容易想到的而不是最好的方法。这样就导致花了大量精力在没必要的事情上，其一，你做的事情其实应该是别人做的；其二，你做的事情应该有避免重复劳动的更高效的方法。
>> 后来针对跟业务部门的协作，我们制定了以下规范：
所有需求必须通过邮件提出。否则，不予理会。（目的：为了记录需求内容和明确责任人。）
业务方的需求提出者是固定的接口人，不接受其他人的需求。（目的：业务方过去经常在未达成内部一致的情况下提需求，造成麻烦。）
产品这边接收方也设立固定的接口人。（目的：防止需求重复设计、由一个人统筹外来的需求。）
需求的状态每周固定时间发布。（目的：让需求来源方放心，了解需求正在推进的状态。）
有延期的需求，发送邮件给相关需求方，告知原委。（目的：让需求方了解延期的原因。）
>> 在iOS上有一个应用叫做Workflow，
>> 在《领导梯队》里，作者提到了作为领导应具备的三个管理能力为：领导技能、时间管理和工作理念。
◆ 第10章 处理问题
>> 有跟我们的预期不符的状况，那就是我们需要解决的问题。
>> 要能够很好地发现问题，我们应该做到以下几点：
>> 1．在工作中对任务要有预期。
>> 2．敏锐地察觉到与想象不符的状况。
>> 3．不应关心没有预期或与预期差别不大的状况。
>> 4．问题是合情合理的吗？
>> 不能只提出问题，却不负责证明问题的合理性。
>> 5．问题是真实存在的吗？
>> 。把问题本身考虑完整，再进行下一步的分析。
1．考虑问题的背景。
>> 2．考虑问题涉及的人。
>> 3．考虑解决问题的期望。
>> 没有痛感也要主动发现问题，这是产品经理的基本素质。
>> 多演讲者对问题的提炼都是很精彩的，他们能够瞬间对问题作出分析，找出问题的本质，用一句话把提问者问题的核心表达清楚。
>> 我们分析问题时，也需要借鉴这种方法，把复杂的问题抽象出容易理解、方便解决的本质。
>> 把产品经理看成是相对感性的工种，以为需求分析在于“一针见血”，功能设计在于“一剑封喉”。但产品经理的工作偏偏是最需要讲逻辑的，很多设计层面出的错误，等实现后再发现有错漏就为时已晚。关于逻辑分析，仅讨论几种我经常遇到的逻辑错误，它们能够覆盖大部分的场景。
滑坡谬误（Slipperyslope）是一种非形式谬误，使用连串的因果推论，却夸大了每个环节的因果强度，而得到不合理的结论。
>> 滑坡谬误（slippery slope fallacy）
>> 问题摆在这儿，现在只有两种方法了，到底选哪个？这种话就是轻易断言。很多事情我们只是没想到更好的解决方案。在之前的产品工作中，考察实现一个需求的足够好的功能，我们不会简单地断言当前讨论的A、B、C三个方案必须要选择其一。甚至有时，我们会推翻十几个方案，继续去想更好的方案。
>> 这个世界上，既不存在“完美的”解决方案，也不存在“唯一的”解决方案。在分析问题时，我们要找的是可以真正解决问题并且让我们自己满意的方案。
>> 我们对待经验看法和案例所传递的观点时要非常慎重。许多鸡汤文会告诉我们，努力即可有回报，多少人是白手起家最终成就一番事业的。但并不代表努力就是充要条件，也不代表放在任何人身上都具有普适性。每个人在传递自己的想法时，都会有对自身的考量，这样的想法也自然不能算严谨的推理结果值得我们完全采纳。
>> 产品经理应该对统计数据敏感，但不能误读统计数据的含义。
>> 在发现和分析问题时我们面向的对象是事，而在解决问题时主要面向的对象则是人。
>> 当你解决不了一个复杂的问题时，就要试着拆分这个问题，不断拆分，直到你觉得每个小问题都是自己能够解决的程度再去解决，解决之后再组合，整个复杂问题也就解决了。
◆ 第11章 沟通
>> 对产品经理来说，好的沟通能力要包含以下几点：
• 能够快速、准确地理解别人表达的信息。
• 能够准确、通畅地表述自己想传递的信息。
• 在理解和表达中就事论事，也能照顾大家的情绪。
>> 对某些信息真正掌握，就是可以把信息再准确无误地传递给别人。
关于事实和观点，可以阅读《非暴力沟通》，该书中对非暴力沟通的第一条原则就是陈述事实，其中有详细的讲解。
>> 区别事实和观点
◆ 第12章 成长
>> 有趣跟好奇心是分不开的，也跟对事物的了解程度分不开。
>> 我们按处理问题的整体流程来看，首先确立标准，也就是定义清楚问题。千万不要觉得面试就可以不做准备，“一个人靠不靠谱聊一聊不就知道了”，我一开始也是用这种思路来面试的，但发现效率极低、效果极差。
如果只关注这个人的言谈举止，只能看得出他大致的情况，如年龄、健康状态、基本的性格（外向还是内向）、沟通是不是顺畅，稍微深度的信息就很难发掘。我们是要了解产品经理的能力和他的经验，最后目的是判断他是不是符合岗位的要求和招聘的标准。这些都是随便聊一聊做不到的。
那标准该怎么确立呢？可以先列出所需的技能项。比如，我理解的产品经理所需要的技能有：
• 需求分析
• 功能设计
• 项目跟进
• 行业知识
前三个在第一部分已经解释过了。最后一个指的是要对互联网圈内或者所从事的行业内的知识和信息有所了解，往常的工作不都是闭门造车。
针对每一个技能项分三个档次，然后增加说明。比如，拿到了数据可以做出判断，这是段位比较低的。再高一些的要求，应该自己有调研、访谈或者收集数据的能力，需求的分析更加合理。最高的要求是可以有成套的方法，系统地获取用户需求。
那么需求分析的技能项标准表格按三个档次分就是：
>> 我理解的产品经理所需要的技能有：
• 需求分析
• 功能设计
• 项目跟进
• 行业知识
◆ 点评
点评:★★★★☆
公司推荐书目。这本书很适合入门级的产品经理阅读，当做作者对过往工作的复盘去看比较合适。里面总结了作者从想法，需求，MVP的全流程想法，有日常工作中的管理方法，也有一些如何提升专业技能的“鸡汤”，因为我也做了多年的PM，对作者的一些经历比较有感触，新产品入门推荐阅读。
AICG
SaaS
产品经理
工业物联网