5000字教你写ToB产品需求文档( 四 )


3. 方案信息
方案指我们需要做哪些功能来帮助用户解决问题 。 从篇幅上来讲 , 方案信息是整个PRD的大头部分 , 也是新人最为关注的内容;但随着经验的增长 , 处于实现层的方案文档撰写能力将逐渐转化为一种基础能力 , 而不是竞争性能力 。
可能有些人会对文档撰写不屑一顾 , 但笔者认为这是产品经理对外的第一张名片 。 产品经理本身是一种无授权的团队leader , 我们需要通过递出一张张合格甚至优秀的名片来建立团队影响力和信任感 。 因此 , 一个好的文档撰写能力至关重要 。
我们将方案信息划分为3大版块:方案规划、方案内容、埋点信息 。
5000字教你写ToB产品需求文档
本文插图
1)方案规划
在着手开工之前 , 我们先需要向团队讲清楚这一次我们大致准备怎么做 。 方案规划的内容包含但不限于分期规划、满足场景、需求清单(粗略版)、目标价值、衡量指标、风险评估等 。

  • 分期规划:B端客户的需求往往庞乱而复杂 , 当我们面对的客户群体标准化程度较低、个性化需求较多时 , 可能会选择分期解决、小步快跑 , 先满足核心主流场景 , 再逐次完善分支异常场景 。 所以 , 当我们决定分期解决问题时 , 就需要提前向大家告知清楚 。
  • 目标价值:指该方案上线后能够为用户带来什么价值、给公司又能带来什么样的商业价值 。
  • 衡量指标:常言之 , 无法衡量就无法优化 。 因此 , 我们需要明确出1-3个能够真正衡量方案价值的指标 , 便于我们未来进行优化和迭代 。
  • 风险评估:指迭代上线前 , 需要对整个迭代可能遭遇或造成的风险进行评估 , 包含技术风险、用户体验变更风险、数据修复风险、并发风险等 。
笔者曾经有一次惨痛的迭代教训就和缺少风险评估有关 。 那次迭代是对原有的一些“糟糕”交互进行了优化 , 当时并没有考虑到是否会对用户原有使用习惯造成影响 , 最终上线后 , “收获”了一大批的负面反馈 。 如果能提前对此有所评估 , 也许就会考虑通过一键切换回旧版本等一些缓和性的方案来进行平滑过渡了 。
2)需求清单
需求清单指我们需要满足哪些需求、各需求的优先级是什么样的 。 其中包含但不限于需求名称、需求描述、需求类型、所属模块、优先级等 。