《人人都是产品经理2.0：写给泛产品经理》读书笔记

互联网产品经典入门书，主要面对-1到3岁的产品经理，详述产品的底层逻辑，产品经理领域的“知识地图”，产品经理的思维方式和做事方法。

《人人都是产品经理2.0》笔记精华

• 第01 章 初识：大话产品经理／13
  • 1.1 从一个小故事谈起／15
  • 1.2 产品经理的前世今生／16
    • 产品经理概念诞生
      • 宝洁第一次提出了产品经理的概念。
        • 上世纪二三十年代的现代企业时期
        • 当时宝洁推出了一种佳美牌（Camay）香皂，但销售业绩较差。一个叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于Camay和Ivory（宝洁的一种老牌香皂）两款香皂，那么Camay的潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持。之后，每一个宝洁品牌都当作一个独立的事业在经营，有专门的产品人员、销售人员给予支持，直接与其他宝洁品牌竞争。
      • 麦古利
        • 全世界第一位产品经理
        • 负责Camay香皂的品牌建设、市场销售等几乎所有的事情。
    • 项目经理和产品经理区别
      • 项目经理：
        • 靠做—执行+计划+控制—项目越做越小，越做越确定（立项和结项），是个封闭式命题
      • 产品经理：
        • 靠想—创造力—产品越做越大，是个开放式命题
  • 1.3 思维方式与性格特点／22
    • 思维方式
      • 从学生到职场
      • 从用户到产品经理
      • 从现象到本质
    • 性格加分项
      • 热爱生活，保持好奇心
      • 理想主义+完美主义
      • 善于沟通，具有团队精神
      • 抗压，自我激励，情绪调节
  • 1.4 产品经理的日常／32
    • 产品日常
• 第02 章 产品：关键词与分类／41
  • 2.1 产品：解决某个问题的东西／43
    • 【某个】
      • 明确定位（所有人？明显定位不清）
    • 【问题】用户、需求、场景
      • ►用户： 这个问题是谁的问题。
        • 更加多样
        • 1）广义用户：
          • 即产品干系人
        • 2）用户类型多样且有主次之分
        • 3）用户指“角色”，
          • 而不是传统意义的“自然人”：例如客户和终端用户
      • ►需求： 问题的核心是什么。
        • 更加碎片
        • 1）最浅需求
          • 表象
          • “我要xxx功能”
        • 2）第二层
          • 背后目标和内部动机
        • 2）最深一层
          • 最后归结为人性（马斯洛需求层次理论、erg理论）
        • 3）满足需求的三种方法：
          • 提高现实：
            • 自己努力、公司加薪、国家减税。
          • 降低期望：
            • 忆苦思甜、比下有余。
          • 转移需求：
            • 寻找新关注点、转移注意力。比如，和平年代用国与国对抗的体育赛事来激发集体主义、
      • ►场景： 用户在什么情况，以及何时何地碰到这个问题。
        • 更加多变
        • 用户：
          • 用户多样化、触达用户的渠道复杂化
        • 需求：
          • 更加丰富多样，也更加碎片
        • 场景：
          • 随时随地，在各种环境下
    • ！移动时代对于产品经理的要求！
      • 要掌握移动领域的基础知识：
        • 比如安卓和iOS规范，新功能等
      • 要熟悉各种更可利用的硬件：
        • 比如重力感应器、NFC、加速感应器等
      • 要理解互动方式的变化：
        • 摇晃（摇一摇）、语音等
      • 要明白产业链结构：
        • 比如BSP硬件层[5] 和OS操作系统层、OS suite层（如MIUI等）及App层等都需要了解。最终产品需要考虑的适配情况复杂多变，比如iOS和安卓平台、多种屏幕分辨率、各种手机厂家对UI层面的改造，等等。
      • 要懂得用简单逻辑完成任务：
        • 流程能串行就不并行；减法+“单核思维”；强调任务简单，大任务拆分，单任务沉浸
      • 要采用更灵活的实施过程：
        • 敏捷开发
  • 2.2 常见的产品分类维度／51
    • 用户关系角度
      • 1）单点：
        • 计算器
        • 1人使用
        • 无网络效应
      • 2）单边：
        • 电话
        • 1群人使用
        • 可能有网络效应
      • 3）多边：平台级产品
        • —群人使用
        • 壁垒高，易垄断
        • 双边：
        • 三边：知乎（提问者+回答者+围观者）
    • 用户需求角度
      • 工具：
        • （初级产品形态）解决单点问题
        • 优势：
          • 容易启动，引流
        • 劣势：
          • 黏性弱
        • 商业模式：
          • 不强制留咨，采用个性化定制
      • 内容：价值过滤器
        • 商业模式：
          • 逻辑思维：卖书/知乎：内容付费/微信：内容打赏等
        • 发展原则：
          • 有趣的表象+有价值的内核
      • 社交：彼此互相吸引
        • 优势：
          • 用户黏性高
        • 劣势：
          • 变现困难
        • 商业模式：
          • 直播礼物/付费解锁用户信息/电商带货等
      • 交易：做生意卖东西
        • 形式：
          • 电商/O2O
        • 优势：
          • 变现流
        • 劣势：
          • 业务流程复杂
      • 平台：
        • 复杂的综合体—“生态”
      • 游戏：
        • 打造平行世界
      • 常见产品发展道路：
        • 从一个小工具单点启动，快速获取用户，然后让这些用户彼此吸引，留下个人信息和用户关系，转社交，黏住他们；或者从内容转社交，建立互动探讨的机制；接着设法转交易，给他们卖一些符合调性的东西；继而引入各种合作方，成为平台……越往后想象空间越大。
    • 用户类型角度
      • 角度1：企业 vs 个人
      • 角度2：群体 vs 个体
      • 角度3：工作 vs 生活
      • 角度4：男人 vs 女人
      • 2B
        • ► B2D ，
          • 云储存、大数据等开发者服务，帮助开发者提升效率的基础设施。
        • ► SaaS1.0，
          • 通用管理型SaaS，是传统意义上的管理软件。
        • ► B2B ，
          • 垂直行业交易平台，是信息撮合+在线成交。
        • ► SaaS2.0，
          • 垂直行业 SaaS 工具+交易，是SaaS1.0和B2B的综合，2015年左右开始成为新趋势。
      • 2C
    • 产品形态角度
      • BS结构：
        • pc、h5
        • Browser-Server结构
      • CS结构：
        • 客户端
        • Client-Server结构
      • 软硬结合：
        • 智能家居，手环，物联网
        • 除了软件部分，还有硬件实体
      • 大实体：
        • 大型体系：汽车制造等产业链
        • 有软硬件更有服务
      • 一个APP功能形态选择——Native（Client模式）还是Web（Browser模式）更好呢？
        • ►偏交互的用Native，偏浏览的用Web：
          • 交互指复杂操作，包括输入、选择等，Web往往支持得不好。
        • ►已稳定的用Native，试错中的用Web：
          • H5页面适配各种手机系统、浏览器简单，用来做低成本验证很方便。而已经固化的功能，用Native更节省手机本地资源，使用起来更流畅，而且因为不依赖网络，也会更稳定。
        • ►访问硬件的用Native，信息展示的用Web：
          • 硬件包括手机里的各种传感器等，Native的访问权限更高，安全性也更高。
        • ►核心功能用Native，周边辅助用Web：
          • Native的工作量相对大，应该把时间多用在刀刃上。
        • ►变化少的用Native，经常变的用Web：
          • 比如电商的活动页面，经常需要变，做在Native应用里就会很被动。
      • 行业角度
        • 娱乐、金融、医疗健康、教育等
        • 行业之下分类
          • ►工具：
            • 音频播放器、音乐制作软件。
          • ►内容：
            • 歌曲库，以及早年的百度MP3。
          • ►社交：
            • 音乐讨论社区。
          • ►交易：
            • 版权市场，以及供个人付费购买高品质音乐的产品，如QQ音乐。
          • ►平台：
            • 阿里音乐（阿里总是倾向于做整个生态）。
          • ►游戏：
            • 节奏大师、太鼓达人等。
      • 盈利模式角度
        • 卖货：
          • 向前收费
          • 包月付费，点播费，会员付费功能等
          • 重点：货好
          • 直接像用户要钱
        • 卖人：
          • 向后收费
          • 广告发布、竞价排名、冠名赞助、企业会员等
          • 重点：人多
          • 2B的抽水模式，向企业单位或信息提供者收取费用
      • 关键资源角度
        • ►资本驱动 ，
          • 对应着需要大笔资金做准入门槛的产品。比如金融行业的某些业务，没有足够多的钱，根本没法进场。再如拼价格战，补贴大战时，资金不够多的公司也会被迅速淘汰。
        • ►技术驱动 ，
          • 意味着拥有核心技术能力，成为别人无法模仿的壁垒。比如Google的搜索引擎算法。如今的人工智能领域，谁拥有最牛的算法、海量的数据、强大的计算能力，谁就能取得领先。
        • ►产品体验 ，
          • 产品本身要好，对互联网行业来说，就是用户体验很爽。比如很多社交应用，有漂亮的界面、流畅的交互、快速的响应、丰富的内容，用户用过之后会触发口碑传播，一传十，十传百。我们常说的“消费升级”，也要求产品本身升级。
        • ►运营服务 ，
          • 对应着需要很多“人肉”参与的产品，强调运营效率、服务体验等。比如在O2O类产品的早期市场争夺战中，大家都很强调“地推”，就是靠人海战术迅速获取商户、用户资源的手段，谁的人不够多、执行力不够强、速度不够快，谁就会被淘汰。
        • ►垄断资源
          • ，取决于获取资源的能力。拥有一座矿山、一个油田、一片土地，或者是专属经营权等。比如只有12306可以卖火车票，某某公司成为谁的独家合作伙伴等。
      • 行业成熟度角度
        • 初创期
        • 爆发期
        • 平台期
        • 衰退期
• 第03 章 概念：提出与筛选／67
  • 3.1 产品概念的提出／69
    • 确定5个关键要素
    • 核心用户
      • 产品目标用户中最重要的用户是谁，表达为一个抽象的人群。
      • 举个例子，校园社交App，目标用户是在校生，核心用户就是一批校花。
      • “洗粉”：
        • 为讨好核心用户，而得罪其他不重要用户，即情愿选择让一部分人爱你爱得发疯，另一部分人恨你恨得要死，也不要让所有人都觉得你还OK。
    • 刚性需求
      • Ta们碰到最痛的痛点是什么。
      • 三个条件：真实、刚需、高频 。
        • 真实：
          • 辨别真伪
        • 刚需：
          • 强烈且不能忍受，例如停车—刚需是找到车位，弹性需求是省车费
        • 高频：
          • 发生频次
    • 典型场景：
      • 这些痛点最常出现在怎样的生活、工作情况下。
      • 典型：有没有“唤起点”
        • 唤起点：
          • 在某种情景下、某时某刻，用户能想到，最好是能第一个想到你的产品。这个时刻就是产品的唤起点 。
    • 产品概念：
      • 用什么方案解决，用一个词、最多一句话概括你的解决方案。
      • 举例：口碑网，大众点评
        • 产品概念：
          • 一个有餐厅列表、可以点评的网站。
    • 竞争优势：
      • 相对已有方案，有什么突出优势。
      • 人无我有/人有我优
      • 找到“竞争标的”
      • 竞品分析
        • 相似的产品→
          • 只能带来一些功能层面上的优化，不会对产品方向带来什么新思路 。
        • 能满足同样需求的不同产品（从表层到深层需求）→
        • 所有消耗用户时间的产品
          • 互联网/手机上的所有产品都是竞品，竞争的是用户仅有的那点 时间
  • 3.2 概念提出的综合案例／76
    • 智能长命锁/淘宝首页
    • 用户分类方法
      • 从目标用户中找到核心用户
      • 全集—子集—MECE
        • （相互独立，完全穷尽）
      • 角色划分：
        • 适用于多边，买卖供应商、司机乘客、提问者/回答者/吃瓜者等
      • 熟悉度划分：
        • 适用于单边，新人、中间用户、专家（新老用户）
      • 人口信息统计（年龄，职业，消费水平）：
        • 信用卡级别，k12教育级别等，慎用
      • 产品业务场景：
        • 企业级服务（按融资阶段）；培训（按行业）
  • 3.3 产品概念的筛选／82
    • 筛选要素
    • 【内部因素】能力
      • 人：
        • 团队是否与要做的事情匹配
      • 财：
        • 各种资本、资金的支持是不是到位
      • 物：
        • 行业资源与业务能力
    • 【内部因素】意愿
      • 使命感、愿景、价值观
      • 使命
        • 就是我们要解决一个什么问题，要做一件什么事情，比如“让天下没有难做的生意”；
      • 愿景
        • 是说我们希望成为什么，比如“让客户相会、工作和生活在阿里巴巴，并持续发展最少102年”；
      • 价值观
        • 就是我们认为什么是对的什么是错的。
    • 【外部因素】价值
      • 宏观：
        • 行业天花板
        • 潜在用户× 单用户可挖掘价值 = 行业天花板。
      • 微观：身边人你需要这个产品吗
        • 种子用户：
        • 1）愿意配合
        • 2）可以提供很多有价值的东西
        • 3）可以忍受缺陷
        • 4）可以成为义务推销员
        • 受你要解决的那个问题困扰最深的一小群人
      • 用户递进模型
        • 潜在用户：
          • 指向将来的想象空间与发展天花板（有闲暇时间可以代驾的司机，可以开顺风车的司机）；
        • 目标用户：
          • 指所有现在能跟产品发生关系的用户群体（专职司机+乘客）
        • 核心用户：
          • 指目标用户中最重要的那个群体（先搞定供给端：各城市出租车司机）
        • 种子用户：
          • 指核心用户中最早接触的那一小批用户，通常是一些具象的、我们认识的个体（嘀嘀打车：公司在机场摆摊时每天遇到的那几十个人）
    • 【外部因素】成本
      • 宏观：大环境
        • 有一个模板，叫作PESTEL
        • ►政治因素（Political）：
          • 是指对组织经营活动具有实际与潜在影响的政治力量和有关的政策、规定等因素。
        • ►经济因素（Economic）：
          • 是指组织外部的经济结构、产业布局、资源状况、经济发展水平以及未来的经济走势等。
        • ►社会因素（Social）：
          • 是指组织所在社会中成员的历史发展、文化传统、价值观念、教育水平以及风俗习惯等因素。
        • ►技术因素（Technological）：
          • 不仅仅包括那些引起革命性变化的发明，也包括与企业生产有关的新技术、新工艺、新材料的出现，以及发展趋势、应用前景。
        • ►环境因素（Environmental）：
          • 一个组织的活动、产品或服务中能与环境发生相互作用的要素。
        • ►法律因素（Legal）：
          • 组织外部的法律、法规、司法状况和公民法律意识所组成的综合系统。
      • 微观：行业环境
        • 波特五力模型
        • ►对于同行业内现有竞争者的能力，
          • 其主要指标为市场成熟度和竞争激烈程度。对于不成熟的早期市场，竞争对手少，但用户教育成本高，要避免做“帮后来者教育用户”的事情，而竞争激烈时期，可以考虑的策略是往行业上游走。比如，几年前团购流行时上演了“千团大战”，你就可以考虑做团购网站的导航、做团购商品的供应商。
        • ►潜在竞争者进入的能力，代表行业门槛高低。
          • 一些依托“黑科技”创业的领域，门槛相对高，而商业模式创新则门槛相对低。
        • ►替代品的替代能力，
          • 对于这点，我们要保持对变化的敏感，与其被别人干掉，不如自己先拥抱变化。
        • ►供应商的讨价还价能力，
          • 其实是一个店大欺客的问题。如果你的上游供应商过于集中，就很可能对你强势，设法分散是个解决方案。
        • ►购买者的讨价还价能力，
          • 其实是一个客大欺店的问题。如果你只有一个客户，可想而知，他提任何条件，你都只能答应，所以也是要设法分摊风险。
• 第04 章 需求：采集与用户研究／97
  • 4.1 需求采集方法的分类／99
    • 直接采集与间接采集
      • 直接采集：
        • 一手需求
        • 需求提出人是否是本人？
        • 是原始需求，还是加工过的？
        • 更加准确，但未经梳理，得出结论的效率低
      • 间接采集：
        • 二手需求
      • 全员参与采集，
        • 产品经理处理
    • 说与做，定性与定量
      • 说做不一致
      • 定量数据发现 7月用户活跃降低5%，定性抽取6月活跃，但7越不活跃用户做访谈
      • 是否在真实场景里
        • 很多情况，做产品时是无法模拟的，需要培养“临场感”—亲自置身场景
      • 是否和产品发生交互
        • 新功能：
          • 用户没用过，判断用户是否需要
          • 1）用户以为自己需要，结果有了并不用
          • 2）用户以为不需要，结果用了就离不开
          • 解决方法
            • 低成本验证
            • 免费试用：
              • 试吃，30天适用会员版，app核心功能h5化，不用下载也能用；
            • 类似需求，
              • 是否有别的产品和用户产生了互动，加以了解
        • 旧功能优化：
          • 用户用过，提出问题
    • 采集方法：
      • Z字采集法
      • 产品规划阶段：
        • 听用户“定性地说”，确定产品方向（做什么）；随机抽样了40个用户做访谈，据此写出需求列表。
      • 项目早期：
        • 听用户“定量地说”，确定需求优先级（先做什么）；投放了20万份调查问卷，确定了需求优先级的排序。当然，这只是确定优先级的辅助手段，最终做什么，还是由产品经理决定。
      • 项目实施过程：
        • 看用户“定性地做”，确定要先实现的那几个需求应该怎么做；设计的同时完成可用性测试，其间陆续找了10个用户来验证。
      • 上线后的优化阶段：
        • 看用户“定量地做”，根据产品的用户使用情况做数据分析，不断地改进产品。
  • 4.2 一些实用的采集方法／105
    • 客服轮岗
    • 用户批斗大会
    • 百度搜索词联想
  • 4.3 用户、需求的再理解／106
    • 需求的三种深度
      • ►第一种深度
        • 观点和行为
        • 表面能听到、能看到的东西，一般是通过用户怎么说、怎么做直接表现出来。如果只到这个层次，是做不好产品经理的。
      • ►第二种深度
        • 目标和动机
        • 用户为什么这么说、这么做？如果能找到目标和动机，会稍微好一些。但相对第三层，这里还是要实在一些。比如，用户说希望开始每天健身、跑步，目标是减肥。再往深层挖，其价值观层面的需求可能是为了在朋友面前呈现出积极向上、健康的自己。
      • ►第三种深度
        • 人性和价值观
        • 最底层的，最稳定的需求，人类社会诞生的千万年来，基本上没怎么变。如果能把需求挖掘到这个层次，就找到了产品最本质的用户价值。
    • 如何应对战略需要？
      • （内部需求）
      • 1）正面需求：
        • 毕竟提出者都是广义用户，需要考虑他们的需求
      • 2）判断主次
      • 3）分清手段和目的
        • KPI是实现战略目的，商业价值的一种手段
    • 用户：抽象到具象再到抽象
      • 第一阶段，用户是抽象群体
        • 在产品概念阶段，用户是假想的某一类人——目标用户、核心用户。（靠产品经验经历进行假设出来的）
      • 第二阶段，用户是具象个体
        • 1）根据具体角色，所处场景抽象出产品架构思维导图
        • 2）根据该思维导图创建【用户故事】（“易停车app”思维架构中中开车的上班族”（人物角色）在“工作日上班”（需求场景）下的一个“用户故事”）
        • 需求采集时，我们要去接触一个个真实的用户，见活人，听故事，找感觉，发现“用户故事”。
      • 第三阶段，用户又是抽象群体 ：
        • 【人物角色】—用户画像
        • 整理采集到的需求时，把真实用户再合并特征，定义出“【人物角色】，并反向修正产品概念。
  • 4.4 产品原则与初心／116
    • 产品原则
      • 是整个产品团队必须达成共识的准则，依赖于团队的价值观或者是产品的初心，相当于一个产品的宪法。
    • 制定产品原则的前提
      • 是一个产品做过需求采集且信息足够充分。
    • 产品原则几要素
      • ►目标用户分为哪几类，以及他们的优先级排序，整个团队必须达成共识。
      • ►产品的市场切入点，最关键的用户需求场景是哪几个，一开始的最小可行产品MVP必须满足哪些。
      • ►对一个社区而言，人和内容都很重要，到底哪个更重要？回答这个问题的共识是这个社区的产品原则。而且，往往对错都没有共识重要。有时候虽然是一条绕远的路，只要齐心协力说不定就走完了，就怕走走停停、不断争吵。
      • ►一个产品，应该追求用户数量还是质量，追求流水还是追求利润？这些都是产品原则里面需要包含的内容。
• 第05 章 转化：需求分析与Y 模型／123
  • 5.1 从问题到解决方案／125
    • 需求分析—将问题转换为解决方案
  • 5.2 Y 模型的基本概念／126
    • 基本模型
    • 核心价值观：
      • 用心听，但不要照着做
    • 发现更多用户目标：
      • 我们没法创造需求，只能创造出用户没见过的解决方案，从而更好地满足需求。
    • 抓住恒定人性：
      • 1，2会变，但4会持久不变，定位要站在4的高度上
    • 在成熟市场上寻找机会
      • 微信中的“飞机大战”
      • 单机—世界榜—好友榜（索要机会，邀请，赠送）
  • 5.3 实战中如何深入浅出／136
    • 深入：（1-2-4）如何挖掘人性
      • “攀梯术”：
        • 主要出现在一对一深度访谈的场合，用来探究用户对产品功能/特性的态度背后的原因，也就是说，在产品属性（Product Attribute，A）与个人价值（Value，V）之间产生有意义的关联，从而知晓影响用户决策的因素。
      • 基本手段：
        • 通过一系列直接的探询式问句来洞察人性。典型的提问形式是“为什么那个东西对你来说很重要 ”和“那个东西对你意味着什么 ”
      • 实操准备：
        • 访谈前向用户说明
        • ►回答没有对错，只需要表达自己的观点即可。
        • ►如果过程中觉得有一些问题无法回答，可以直接说出来。
      • 实操技巧
        • 情景唤起：
          • 通过让用户假想、回忆（使用产品的）情境，引起Ta的思考。
        • 假设某物或某状态的缺失：
          • 让用户思考，某物/状态如果缺失了会怎样。
        • 反面攀梯：
          • 用户无法说出做某事或想要某种感觉的原因时，可询问Ta不做某些事情或不想产生某种感觉的原因。
        • 时间倒流对比：
          • 让用户反思过去，并与现状对比。
        • 重定向：
          • 沉默或重述确认
          • 用沉默或通过再次询问确认的方式来鼓励用户继续讲。
    • 浅出：（4-2-3）如何设计功能
      • 借力于用户
        • “糗事百科” —“提交→（活跃用户）审核→（普通用户看到）最新→（用户点赞量）推荐”的内容审核机制;
      • 初期邀请注册
        • 保证产品内容质量
      • 向游戏学习
        • 徽章、等级制：过往
        • 经验、积分制：现在状态
        • 排行榜：未来努力方向
        • 等其他行业...
• 第06 章 功能：细化与打包／155
  • 6.1 一个功能的DNA／157
    • 功能描述列表
      • 性价比 = 商业价值/成本（开发量）
    • 商业价值判断
      • 对某个功能判断价值的流程
        • ►参照“产品原则”里“目标”部分的定义，明确当前产品最看重的指标是什么，可以是数字化的KPI，比如注册用户数达到10万，也可以是某些关键结果，比如“建立起线上自动化的专家入驻全流程”。如果有多个指标，则需要对这些指标加权合并[2] 。
        • ►考察每个功能点实现后，对上述指标的帮助大不大。如果大，则这个功能的价值就大。因为每个产品不同时期的指标不同，所以评判各个功能价值的标准也各有差异。通常用半定量的方式来衡量，比如最简单的大、中、小，或者5.4.3　、2、1等评分标准。
        • 广度：
          • 潜在用户：
            • 一个产品将来可能覆盖的用户群体；
          • 单用户价值：
            • 电商—客单价；游戏-APRPU；社交-用户活跃度度
          • 潜在用户数 *单用户价值（大力推广阶段重点）
        • 频度：
          • 先利用高频低单价的需求抓用户
          • 再用低频高单价的需求做利润
          • 需求频次 *单次复杂度（产品瓶颈期重点）
        • 强度：
          • 不可替代：
            • 早餐店卖包子——再做一个单品：馒头？豆浆——选择豆浆
          • 紧急：
            • 极个别的用户负面评论，但是引起大范围舆论；对手突然提高补贴力度等
          • 持久：
            • 3天活动？长期功能？
          • 不可替代、紧急、持久（早期发展重点）
    • 成本评估和性价比（初评）
      • 成本：人天
      • 性价比 = 商业价值/成本（开发量）
      • 理论，性价比高，优先级高，但是，还要考虑功能分类和实际情况
    • 功能分类：KANO模型
      • 第一类：基础功能
      • 第二类：亮点功能
        • 亮点是忠诚度、口碑传播的基础。
      • 第三类：期望功能
        • 选择原则：先做性价比高的
      • 第四类，无差别功能
        • 用户不用；
        • 为什么有这种功能：用来测试验证的，不做怎么知道用户不用
      • 第五类，反向功能
        • 用户不喜欢
        • 比如：百度广告—为了满足商业需要—用户不喜欢，但是企业/广告商喜欢
  • 6.2 功能打包，确定MVP／175
    • 如何确定MVP？
      • 尽可能多的放弃
      • 不同功能类型的应对对策
        • ►基础功能必做，要留足资源。
        • ►在产品初创期，先实现个别低成本的亮点。
        • ►对期望功能，先做性价比高的。
        • ►无差别功能无须做，低成本验证出来即可。
        • ►对反向功能，权衡各方利益后再决定。
      • 考虑功能依赖关系
      • 考虑功能相似性
      • 考虑非功能需求
    • 如何表达出MVP——产品架构图
      • 《人人都是产品经理》架构图
      • 当年天猫（淘宝商城）架构图
  • 6.3 把需求和功能管起来／185
    • 空间维度：功能列表
    • 时间维度：需求流程
• 第07 章 执行：立项组队与研发生产／191
  • 7.1 从“想清楚”到“做出来”／193
    • 原型验证与NPS
      • （POC—产品概念测试）
      • 产品立项前的验证：
        • 验证用户需求是否准切
      • NPS：
        • 净推荐值，是一种计量用户将会向其他人推荐某产品可能性的指数。
      • NPS =（推荐者数 – 批评者数）/总样本数×100%
        • ►推荐者：
          • 打分在9～10分之间，是具有狂热忠诚度的人，他们会继续使用产品并将其引荐给其他人，可以帮助产品成长。
        • ►被动者：
          • 打分在7～8分之间，总体满意但并不狂热，会用但不会传播，可能考虑其他竞争对手的产品。
        • ►批评者：
          • 打分在0～6分之间，使用后不满意，或者对你的产品没有忠诚度，可能有负面口碑，会阻碍产品成长。
        • NPS的得分值在50%以上就已经比较理想，如果达到70%～80%，则说明产品拥有一批忠实拥趸。
    • 产品委员会与关键节点
      • 产品委员会：
        • 手握资源人，在每个关键节点一起参与产品会议
      • 关键节点
        • 1）概念筛选
          • 根据各种背景信息，判断要不要对某个产品概念进行细化、展开。如果认为可行，就要启动全方位的需求采集工作。这是本书第03章讲的事情。
        • 2）立项组队
          • 对产品进行原型验证，评估需要投入多少研发生产资源，有多少风险及如何应对等。如果立项获批，就要启动项目、组队开干。这是本章前半部分的内容。
        • 3）上线发布
          • 产品完成开发后，千万不要因为怕浪费而仓促上线。这时还是要先用真实产品找种子用户验证，如果没有通过验证，就不要上线，以免浪费更多的客服、销售、运营维护资源。
        • 4）营销推广
          • 为提升用户量，上线之后马上就开始推广，也是常见的错误。应该先花一段时间考察用户是否活跃，是否会再次使用产品。当这些指标达到预期后，才可以大力推广，否则就是浪费资源。
  • 7.2 立项：搞定各种资源／196
    • 7.2.1 关于人：
      • 团队、组织
      • 权力：
        • 强力组织，比如国家政府，用“枪杆子”保证“绳之以法”。
      • 利益：
        • 商业组织，比如公司企业，用“钱袋子”支撑“诱之以利”。
      • 共识：
        • 松散组织，比如公益社团，用“笔杆子”达成“晓之以理、动之以情”。
    • 7.2.2 关于物：
      • 政策、资金等
      • 用MRD来获取资源
      • MRD：
        • Why：为什么要做这个产品
        • What：产品MVP包含哪些功能及要做什么—demo
        • How：项目计划及风险对策等
        • Market Requirements Document，市场需求文档，除了描述问题，解释为什么要做这个产品，还要给出解决方案。这个文档比较像产品规划和商业计划书（BP，Business Plan），是写给资源拥有方看的。
      • PRD：
        • Product Requirements Document，产品需求文档，是在项目过程中写给开发、测试、设计师看的，仔细描述产品功能要怎么做。
  • 7.3 组队：聊聊初创团队／199
    • 7.3.1如何快速知己知彼
      • ► 为什么要来这个团队？
      • ► 对一年后收获的底线预期。
      • ► 个人对团队的帮助。
      • ► 自己能做什么？
      • ► 自己想做什么？
      • ► 项目失败最可能的原因是什么？
      • 上面这些话题看上去有些虚，但对提升早期核心团队的战斗力非常关键，问题的具体答案是什么其实不重要，重要的是共同参与。
    • 7.3.2 小团队的沟通协作
      • “奥卡姆剃刀”原理
        • 该原理称“如无必要，勿增实体”，即“简单有效原理”。
      • 能解决需求的最简单方法
        • 适合的才是最好的
    • 7.3.3 小团队与大公司的区别
    • 7.3.4 借助第三方力量做产品
      • 众包：分享、座谈、咨询、外包
  • 7.4 研发生产时，我们做什么／206
    • 产品经理视角的项目流程
      • ►立项环节：
        • 在这个环节，产品经理要组建团队、设法获取各种资源，以及确定项目计划。
      • ►需求环节：
        • 这个环节主要做的是功能细化，也可以叫需求开发。产品经理要写PRD产品需求文档和UC用例，并和设计师配合做Demo原型。在这个过程中，可能会经历多次评审会议，还要和技术人员一起确定功能细节。
      • ►开发环节：
        • 同时，产品经理已经开始下一个迭代版本的项目前期准备。
      • ►测试环节：
        • 开发推进的同时，测试工程师要编写TC测试用例，通过TC评审，并且在系统可用的第一时间做冒烟测试[7] 。此环节中，产品经理要组织功能评审，在第一时间把新产品展示给所有的项目干系人，以确保做出来的东西是大家想要的。
      • ►发布环节：
        • 测试工作完成后，运维人员要组织发布评审，执行预发布、发布的动作，并且在发布完成后让产品经理到真实的线上环境去验证，以确保产品符合预期。
      • 额外三件事的把控
        • 文档管理：
          • 输入/输出文档，模版，工具，如何让同步更新
        • 流程管理：
          • 每个流程的评审是否可删减，高效
        • 敏捷方法：
          • 日常沟通方法，监控进度
    • 7.4.1 产品经理要不要懂技术
      • 测试
        • 功能测试
          • 单元测试：
            • 最小单元代码自测—开发
          • 冒烟测试：
            • 基本功能测试—测试
          • 回归测试：
            • 修改旧代码后，对相关功能重新测试以确保没有新错误引入
        • 性能测试
        • 压力测试
        • 验收测试：产品经理
• 第08 章 成长：规划与迭代／219
  • 8.1 好产品步步为营／221
  • 8.2 规划：只看最短和最长／223
    • 最短：
      • 1-3月/最长：3-5年，10年后
    • 产品规划
    • 业务规划
      • ► 一句话的业务定位：
        • 这句话通常也会表现为产品的Slogan，比如小红书的“全世界的好东西”、微信的“一个生活方式”，以及陌陌的“总有新奇在身边”。
      • ►一个业务模型：
        • 包括这个业务内部分为哪些模块，彼此之间有什么关系，与产业链中的各个角色怎么配合，如何平衡各方的利益，自己如何赚钱等。
      • ►三五个业务关键点：
        • 接下来的一段时间，主攻的几个业务难点是什么。比如“入驻平台的卖家数在1个月内达到1.0.0　”“3个月内把服务扩展到所有省会城市”或“半年内谈妥ABC几个战略合作伙伴”。
    • 8.2.1 从规划向上看战略
      • 长期规划=战略
    • 8.2.2 通过提问把别人干翻
      • 在大公司争取资源
        • 1. 每次对方讲完PPT。
          • 为什么要做这件事，不做的话会“死人”吗？
        • 2. 看到对方从总体KPI分解出的目标。
          • 这是用户的目标还是我们的目标，是不是老板的目标，老板换了怎么办？
        • 3. 看到对方从用户需求出发，引用了一个观点。
          • 这个用户有普遍性吗，能代表多少人，这类用户对我们的优先级是什么？
        • 4. 看到对方引用一个数据来证明自己的观点。
          • 数据来源是什么，什么时候获取的，是怎么采样的？
        • 5. 看到对方的规划写得太实在，都是项目方案。
          • 为什么没有看到这个产品线的大图，5年后这个产品是什么样子，你实现整个图景的路径是什么？
        • 6. 看到对方写得太虚，都是画大饼。
          • 未来的确很美好，但怎么实现？现在如果只做一件事，最重要的是什么？你打算怎么做？
        • 7. 看到一个运营方案需要资金预算。
          • 你能给出量化指标吗，ROI是多少，这笔钱真的能用在最看重的用户身上吗，会不会被不投钱就已经很活跃的用户花掉？
        • 8. 看到要做的事情太多。
          • 这么多事情，你打算组建多少人的团队，他们都需要什么能力，怎么分工？如果只给你两个人，怎么办？
        • 9. 看到要做的东西真的很吸引人。
          • 实现路上会碰到的最大问题是什么，你打算怎么解决？需要大家怎么配合你，你打算如何说服各个部门都来帮你？
        • 10. 看到具体的项目。
          • 你这些项目需要占用的开发资源有多少，如何给技术同学带来成长和成就感？
    • 8.2.3 提升规划能力的实践
      • ►让产品团队每个人做一份自己产品的规划，规划周期可以限定为3个月。重点是每个月要拿出1天时间，每个人轮流宣讲，听众是团队其他人。
      • ►每个人讲完以后，听众轮流说一点“好”与一点“可以更好”（其实就是“不好”的委婉说法），不许重复。可以针对规划本身，也可以针对PPT制作、演讲技巧等。
      • ►主讲人自己在白板上记录大家的发言，等所有人发言完毕后统一进行回复和讨论，会后优化产品规划PPT以供下次讨论。
      • 一般半天时间（4小时计）可以讨论3个人的规划，假设是一个6个人的团队，一天时间正好全部讨论完。最终每份规划可以得到5点“好”与5点“可以更好”，全组就能得到30点“好”与30点“可以更好”。相信3到6个月下来，每个人的产品规划、PPT演示能力都会有显著的提升。
  • 8.3 迭代：再理解敏捷／230
    • 8.3.1 敏捷价值观、宣言与原则
      • 敏捷的5个价值观：
        • 沟通、简单、反馈、勇气、谦逊
      • 敏捷宣言：
        • （目标结果为导向）
        • 一、人与人的交互，重于过程和工具。
        • 二、可用的软件，重于详细的文档。
        • 三、与客户协作，重于合同谈判。
        • 四、随时应对变化，重于循规蹈矩。
      • 敏捷12条原则：
        • 一、对于我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
        • 二、拥抱变化，欢迎需求的变化，即使在开发后期。
        • 三、敏捷过程能够驾驭变化，保持客户的竞争优势。
        • 四、经常交付可以工作的软件，从几个星期到几个月，时间尺度越短越好。
        • 五、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
        • 六、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
        • 七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
        • 八、可以工作的软件是进度的主要度量标准[4] 。
        • 九、敏捷过程提倡可持续开发。
        • 十、对卓越技术与良好设计的不断追求将有助于提高敏捷性。
        • 十一、简单——尽可能减少工作量的艺术至关重要，最好的架构、需求和设计都源自自我组织的团队。
        • 十二、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
    • 8.3.2 敏捷项目管理的实践
      • Scrum关键概念的理解。
        • ►团队角色
          • PO（Product Owner）
            • 通常是产品经理，要对各种利益相关方负责。
          • SM（Scrum Master）
            • 充当教练的角色，一般由对流程、方法论比较熟悉的人来担任，不建议这个角色和PO重叠。
        • ►关键产出物
          • Product Backlog
            • 指比较长期的产品任务表，即第06章提到的功能列表。
          • Sprint Backlog
            • 在Scrum里指当前这个迭代里面的任务点。
          • Burndown Chart
            • 是燃尽图，用来监控任务是不是在按期推进。
        • ►重要的会议
          • 首先是每个迭代的计划会 ，
            • 经常和需求评审会 合并，主要目的是明确任务，以及评审这个迭代里需要做的功能。
          • 每天的站立会议 ，
            • 是重要的信息同步手段。
          • 功能评审会
            • 用来评估做出来的东西是不是想要的。
          • 回顾会
            • 目的是为了过程改进，因为Scrum和敏捷最核心的思想就是不断优化，以优化出一个最适合当前团队的方法论。
        • ►日常管理工具
          • 看板
            • 是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。比如，有一块写着当前迭代关键信息的白板，或者有一面用来粘贴任务卡片和便利贴的玻璃墙，如图8-2所示。
      • 实例：创业公司的简化项目流程
        • 角色的简化
        • 流程的简化
          • ►立项会议：
            • 确定项目目的——为什么、做什么（时间控制在半小时以内）。
          • ►需求评审：
            • 确定项目怎么做（对相对较小的项目，可以和立项会议合并，总体时间控制在2小时以内）。
          • ►功能评审：
            • 简单地讲，就是在测试环境下演示一下产品，以确定做出来的是不是团队要的（1小时左右搞定）。
          • ►发布上线：
            • 确定产品是不是用户想要的，以及用户还要什么。通过获取用户反馈来让产品的优化形成一个螺旋上升的闭环。
          • ►需求变更 ：
            • 这在项目过程中不可避免，一开始可以简化成某个人拍板，决定是否接受变更。
          • ►日常需求：
            • 即零散、随机出现的小需求。开始只掌握一点，即所有需求必须经过产品经理，运营等角色不能直接找开发，确保产品经理知道所有的需求信息，以便统筹安排。
        • 文档的简化：
          • PRD+设计稿+代码
        • 看板实践
        • 任务卡片
          • 任务描述
          • 工作评估
          • deadline
          • 优先级
          • ►左上角标：
            • 表示此卡片的任务延期。少量的任务延期是正常的，也是允许的，但要进行监控。如果发现项目里有很多人出现大幅延期，则说明计划制订不合理，需要及时调整；如果只是个别人出现大幅延期，则更可能是个人问题，需要延期人自己加班赶上进度。团队要达成共识，让别人等、浪费别人时间是可耻的。
          • ►右上角标：
            • 表示突发任务。少量的突发任务也是正常且允许的，但如果有大量突发任务，则说明缺乏经验、计划不足，或者有“外力”经常干扰项目进程。
          • ►左下角标：
            • 表示持续任务，可以一直贴在看板的Doing（正在做的）任务列表里。比如，对产品经理来说，“处理用户反馈”就算一个持续任务。而非持续任务都应该从看板的Doing列表及早转移到Done（已完成的）任务列表。
          • ►右下角标：
            • 未定义的备用标记。团队在做项目的同时会不断优化项目流程，如有需要可以临时定义这个新的角标。
        • 看板应用
          • 其横坐标是Todo（未开始的任务列表）、Doing和Done，纵坐标是各种团队角色。当时，团队每天下班前，也就是18:00开站立会议，大约持续15分钟，会上每个人只说三句话。第一句“今天做了什么”，说某个任务的同时指着看板上对应的任务卡片，如果任务完成，则把卡片从Doing一列拿到Done一列，如果延期了就涂上左上角标；第二句“明天打算做什么”，同时指着Todo一列的相应任务卡片，并把它拿到Doing一列；第三句“碰到什么困难、需要什么帮助”，与大家一起讨论，但不展开，具体的细节可以约着会后私聊。
• 第09 章 运营：先验证再扩张／249
  • 9.1 产品与运营的关系／251
    • 9.1.3 给运营提需求的模板
  • 9.2 运营工作的分类／256
  • 9.3 大运营的其他职责／268
  • 9.4 产品的生命周期／272
• 第10 章 案例：商业模式、创新与行业／277
  • 10.1 聊聊商业模式／279
    • 商业模式画布
      • ►客户细分：
        • 我们的目标用户是谁，其中最重要的又是谁。
      • ►价值主张：
        • 我们可以帮用户创造什么额外的价值。这里所说的价值必须是现有产品服务没有的，比如更高的性能、更低的价格、更小的风险。
      • ►客户关系：
        • 用户与我们、用户与用户之间的互动模式是什么，比如专人一对一服务、用户自助使用、用户彼此共建社区，等等。
      • ►渠道通路：
        • 如何与用户建立起高效联系，拉近现实与心理的距离。
      • ►关键业务：
        • 我们需要做什么产品来解决用户问题，创造价值。
      • ►核心资源：
        • 我们做这件事，和别人相比，有什么特别的优势因素。
      • ►重要合作：
        • 我们需要和哪些上下游、周边伙伴协作，以及如何协作。
      • ►收入来源：
        • 如何从用户那里获得收入，以维持业务可持续发展。
      • ►成本结构：
        • 做这件事，都在哪些环节需要花钱。
    • 10.1.1 对比：商业、业务、盈利模式
      • ►商业模式：
        • 完整讲述了我们创造了什么价值，为什么有存在的意义，对应图10-1的全部。
      • ►业务模式：
        • 在解决方案层面做的是什么事，对应图10-1左上区域的关键业务、核心资源、重要合作。
      • ►盈利模式：
        • 怎么赚钱，怎么养活自己的团队，对应图10-1下方区域的成本结构与收入来源[1] 。
  • 10.2 创新那点事儿／284
  • 10.3 行业案例分析／294