功能：细化与打包读书笔记 #Week6

一个功能的DNA

• 需求转化-->确定基本属性-->分析商业价值-->初评实现难度-->计算性价比
  • 用户需求和产品需求是多对多的关系
  • 需求的基本属性：编号，提交人，提交时间，模块，名称，描述，提出者，提出时间，Bug编号*
  • 产品5±2个模块比较合理，再多也可增加基本属性：“二级模块”
  • 需求种类：新增功能、功能改进、体验提升、Bug修复、内部需求
  • 产品需求列表：模块，子模块，Feature，任务描述，商业价值描述，商业属性，商业优先级，开发量，性价比，备注

---

• 价值评估

  • 参照“产品原则”目标部分的定义，明确当前产品最看重的指标是什么。如果有多个指标，加权合并。

  • 考察每个功能点实现后，对上述指标的帮助大不大。

    • 广度：潜在用户数 X 单用户价值
      • “天花板”
      • 具体操作时，先从某些细分用户切入，再逐步扩大到所有潜在用户
    • 频度：需求频次 X 单次复杂度
      • 需求频次高

      • 单次需求的复杂度高，单价高，也有很大的价值可以挖掘（婚纱。。）

        
        
        

        image.png
    • 强度：不可替代、紧急、持久
      • 真实刚需：当你没有做这个产品功能时，用户是不是在设法解决，甚至已经在用某种低效的方式来解决这个问题？
      • 可替代性：包子-->馒头 vs 豆浆
      • 紧急程度
      • 持续时间

  • 不同阶段的产品各有侧重

    • 早期的验证阶段：强度。测验留存率高低。
    • 拉新阶段：广度。依赖的是需求和功能覆盖的广度是否足够大。
    • 瓶颈期：频度。先主攻“单用户获取成本”低的场景。

  • 实用工具的突破

    • 墨迹天气
    • 工具性产品困境：单用户价值低，可替代性强
    • 增加用户黏性：实景功能，引流。。。
    • 一个产品要大成，靠的就是用户与你产生复杂的积极性情感

  • 智能硬件：KOL营销

• 成本评估

  • 首先判断成本的瓶颈在哪里，例如开发量

  • 确定性价比

    
    
    

    image.png

---

• 功能分类（KANO模型）

  • 一些基础功能非做不可，工作量较大，性价比不高

  • 基础功能Must Have

    • 这类功能没有实现，用户“极其不满”。做得再好，也是“理所应当”
    • 无法带来满意，只会消除不满

    • 不需要看性价比，留足资源先搞定

      
      
      

      image.png

  • 领域知识

    • 如果没有功能A，你觉得如何？很满意、一般、无所谓、不满意、很不满意
    • 如果有了功能A，你觉得如何？

  • 亮点功能Excited to have

    • 习以为常-->赞不绝口
    • 亮点是忠诚度、口碑传播的基础
    • “用户没见过”“未经市场检验”“如果被认可，就能获得巨大回报”

    • 对用户人性的理解

      
      
      

      image.png

  • 期望功能Nice to Have

    • 对产品而言，这类功能多多益善
    • 先做性价比高的

    • 缺乏惊喜不大可能主动传播

      
      
      

      image.png

image.png

• 无差别功能

  • 做不做用户对产品的感受是没有变化的（后台数据）
  • 低成本验证是不是无差别功能

• 反向功能

  • 满意”，针对某一种客户可能是反向的，针对另一种客户却可能是正向的
  • KANO往往只针对一种用户，通常是核心用户
  • 用户的多边形和多样性

• 价值由产品背后的用户需求（问题）决定，成本由产品功能（解决方案）决定。性价比=价值/成本。

---

功能打包，确定MVP

• 尽可能多放弃
  • “用户愿意用，最好愿意付费”“用户易于使用”“团队有能力实现”的最小功能集合
  • 多快好省，范围大、时间短、品质高、资源省（TRQ: Time, Resource, Quality, Quantity）
  • MVP的限制因素
    • 不同功能，不同对策
      • 基础功能必做，要留足资源
      • 在产品初创期，先实现个别低成本的亮点
      • 对期望功能，先做性价比高的
      • 无差别功能无需做，低成本验证即可
      • 对反向功能，权衡各方利益后决定
    • 考虑功能依赖关系
    • 考虑功能相似性：通过业务逻辑图的方式可视化，可以更直观讲解
    • 粒度大小：需求列表的任意一行，工作量做好不超过“5人天”
    • 考虑非功能需求（性能需求，培训需求，运维需求，可扩展需求，内部数据分析需求）
  • MVP的表达：产品架构图
  • 功能分分合合的本质：不同用户角色背后的自然人重合度高不高

---

BRD

• 项目背景：列出项目的必要性，我们在哪里，为什么要做这个项目，解决什么问题
• 商业价值：我们去哪里？！！！
• 功能需求描述
• 非功能需求描述
• 资源评估
• 风险和对策

---

需求的DNA

• 编号
• 提交人
• 提交时间
• 模块
• 名称
• 描述（无歧义，完整性，一致性，可测试）
• 提出者
• 提出时间
• Bug编号
• 分类（新增功能、功能改进、体验提升、Bug修复、内部需求）
• 层次（基础、期望、兴奋）
• 重要性
• 紧迫度
• 持续时间
• 商业价值
• 开发量
• 性价比
• 状态（待讨论、暂缓、拒绝、需求中、开发中、已发布）
• 负责PD
• 开发工程师
• 项目名称
• 发布时间
• 备注（被拒绝的理由；被暂缓的理由和重启条件；其他文档）

---

需求的生命周期

image.png