三、策略产品工作的通用方法论
3.1 需求文档框架
3.1.1 目的:让项目参与方和其他对项目感兴趣的角色更好地理解需求的来龙去脉
- 项目背景:为什么要启动这个项目?
- 项目目标:背后解决的问题是什么?怎么才能达到解决问题这个目标?
- 需求概述:理解整个文档的需求框架
- 需求详述:所有产品细节是怎么的?
- 统计需求、监控需求:非通用,0到1的需求不需要,修复bug的需求不需要
3.1.2 不同需求类型:
功能:收敛的解决方案,通过流程和原型表达产品实现效果
策略:发散的解决方案,通过逻辑描述和效果示例表达产品实现效果
3.1.3 策略的需求的差异:
简单策略:逻辑简单直接的需求,通常开发成本较小(开发通常只需要一天两天)
复杂策略:逻辑复杂的需求,通常开发成本较大(需要几天甚至几个星期)
3.2 简单策略
简单策略:PM可以直接给出策略规则
基于历史数据
参照竞品
经过多次重复尝试,确认竞品定义了超过3分钟用户就要再次输入密码,那自己的产品也可以暂定为3分钟
3.3 复杂策略
复杂策略:PM详细描述待解决问题、输入因素、输出效果,包括总结性的概述和示例case(来源于问题调研)。计算逻辑由策略工程师开发实现。
案例1: 从0到1,电子书阅读器的屏幕阅读体验不佳如何解决?
案例2: 策略迭代,滴滴拼车策略优化
-
需求文档自检清单:
-
小结:
策略需求文档的核心是将策略的四要素描述清楚。
其中针对复杂策略,可以跳过计算逻辑这个要素,但是需要通过具体的case示例将问题和产品实现效果更清晰地表达出来。
策略产品经理入门学习笔记:
策略PM入门学习(一)
策略PM入门学习(二)
策略PM入门学习(三)
策略PM入门学习(四)
策略PM入门学习(五)
网友评论