PDM，读《人人都是产品经理2.0》

终究还是看了人人都是产品经理一书。原因有三，一是名声实在太大了，当初抗拒此书也是这个原因（就像旅游攻略推荐的网红店，看到排起的长龙就放弃了），但随着影响力突破阈值，此书成为了必需项。否则在攀谈时，缺少了部分共同语言；

二是公司VP近日细读了此书，开始在部门内大力倡导。传统公司、IT软件行业，逐渐重视产品经理的概念，从项目经理到产品经理，从项目实施到产品，这个趋势此书也有提及（谈及产品经理的前景，传统行业会产生巨大的需求）。甚至领导在研究如何把人人都是产品经理的理念，落实到部门管理制度中。一开始很是不解，这不是一本讲管理或组织的书籍，产品经理只是公司众多岗位中的一个，如何与管理对应上？读完此书后明白了，关键是以产品经理为载体，传播重视市场、重视客户的理念。公司这两年倡导变革，拥抱变化、拥抱市场，从做了什么到为客户做了什么，一切以市场价值为衡量基准。而这正是产品经理擅长的，连接客户需求与解决方案，PMF。变革的效果，在于能否让各利益方清楚的了解变革的必要性。对于领导，关键在于能找到一个例子、一个载体，借此来清晰传达变革的理念。以我们IT部门为例，近几年实施了大小几十个项目，包括多个千万级别的。系统成功上线了，但上线成功了吗？这往往不是项目经理关心的，给我一个目标、范围、预算，项目经理专注在既定要求下关闭项目。在项目前期对于可行性验证，普遍不够重视。业务用户的问题真的弄清了吗？痛点抓准了？目前业务成熟度、sponsor意愿是否足够支撑？实际情况很可能是大家都没有想清楚，为了上系统而做一个项目，要不说项目经理难做，精力全花在填坑上面。而强调产品经理，就是希望能在需求验证与解决方案可行性分析时下功夫，先想清楚了再做，否则精力就要花在不增值的执行环节。而项目后期，系统上线，经过1-2个月运维后，项目经理就卸任了。在甲方，大型系统由BA接业务需求、评估、排序、指导技术人员开发，一般系统则直接由技术人员运维（兼具接优化需求）。公司在实施PLM时，乙方项目一直在打预防针，上线后一年内，先不要看价值，优化到能用就不错了（这还是业界前三产品）。这在互联网C端看来难以想象，从0到1造出来仅是开始，要靠规划与迭代打磨产品。好产品是改出来的。因此传统公司采用产品制，就是让产品经理（往往由原BA、项目经理担当此责）对产品全生命周期负责，上线后，产品能给业务带来多少价值，由产品经理全权负责系统。这样也有助于领导的有效把控力，专盯产品经理，月度规划与版本迭代情况；

三是听说2.0相较于1.0，侧重于道，不像1.0讲解了许多操作层面的内容。虽然目前不在互联网行业，但对于产品经理每日要做什么，还是了解的。

回到此书，将产品经理的工作要点，按事情的先后顺序做了阐述。难得的是作者结合自身及他人经历，分享的案例。并且最后两章，对于创新创业、产品经理升级套路，做了论述。计划3月份跳槽互联网PM岗，对照着能力模型图，打怪升级吧。

---

读书笔记

1. 产品关键词与分类

   1. 用心听用户，但不照做             //第一金句。反过来正是我们常犯的。不“听”用户，只是作为传话筒，把用户的要求递给开发。
   2. 不但要听用户怎么说，还要看用户怎么做             //最有效了解用户的方法，有时候业务听起来很复杂、或高深，其实跟着用户旁边一周，门清
   3. 人人都爱提主意 
   4. 用户是产品的一部分；如果你是游戏的免费用户，那你其实是游戏提供给付费玩家的一个功能             //对于过边产品，用户的目的是借由产品与他人发生关系
   5. 产品架构、产品设计、产品管理、产品运营
   6. 想清楚自己肯定不要做什么，就可以逐步找到自己的定位             //用户调研也可采用此办法，直接问用户怎么办当然这行，但我们打算这么办，你觉得呢
   7. 这是一个供给充足、市场细分、用户选择很多的时代，情愿选择让一部分人爱你爱得发疯，另一部分人恨你恨得要死，也不要让所有人都觉得你还OK，你是个好人，然后就没有然后了。这就是产品的调性、品牌的人格化。             //峰值有正有负，总比均值为0好
   8. 核心用户定义得越精准，产品设计、推广等过程中的目标将越明确。

2. ---

   概念提出与筛选

   1. 可怜的是，很多产品根本没有任何“唤起点”，用户怎么想到用你？这也意味着你还没找到自己的典型场景。所以，只要是一个“点”，就不要怕小，怕的是没有独特性，怕的是不够典型。             //三节课也强调了“典型场景”，梁宁也提到，场是指特定时间&空间下，景为唤起的情景。产品是被动的艺术，要靠用户在特定情况下，被用户想到去使用。
   2. 先找定一个对手，打透以后再考虑视野和格局，再扩展
   3. 竞品选择
      1. 相似产品，同样的产品功能解决同样的用户需求
      2. 满足同样需求的不同产品功能，替代品，调研的不仅是功能，而是用户的深层需求；同样的功能解决不同的用户需求，不同需求场景下，不同的潜在竞品；解决方案经常变，但问题不变，元问题
      3. 所有消耗用户时间的产品
   4. 问题和解决方案，不一定先有哪个，最重要的是要找到它们的匹配。这才是产品经理价值的本质。             //手上拿着的可能是钉子也可能是锤子，关键是不能因为拿着钉子看啥都是锤子，或拿着锤子哪都，产品经理要专注找到适配的另一方。
   5. 划分用户的目的是为了需求场景的差异化              //三节课提到，用户的作用是为了划分不同的场景、问题，进而提供适配的解决方案。因此这里的用户不是指自然人，而是一种分类维度，需求的集合。

   6. 种子用户

      1. 配合意愿高

      2. 久病成医，有自己的想法，用户顾问              //确实，与一线业务人员多聊聊，往往收获更大。虽然他们提出的方案过于片面，但对于公司、部门的顽疾，看的很透彻。

      3. 忍受力高。不完美的产品，才是迭代的产物

      4. 义务传播

   7. 波特五力模型

      1. 竞争对手竞争能力；市场成熟度、竞争激烈程度；成熟度低，用户教育成本高；竞争高，往行业上游走

      2. 潜在对手进入能力；代表门槛高低

      3. 替代品替代能力；

      4. 供应商/客户议价能力；

   8. 对一类用户、需求、场景的定制，可成就一个产品，形成壁垒，也会因产品基因成为限制。             //类似价值网的概念，大公司创新的窘境，成熟产品创新的窘境。

3. ---

   需求采集与用户研究

   1. 用户怎么说和怎么做经常是不一致的。“说”最大的劣势是“耳听为虚”，怎么解决耳听为虚呢？看他怎么做。“做”的优势就是“眼见为实”，但也有劣势：我们不知道用户为什么这么做，背后的原因是什么，也就意味着没法从根本上解决问题。于是，需要再去听他如何说。所以说和做是一对不可分拆的方法，尽量同时用于一次需求采集              //说白了是如何透过表象挖出根因，直接听用户讲原因是什么很难找到root cause，必须先看他们实际怎么操作的，然后据此向他们提问，为什么这么做？这个操作要注意什么？才有可能挖到根因。

   2. 定性的问题是“以偏概全”，被部分样本的特殊情况带入歧途，所以要辅以定量的方法。但是定量会“以表代本”，只能用来发现表面的现象，却无法从中知道背后的原因，做一个定性的访谈，来搞清楚到底发生了什么。

   3. 需求采集时，是否发生在真实场景中

   4. 临场感，因为需求是带场景的，对体会把握的准确感；变为小白，回滚到完全不了解产品的心理状态；回到用户发生需求的场景中，真实的用户不是用户群体              //所以听说TX评审方案时，会注重产品经理对于用户是否摸得透，对用户有感觉，往往抓的准相应的场景与需求。

   5. 需求采集时，用户是否与产品发生互动；用户想象自己是否需要，和真的用过以后是否实际需要，存在出入，通过产品交互发现；电视机需求、洗碗机需求。              //还有是否会为此需求花钱？

   6. 低成本验证

      1. 简化实现

      2. 跑人肉流程去验证              //主干流程线上跑通。分支、异常流程，频率若低的话，先靠人工操作完成。

      3. 让用户低成本体验

   7. 用户想法，存在滞后、惯性              //尤其是惯性，B端产品的替换成本极大。一个shi到不能shi的系统，用了一年习惯了，对于换一个更好体验的系统，会有极大的抵触心理。好不容易习惯了，别换了。

   8. 最重要的用户还是外部的。满足任何战略需要的内部需求时，心里都要时刻想着外部用户，防止本末倒置。战略需要而用户不需要的产品，往往没有好下场。

   9. 用户，抽象到具体到抽象

      1. 假象，目标、核心用户

      2. 用户故事

      3. 真实用户合并特征，人物角色，修正产品概念

   10. 观点与行为、目标与动机、人性与价值观

   11. 产品原则，讨论对错没有达成共识更重要 

4. ---

   需求分析与Y模型

   1. 产品功能多、选择多，往往是减分项，因为让用户弄不清重点

   2. 没法创造需求，只能创造新的解决方案，来更好的满足需求 //底层需求，无非多快好省

   3. 成熟市场的竞争，仅仅满足用户提出的需求是不够的，因为在预期范围内。需满足人性方面的需求，用户没想到的问题

   4.  

      

   5. 由用户需求-目标动机-人性需求，要尽可能的深入详尽；由人性需求-目标动机-产品功能，采用尽可能简单的方案

   6. 产品属性与个人价值，攀梯术              //for用户调研

      1. 用户需求与产品功能是否与人性建立关联

      2. 情景唤起，假想、回忆

      3. 假设状态缺失后会怎样

      4. 反面攀梯，无法说清做什么的原因，询问不做某些事情或不想产生感觉的原因

      5. 时间倒流对比，让用户反思，与现状对比

      6. 重定向，沉没或重述确认，以鼓励用户继续讲述

   7. 完美不是无一分可增，而是无一分可减              //金句

   8. 用户任务越简单，产品功能的实现越复杂，把简单留给用户              //看来领导是看了这句话，天天说：把复杂留给自己，把简单留给用户

   9. 面对问题时像新手，一秒变傻瓜，进入没有任何专业知识的用户视角；解决方案时成为专家，需求本质、高性价比的解决方案              //这个讲法很精辟。在听取问题时，不怕像傻瓜一样向用户反复求证，以真正找到问题，哪怕这个阶段可能会问到用户翻白眼；但在提出解决方法时，要体现专业度，适当的以我为中心，前提是你要解决什么我已经清楚了

   10. 问题中心，方法中心

   11. PMF，product/market fit

   12. 产品功能

       1. 需求价值

          1. 广度；潜在客户数*单价；高频低单价抓用户，低频高单价抓利润；有海量用户做基础，低频总量才足够大 //就是互联网的长尾效应，利用互联网边际成本低的特性实现用户个性化需求。

          2. 频度；频率*复杂程度

          3. 强度：可替代性、紧急程度、持续时间

       2. 日常评估时，没法面面俱到，所以通常会先判断成本的瓶颈在哪里，然后用对成本瓶颈的评估来简化完整评估

       3. 流程在效率可以接受的前提下，不用非做产品，可以人肉流程以验证模式 

       4. KANO

          1. must have

          2. exited to have

          3. nice to have；往往就是用户提出解决方案时能想到的功能

          4. indifferent have

          5. reverse have；用户多边形，因角色存在相斥性，对同一功能存在正向、负向满意度；用户的多样性

       5. 用户需要的东西有时候并不难实现，但很容易被忽略。如果你不是一开始就跟用户接触，就很难知道这些内幕

       6. 优雅降级，全部功能都有，目前必须关闭部分功能，会保留哪些功能？             //目前很多时候都会此思维模式，正向加法不好做，那就反过来假设存在全集，减法怎么做？

       7. MVP阶段，就开始设计独立后台功能

   13. 万能借口

       1. 需求放到二期              //这个用的太烂了，所有人都不信了

       2. 不是目标用户              //烂而好用，很难反驳

       3. 是你的需求还是用户的需求              //还是某位领导的需求？

       4. 你们再去评估一下

5. ---

   立项与研发

   1. 产品概念测试

   2. NPS 净推荐值

   3. 产品委员会，资源决策的

      1. 概念筛选              //对应可行性分析评审

      2. 立项组队              //对应成立项目组

      3. 上线发布              //对应go/no-go meeting

      4. 营销推广              //对应上线一周后的上线报告

   4. 时刻思考合作者的内在驱动力

   5. 团队问题的具体答案是什么不重要，重要的是共同参与              //跟人有关的问题，大多如此，在于共识

   6. 产品经理应该和技术人员一起做“预测”，心里想着目标，一起面对变化。最核心的区别是：承诺是技术对产品的责任，预测是两边一起承担责任。             //类比S&OP会议，销售与供应链一起参与做预测

6. ---

   规划与迭代

   1. 业务规划

      1. 业务定位如果一句话无法说清，那说明定位还不够准确，没有想清楚              //金句，一句话说不清产品定位，说明还没有想清楚

      2. 业务模型

      3. 业务关键点

      4. 多问、多被问

   2. 迭代

      1. 角色简化；

      2. 流程简化；

         1. 主流程：立项会议、需求评审、功能评审、发布上线；

         2. 分支流程：需求变更，日常需求

      3. 文档简化；

   3. 低成本验证，用简单的产品雏形把业务逻辑跑通，再决定是否做客户端。否则上线容易下线难，维护使用量很低的产品，机会成本大，后续新功能也需额外考虑兼容              //因为验证的本质是商业逻辑，而非技术实现手段

   4. 可选的低成本验证方法，文章传播、公关

   5. 用户是产品的一部分，成长成熟后，产品与用户是共生关系

7. ---

   运营

   1. 用户的需求，不是全满足，满足不完，总会源源不断地出现。需求需要控制，就应该让各种用户“欲求不满”。但控制不是目的，而是为了找出最刚性的需求来优先满足，因为都重要等于都不重要

   2. 验证阶段，反而要控制大量用户涌入。因为大量主流用户，只会给产品一次机会 //B端产品则不是，充分大量测试，不做控制，因为B端产品是主动的艺术，而非被动。这是与C端产品本质的区别。

8. ---

   创新

   1. 没有落地、实现商业价值，只能叫做新发明、新发现

   2. 技术风险与市场风险是等权重的

   3. 用户只能提出渐进式创新，而产品经理提出颠覆式创新

   4. 事情是做出来的，想到的idea秘密毫无意义，一定已被无数人想到过，或者尝试过，只是你不知道而已，在做的过程中发现的秘密才具有价值              //金句，基本上所有事情都是这样，很难有独特的想法，关键在于实践落地。

   5. 没找到确定真实的用户需求之前，一定不能开始做              //金句，没想清楚之前，不要做，做也是错的。

   6. 等到你敢拿着产品去见用户时，一定已经晚了              //测试一定要仅可能的早，在你认为已经提前到极致时，再提前些，例如流程没跑通，那可以给用户看静态表单界面，是否是这些字段？

   7. 预测和规划的成本大到，不如直接冲上去干，集体中总会有一个团队成功，快速抢占市场。              //这种现象会越来也少，哪个山头都已经有人了，而小山头细分市场不存在快速抢占。

   8. 产品经理未来看好的点

      1. 对于高级岗位的需求，逐渐细分

      2. 传统行业对于产品经理的需求，由于与互联网联系逐渐密切，巨大的增量市场

      3. 工程师缺乏业务感觉 //不是我们工程师不行，而是被任务压的，硬生生把自己变成执行机器才能完成已有工作。

   9. 尽快做出一个丑陋的产品，追求尽快验证；每周树立一个里程碑，从而保持快速迭代的节奏；初期技术可以外包，产品设计层面不可外包。              //保持迭代节奏很重要，对于团队。即是只是改了样式也是迭代内容。

   10. 认可快死比半死不活更好，死亡是一家公司对社会的最后一次贡献。