一个功能的DNA
- 需求转化-->确定基本属性-->分析商业价值-->初评实现难度-->计算性价比
- 用户需求和产品需求是多对多的关系
- 需求的基本属性：编号，提交人，提交时间，模块，名称，描述，提出者，提出时间，Bug编号*
- 产品5±2个模块比较合理，再多也可增加基本属性：“二级模块”
- 需求种类：新增功能、功能改进、体验提升、Bug修复、内部需求
- 产品需求列表：模块，子模块，Feature，任务描述，商业价值描述，商业属性，商业优先级，开发量，性价比，备注
-
价值评估
-
参照“产品原则”目标部分的定义，明确当前产品最看重的指标是什么。如果有多个指标，加权合并。
-
考察每个功能点实现后，对上述指标的帮助大不大。
- 广度：潜在用户数 X 单用户价值
- “天花板”
- 具体操作时，先从某些细分用户切入，再逐步扩大到所有潜在用户
- 频度：需求频次 X 单次复杂度
- 需求频次高
-
单次需求的复杂度高，单价高，也有很大的价值可以挖掘（婚纱。。）
image.png
- 强度：不可替代、紧急、持久
- 真实刚需：当你没有做这个产品功能时，用户是不是在设法解决，甚至已经在用某种低效的方式来解决这个问题？
- 可替代性：包子-->馒头 vs 豆浆
- 紧急程度
- 持续时间
- 广度：潜在用户数 X 单用户价值
-
不同阶段的产品各有侧重
- 早期的验证阶段：强度。测验留存率高低。
- 拉新阶段：广度。依赖的是需求和功能覆盖的广度是否足够大。
- 瓶颈期：频度。先主攻“单用户获取成本”低的场景。
-
实用工具的突破
- 墨迹天气
- 工具性产品困境：单用户价值低，可替代性强
- 增加用户黏性：实景功能，引流。。。
- 一个产品要大成，靠的就是用户与你产生复杂的积极性情感
-
智能硬件：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
网友评论