《从点子到产品》读书笔记

引言

其实在写这本书的读书笔记前我应该先写吴军老师的名作《浪潮之巅》的笔记，我开始读产品、设计、运营和商业思维这一类的书的想法也是起源于这本书，但是这本书阅读时间跨度太长，只能等下次阅读的时候补上了。

《浪潮之巅》书内多次提到硅谷的工程师文化，并将工程师进行了级别的划分：

• 第五等工程师：能够独立设计和实现某一项功能的人
• 第四等工程师：具有产品设计的基本知识和领导才能，领导产品的基本实现
• 等三等工程师：能够做行业内最好的产品，和第四等工程师等差距不仅反映在技术水平，对市场的了解，对用户心理的了解等诸方面，而且反映在悟性的差别
• 第二等工程师：是那些可以给世界带来惊喜的人
• 第一等工程师：是可以开创一个全新行业的人

所以我感觉之前一直学技术其实是把路走窄了，代码是服务于商业模式的工具，如果想成为更好的工程师，写出更加有效合理的代码，我认为我们需要去学习产品、设计、运营和商业理念等各个方面的书籍，在一些论坛的推荐下，我决定先从这本书开始读起。

基本信息

• 推荐指数：🌟🌟🌟🌟🌟

• 作者：刘飞

• 类型：产品

• 阅读日期

  • 开始日期：2024/4/27

  • 终止日期：2021/5/6

内容简介

“本书以产品经理的方法论与价值观为主线，讲述了产品经理在从点子到产品的过程中应该考虑的问题、思考问题的思路，以及如何解决问题的方法。第一部分主要讲述从粗略的点子到具体的方案，要经历的步骤。第二部分主要讲述如何落实方案，以及如何进行用户研究、需求分析和产品设计。第三部分主要讲述在落实方案的过程中要掌握的方法和管理技巧。最后一部分主要讲述产品经理在工作和成长过程中要考虑的一些问题。”

内容分析

第一部分 - 产品价值和用户痛点

第 1 章-点子与方案

• 产品模型：设计合理性

  • 用户是不是有需求

• 能不能满足用户需求

  • 

• 检验矩阵

  • 最底层看要判断市场、需求，以及用户是否真正存在。

    • 市场的存在

    • 需求的存在

    • 用户的存在

    • 需求满足的逻辑是否合理。

      • 提供的可能

      • 发⽣的场景

      • 接受的意愿

  • 要看产品模型创造的价值是否是正⾯的

    • 效率
      • 成本
    • 体验

• 商业模式：盈利合理性

  • 常见模式

    • 广告—— 流量可观的

    • 售卖——有⾼质量⽤户

    • 增值服务——有数据或者渠道价值

    • 佣⾦/抽成

    • 企业服务

  • 九个构件

    • 客户细分

    • 价值主张

    • 渠道通路

    • 客户关系

    • 收入来源

    • 核心资源

    • 关键业务

    • 重要合作

    • 成本结构

• 环境：拓展合理性

  • 需求的轻重

  • 延展性

    • 想要进⼊的市场的状况

      • 市场竞争环境

      • 相关的技术

      • 相关的政策

    • 面向的用户如何

      • 结构，特征

      • 会发生什么变化

      • 对于不同年龄、不同领域、不同国家地区的⽤户，有没有拓展性

    • 产品逻辑的拓展性

      • 实现的产品方案是单⼀的，还是多样的

      • 可以做的事情够不够多

      • 是基于它们还能开展更多服务、实现更多功能

      • 可挖掘的需求是否还有更多

      • 对于当前的垂直领域，可不可以扩展到相近的领域

      • 如果扩展到这个领域，产品逻辑上可复用的部分是不是足够多

    • 商业模型的拓展性

      • 赚钱的方式有⼀种，还是多种

      • 商业模式的逻辑都成立吗

      • 对于⽬前的用户，使他们成为付费用户或者说产生商业价值的可能性会因为某些因素发生变化吗

• 团队：实施合理性

  • 清楚团队资源的状况——分析可以做哪些产品和功能

  • 为什么是你们做

    • 你们有能力做出这个方案吗

    • 你们比其他⼈做有足够的优势吗

第 2 章-找到产品核心价值

• 用户体验要素

  • 战略层

  • 范围层

  • 结构层

  • 框架层

  • 表现层

• 为什么要找出核心价值

  • 发现核心价值，能够选择综合考量下来最优的功能。

  • 基于相同的核⼼价值设计的功能，逻辑统一。

  • 有单⼀的核⼼价值能够让用户对产品产生认知。

• 核心价值的定义

  • 离开了它，产品就不能真正解决用户的实际问题。

• “解决问题”是产品价值所在

  • “好的产品是用完即走的

    • 从根本上产品是在为用户做什么

    • 要增强用户黏性、提高用户使用频率、提高用户的活跃度

      • 注意不是黏住用户

    • 要避开“黑魔法”

  • 确保产品真正解决问题

    • 没有真正解决问题的情况

      • 方法看似可以，但实际上很糟糕

      • 方法看似可以，但可行性差

      • 方法看似可行，但问题却并不需要解决

  • 用超预期的方式解决

    • 超预期不仅仅是在于比原来好，而是“好”的程度能够抵消掉转移产品带来的成本。我们把超预期给用户带来的愉悦感和实际的好处（成本更低、效率更高等）记作 X，把用户转移产品的心理成本（对新产品的陌生感，以及尚未建立的信任感）记作 Y1，把用户转移产品的实际成本（比如新产品注册花费的时间、转移资料花费的时间，以及像会员积分这样的实际损失）记作 Y2。那必须保证 X>Y1 ＋ Y2，这样的产品才能让用户满意。

第 3 章-MVP 与痛点

• MVP（Minimum Viable Product，最小可用产品）

• ⽬的

  • 产品满足了用户需求

  • 产品能够创造商业价值

• 越是早期的产品（或者某个成熟产品中的新模块），越需要做得更关注产品的核心功能，实现产品的核心价值

  • 第⼀，产品模型的合理不能确保功能也会受到用户认可，快速投⼊到市场中进⾏验证是最妥当的方法

  • 第⼆，产品的核心功能就可以解决用户问题

• PMF（Product/Market Fit），也就是产品和市场的匹配点。

  • PMF 理论认为，产品的增长曲线会在找到契合的这个点之后，快速增长。在这之前，⼀直是在较低范围的波动状态

• 设计 MVP

  • 达到可用与最小成本的平衡。

  • 奥卡姆剃刀法

    • “如无必要，勿增实体”

  • 用户访谈

  • 去掉可人工处理的功能

  • 确保只有⼀个功能

    • 好的产品是⼀句话能讲清楚的

• MVP 方法

  • 广告

  • 假 MVP

  • 线下实现

  • 众筹

• 实现 MVP

  • 选择平台 —— 微信公众号（开发成本和传播成本低）

  • 选择技术实现方案

  • 关于外包 —— 慎重

• 找出痛点

  • 通过分析数据发现痛点

    • 用户数据

      • 使用频次

      • 日活跃用户、周活跃用户和月活跃用户

      • 用户留存

    • 商业数据

      • 付费转化率

      • LTV/CAC>3，即用户终生价值/用户获取成本>3

    • 要根据不同的产品，选择观察的数据

  • 通过用户反馈发现痛点

    • 用户在线反馈

      • 在产品上增加比较醒目的反馈入口

      • 除了官方渠道之外，要多观察哪⾥可能会有人讨论自己的产品。

    • 定向访谈

      • 数据是乐观的，那就聊用户喜欢的点

      • 数据是不乐观的，可以问用户现在不爱用的原因

• MVP 不是不做产品模型的借口

第二部分 - 需求分析和功能设计

第 4 章-深挖需求

• 基于场景深挖需求

  • 面向人物、环境和时间

  • 检验解决方案

  • 用数据和实例支撑

• 从人性本质深挖需求

  • 逐利心理

  • 两性吸引力

  • 懒惰

  • 虚荣心

  • 共情需要 —— 即我们希望体会他人的生活和感受的需求。

  • 社交货币

  • 安全感

第 5 章 - 用户研究

• 获取的方法

  • 用户的行为、状态

  • 用户表达的观点和思想

• 情报本身的特征

  • 定性

  • 定量

• 在做调研之前，要先判断自己要了解用户的什么，哪种方式是最好的，选择最正确的方法后再去做

• 问卷调查

  • 确保问卷能够达到目的

  • 问卷问题的设计合理

    • 切忌问题具有引导性

    • 切忌问题中有含糊不清的内容

    • 对于涉及敏感话题的问题要特别注意 —— 可以考虑转移主体

    • 尽量少用问答题

    • 选择题的选项确保可靠

    • 切忌问题过多

    • 重要的问题可以交叉验证

  • 样本的把控

    • 发放渠道的合理性

    • 在问卷中确认填写者的必要信息

• 用户访谈

  • 确认访谈的目的

  • 访谈的过程

  • 样本的把控

• 可用性测试

  • 在时间上来说，可用性测试应当是在最简易的可用版本实现后、正式版本上线前，有可以修整的余地

  • 从内容上说，可用性测试关注的是用户对产品的整体使用过程中出现的各种问题

  • 从环境上来说，尽量从轻松、日常的环境中完成

• 数据分析

  • 启动次数

  • 启动时间及持续时长

  • 事件完成情况

  • 使用出错情况

  • 用户活跃情况

  • 用户属性

    • A/B 测试

  • 实地考察

• 用户研究的结论

  • 定性的结论输出的⼀般是有价值的观点

  • 定量的结论输出的则是对数据的分析结果，重点在于怎样客观合理地统计和展现数据

    • 在数据统计中会有⼀些陷阱，例如用户点击率低未必是功能做得差，有可能是许多小屏手机看不到那个按钮导致的。

第 6 章 - 用户体验

• 人们对于针对使用或期望使用的产品、系统或者服务的认知印象和回应

• 蜂窝模型

  • 有用性。面对的用户需求是真实的。

  • 可用性。功能可以很好地满足用户需求。

  • 满意度。涉及情感设计的方面，比如图形、品牌和形象等。

  • 可找到。用户能找到他们需求的东西。

  • 可获得。用户能够方便地完成操作，达到目的。

  • 可靠性。让用户产生信任。

  • 价值。产品要为投资人产生价值。

• 《点石成金》

  • 有用性：能否帮助人们完成⼀些必需的事务？

  • 可学习：⼈们能否明白如何使用它？

  • 可记忆：⼈们每次使用的时候，是否都需要重新学习？

  • 有效：它们能完成任务吗？

  • 高效：它们是否只需花费适当的时间和努力就能完成任务？

  • 合乎期望：是⼈们想要的吗？

• 《用户设计体验》

  • 有效性：实际可以等同于可用性或者有用性，就是这个产品能不能起到作用。

  • 效率：产品应该是能提高使用者的效率的。

  • 易学习：学习成本低。

  • 容错：防止用户犯错，以及修复错误的能力。

  • 吸引力：从交互和视觉上让用户舒适并乐意使用。

• “尼尔森十大可用性原则”

  • 可见原则 —— 保证界面的内容可见、状态可见、变化可见

  • 场景贴切原则 —— 让功能操作符合用户的使用场景

  • 可控原则 —— 用户要能对当前的情况很好地了解和掌控，足够自由

  • ⼀致性 —— 用户需要在同⼀个产品中接受同⼀套规范或者逻辑

  • 防错、防呆原则 —— 要尽量用足够的提醒和设计，让用户不要混淆、犯错和发呆

  • 协助用户记忆原则 —— 在需要记忆某些信息时，产品功能要帮助用户记忆

  • 简约易读原则 —— 界面足够简单、内容易读

  • 容错原则 —— 向用户提醒犯错的可能，并提供给用户挽回错误的方法

    • 帮助和提示 —— 在任何时候，考虑到用户需要得到帮助的情况并予以提示

  • 灵活高效原则 —— 用户在使用时，要方便、高效地完成任务

  • 恢复现场原则 —— 适应用户的碎片化使用习惯，在各种切换和退出返回时要能有恢复现场的能力

• 关于文案

  • 不要用太过文艺的语言，尤其是在给重要功能起名时

  • 能简则简，字数减到最少

  • 反复斟酌，不要有歧义

  • 找到产品的试用者

第三部分 - 产品管理

第 7 章 - 文档管理

• 产品经理要不要懂技术？

  • 任何产品工作中接触到的技术都应该算作产品经理“有可能”需要了解和学习的技术

  • 产品经理⼀定要懂技术，具体懂到什么程度要看“需要”。

• 好的文档到底是什么样的？

  • 能够减少甚至免除在开发过程中技术⼈员跟产品经理沟通的文档就是好的文档

  • 没有逻辑硬伤

  • 没有疏漏

  • 逻辑清晰

  • 可读性强

• ⽂档逻辑

  • 功能框架的逻辑

    • 拆分 —— 把产品的功能（或者预期有的功能）枚举出来，拆分成相对独立的模块

    • 组合 —— 把刚才拆分的产品功能予以组合

  • 业务流程的逻辑

    • 面向事件

      • 面向事件指的是，要完成⼀件事可能会进行很多次操作。而在这些步骤中要整理出健全的流程，逻辑清楚且不存在缺漏。

    • 面向对象

      • 面向对象，指的是对象的生命周期代表着一次完整的功能使用

  • 功能描述的逻辑

    • 完整 —— 尽量枚举所有的情况，并且分情况详述功能内容

    • 考虑到所有影响点 —— 对任何改动，即使再小都可能牵扯到其他的地方

    • 条件判断清晰

    • 含义明确

    • 叙述背景

第 8 章 - 需求管理

• 获取需求阶段

  • 第⼀，判断需求本⾝的重要性

  • 第⼆，考虑需求来源

  • 第三，了解需求背景

  • 没说清楚原因的需求，不记

  • 不说清逻辑的需求，不记

  • 不是实际遇到的需求，不记

• 讨论和设计阶段

  • 需求的优先级

    • 四象限法则

      • 我们要把紧急且重要的需求排在最前，不紧急但重要的需求其次，紧急不重要的需求再次，最后是不紧急不重要的需求。

      • ⽽在判断是否重要时，可以参考这样的排序（重要程度由强到弱）：

        • 不做，会造成严重的问题和恶劣的影响

        • 做了，会产生巨⼤好处和极佳效果

        • 跟核心用户利益有关跟⼤部分用户权益有关

        • 跟效率或成本有关

        • 跟用户体验有关

      • 判断是否紧急，可以参考以下排序（紧急程度由强到弱）：

        • 不做，错误会持续发生并造成严重影响

        • 在⼀定时间内可控但长期会有糟糕的影响

        • 做了，立刻能解决很多问题、产生正面的影响

        • 做了，在⼀段时间后可以有良好的效果

    • KANO 模型

      • 作为⼀个需求对应的功能，“行”描述的是“如果有的话”，用户会“开心”、“无所谓”还是“不开心”；“列”描述的是“如果没有的话”的情况。
      • 

  • 方案的草稿

  • 指定负责人

    • 每个⼈负责的需求范围要有清晰的边界，需求对应哪个模块直接分配即可

    • 团队作战，每次指定或者认领，谁都有可能接手任意需求。

  • 划定时间节点

• 待开发阶段

  • 可行性评审

    • 方案本⾝的可行性

    • 有没有更好的方案

    • 涉及的产品和技术环节有哪些

    • 方案的成本如何

• 开发阶段

  • 开发需求的次序，未必完全按照需求池⾥的需求优先级进⾏，接下来就是拿成本结合需求的优先级得出该需求的性价比。
  • 开发中，“扯⽪”的问题归纳起来有三种：
    • 需求太多，没按时做完
    • 需求有改动，导致了额外工作量，引起开发人员的不满
    • 有新的紧急需求，导致发布延期
  • 导致出现这三种问题的原因
    • 产品方案不完整
    • 需求方的主观改动
    • 无法预测的客观原因

• 复盘阶段

第 9 章 - 工作流中的管理

• 实现一个目的有很多方法，但往往会选择最容易想到的而不是最好的方法。
• 协作管理
  • 与技术⼈员的常规协作
    • 确保产品经理对产品的要求传递给了技术人员；
    • 确保技术部门的意见得到了表达；第三，双方对共同认可的内容予以确认
  • 与技术人员协作的临时状况
    • 首先要安抚
    • 其次，再去解释原委
  • 与需求来源方的协作
    • 要在需求管理的重要节点，跟需求来源方同步信息
    • 如果是客观原因导致的完成情况有问题、有延期，也要跟需求方的同事有理有据地解释清楚
• 双赢心态
• 开会
  • 说清楚会议的主题和内容，以及大家需要提前准备的阅读材料
  • 开会时最重要的是讲规则
    • 针对拟定的主题讨论，其他无关议题禁止讨论或者加会再讨论。
    • 讲求发言顺序，不能争抢和吵闹，最好有主持人。
    • 禁止人身攻击，避免太情绪化的讨论。
    • 会议要对原定的主题输出结论，如果没有结论，要制定解决方案（比如由于信息不全面无法决定，要设立日期再议）
• 记录
  • 文档
  • 会议记录
  • 想法和思路
  • 其他事项
• 流程管理
  • 不要重复造轮子
    • 让协作标准化和流程化。
      • 所有需求必须通过邮件提出
      • 业务方的需求提出者是固定的接口人
      • 产品这边接收方也设立固定的接口人
      • 需求的状态每周固定时间发布
      • 有延期的需求，发送邮件给相关需求方，告知原委
    • 减少手工劳动
      • 学会发掘能够替代手⼯劳动的⼯具
      • 学习⼀些好用的脚本代码
    • 让一些工作可复用
    • 避免重复犯错
      • 找出犯错原因
        • 犯错是由于疏漏所致
          • 对于某些遗漏的环节，可能需要通过制度或者流程机制来解决
          • 逻辑不健全
        • 犯错是由于信息不全面、知识不完备所致，并不是意识不到，而是根本不知道这个问题的存在
        • 犯错是由于没有责任心所致
        • 犯错是由于能力无法胜任所致
• 个⼈管理
  • 任务管理
    • 把表现出来的焦急当成任务的紧急程度
    • 把充实感当成完成任务
    • 眼光不够长远，只做半衰期短的事情
    • 不设截止日期
    • 不检视效果
  • 知识管理
  • 团队管理
    • 专业技能服众
    • 管理技能

第四部分 - 技巧和方法

第 10 章 - 处理问题

• 发现问题
  • 要有主动发现问题的意识
  • 这种潜在的问题，产品经理要发掘出来并且把它们定义清楚
  • 什么是问题
    • 有跟我们的预期不符的状况，那就是我们需要解决的问题
      • 在⼯作中对任务要有预期
      • 敏锐地察觉到与想象不符的状况
      • 不应关心没有预期或与预期差别不大的状况
      • 问题是合情合理的吗
      • 问题是真实存在的吗
  • 把问题描述清楚
    • 考虑问题的背景
    • 考虑问题涉及的人
    • 考虑解决问题的期望
  • 发现问题的主动性
    • 去发现问题出在哪⾥，尝试解决，或者协助别⼈解决
• 分析问题
  • 抽象问题 —— 把复杂的问题抽象出容易理解、方便解决的本质
  • 逻辑分析的常见问题
    • 混淆因果关系和相关性
    • 概念有歧义或者偷换概念
    • 逻辑关系混乱、不熟悉归纳演绎
    • 假设错误
    • 轻易断言
    • 太过主观臆断
    • 片面归纳
    • 比喻过度
    • 被统计数据欺骗
• 解决问题
  • 拆分问题 —— 按层次、步骤、逻辑拆分成一个个小的问题
  • 解决方案
    • 问题和背景
    • 方案的内容
    • 方案的负责人
    • 方案的目标和验证方法
  • 推动执行
    • 确保对方获取到所有的信息
    • 了解对方的态度
    • 定期关注
    • 解决后检验效果

第 11 章 - 沟通

• 能够快速、准确地理解别人表达的信息。
• 能够准确、通畅地表述自己想传递的信息。
• 在理解和表达中就事论事，也能照顾大家的情绪。
• 理解
  • 找到重点
  • 用复述来确认
  • 区别事实和观点
  • 关注诉求
• 表达
  • 表达重点
  • 确保对方理解
  • 用更形象的方式 —— 图形化对表达
• 沟通的心态
  • 把批评当成信息
  • 不要过度解读
  • 不纠结对错，不关心输赢

第12 章 - 成长

• 好项目＋好导师
• 博采众长
• 素养
• 审美
• 善意
• 有趣
• 招聘
  • 问题决定了回答方式
  • 要通过他说的内容，敏锐地察觉其中哪些是真实的、哪些是虚假的，以及哪些是有失偏颇比较主观的，哪些是足够客观的
  • 有头无尾或者没头没尾的描述，是没有价值的

第 13 章 - 兴趣和热情

• 完成任务

• 产品的责任心

  • 不缺席重要的场合
  • 排除影响进度的问题
  • 主动填充缺失环节

• 产生兴趣

  • 兴趣⼀定是自己发掘出来的
  • 有兴趣未必⼀定擅长
  • 要想让自己能够坚持，兴趣就是最好的方式

• 产品经理的自驱动

  • 挖掘热情
    • 接触用户
    • 成为用户
    • 找榜样
    • 分享经验