《启示录》—— 阅读内化（8）

一．这本书的核心观点/思想：

产品经理的职责：

• 评估产品机会；
• 定义正确的产品；
• 落地产品。

评估产品机会：

• 目的：淘汰馊主意，避免时间和资源的浪费；挑选合适的产品机会，团结团队，理解产品目标，整合资源；
• 评估标准：
  • 产品价值：产品要解决什么问题？
  • 需求强度：要解决的这个问题是否足够痛？
  • 需求真实：要解决的这个问题是否真实？
  • 目标市场：为谁解决这个问题？
  • 市场规模：成功的机会有多大?
  • 成功标准：怎样判断产品成功与否？
  • 竞争格局：有哪些同类产品？
  • 竞争优势：为什么我们最适合做这个产品？
  • 市场时机：现在做这个产品的时机成熟了吗？
  • 营销战略：如何把产品推向市场？
  • 解决方案要满足的条件：成功的必要条件是什么？
  • 判断机会：根据以上问题得出是否继续。

定义正确的产品：

• 此阶段最重要的事情是要弄清楚要做什么事情，强调的是探索和全局规划，兼顾短期和长期需求；
• 需要广泛收集用户需求，了解如何运用新技术，拿出产品原型并加以测试，验证需求的真实性以及可行性；
• MVP即是验证需求真实以及相关假设的优秀手段，在验证了机会确实是很不错了之后，再投入更多时间和资源进入落地阶段。
• 市场调研的目的：
  • 确认机会真实有前景；
  • 深入理解用户需求；
  • 确认当下以什么样的技术来更好地解决问题；
  • 确认要设计什么样的解决方案。
• 市场调研的方法：
  • 实地拜访用户；
  • 竞品分析；
  • 问卷调查；
  • MVP——冒烟测试等。

落地产品：

• 此阶段的最重要的事情在于执行，更强调项目管理，将“设计→开发→测试→验证→迭代”不断贯彻到产品中，一步步完善产品；
• 落地产品中的关键点在于“明确的”、“不轻易变更的”目标，将蓝图拆分到各个版本，每个版本把热情和专注投入于每个版本的事情中；
• 而对于目标的管理的关键在于“优先级”，确立当前阶段评估“重要性”的标准，并以此对目标中的任务进行排序，做到每个阶段都有的放矢；
• 落地中的MVP设计：
  • 设计MVP原型，最小可行性产品只具备实现商业目标最基本的功能要求；
  • 只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少；
  • 邀请程序帮助评估产品设计的“可行性”评估，其次是直接成本、间接成本评估等，做到心里有底；
  • 邀请交互设计师进行“可用性”评估，确认是否突出了产品的功能特性；
  • 邀请目标用户进行“价值”评估，测试这个产品原型，并得出NPS分数，一旦确认则不能再进行随意修改。
• 落地中的MVP迭代：
  • 在迭代中需求会非常的多，这个时候就需要“重要性”评估，每个阶段都有不同的“重要性”标准，而这个需求在此阶段的“重要性”评估中处在什么位置来决定是否做这个需求；
  • 一般来说，“提升业绩”、“贯彻公司战略”等标准的“重要性”是最高的，但仍然是需要基于此阶段的方向，来找准最关键的指标来进行判断，不然来者不拒只会让产品臃肿且造成资源浪费。
• 敏捷方法运用的注意事项：
  • 谁的需求谁来担责；
  • 仍然需要轻量级的机会评估、规划，这是每个敏捷冲刺之间的必要条件；
  • 产品经理的设计需要领先于程序开发，同时让程序参与规划和设计；
  • 尽量将工作拆分成多个部分，但避免过于细节；
  • 让开发一同制定迭代周期的规划；
  • 产品、设计、程序一同参加每日站会；
  • 避免频繁更新版本；
  • 版本成果向团队展示，增强信心与理解；
• 瀑式开发的理念：
  • 采用阶段式开发，过程被事先分为几个固定阶段：撰写PRD、设计高层架构、设计低层架构、编码、测试、部署；
  • 采用阶段式评审，每个阶段结束后对阶段提交成功进行评审，评审通过才能进入下一个阶段。
• 瀑式开发的缺点：
  • 产品验证严重滞后：这是最严重的问题，产品经理必须等到软件开发的尾声才能看到可运行的软件，这意味着投入大量人力物力之前，软件的可用性无法得到验证；
  • 变更计划代价不菲：过程中任何对前期决策的修改都会打乱开发流程，甚至会从头来过；
  • 无法适应快速的市场变化：因为严重依赖文档和流程，哪怕是一点点小小的改动都会导致不小的代价，瀑式开发过于理想，认为人们能遇见所有需求，把握所有问题，但这是不现实的，除非是很小的项目，否则瀑式开发已经不再可行。

二．我的收获：

• 这是我所读过的产品相关最具价值的干货之一，作者清晰定义了产品管理过程中所有干系人的职责以及明确其定位，并且在产品开发的各个关键阶段如“机会分析”“定义”“落地”阶段均给出了经验十足的方法论；
• 但是我对于此书收获最深的点不在于产品开发的方法论，，而是在于作者对“瀑式开发”的看法的收获，因为这些产品方法论在学习产品管理的过程中都大同小异了；
• 之前我经历的几个项目我从未意识到自己的团队正在以“瀑式开发”的模式进行开发，最后收获的结果也无法从这个层面去进行更深层次的解释，直到我学习到了瀑式开发的理念和劣势，在回顾时才能更准确的接近本质原因，这是最关键的收获。