起点课堂会员权益
职业体系课特权
线下行业大会特权
个人IP打造特权
30+门专项技能课
1300+专题课程
12场职场软技能直播
12场求职辅导直播
12场专业技能直播
会员专属社群
荣耀标识策略产品经理基础知识：2.3策略需求文档
上两篇帖子，我们说明了策略需求挖掘和迭代的方法。这周我们分享怎么编写需求文档。
一、策略需求文档
策略产品的需求文档和功能产品的需求文档，因为编写的初衷都是为了说明：需求是在什么情况下产生的？用什么样的产品形态，解决什么用户，在什么场景，存在的什么问题？问题解决后想达到什么结果，实现什么目标？需要哪些支持？通过什么方法和数据验证解决方案的有效性。
所以，两种需求文档在结构上是基本相同，内容依次是：项目背景、项目目标、需求概述、需求详述、统计和监控需求。
1.项目背景+项目目标
这两个是需求文档大同小异的内容了。
- 背景：说明需求在什么情况下产生的？谁提出的？
- 目标：帮助什么用户解决在什么场景下存在的什么问题。项目难点在哪，整体的应对策略是怎样的，我们想实现一个什么效果。
依据我的习惯，我习惯在背景部分说明用户场景需求情况，和现有版本存在的问题。
2.需求概述
需求概述主要是说明满足需求的解决方案包含哪些功能模块，各功能模块分别解决什么问题，想实现什么效果，功能模块之间是怎样的组成结构。
内容上其实和功能产品需求文档里的用户划分、业务逻辑、功能结构、功能清单、版本规划等内容大致相同。具体有哪些内容还要视情况而定，只要能把事情说明白就行。
3.需求详述
在《什么是策略产品经理》那篇帖子里，我们提到过，策略产品的解决方案通常是个相对发散的思路；而解决方案通常是通过“逻辑描述和效果示例”去说明产品的实现效果。
即当什么情况下，呈现什么结果。也就是策略产品四要素的后三项：输入条件（触发条件+考虑因素）、计算逻辑、呈现结果。针对迭代策略我们还会加入“问题背景（问题说明、影响面、数据表现情况、产生原因）”。
拆解下来，需求详述部分主要包含以下几个内容，相关详解如下：
- 触发条件：在什么条件下触发策略
- 考虑因素：触发策略相关的影响因素有哪些
- 呈现结果：向用户展示怎样的内容
- 问题背景：问题说明、影响面、数据表现情况、产生原因
- 计算逻辑
- Case示例：上线效果案例
串起来逻辑就是：在什么条件下触发策略功能，然后系统通过怎样的计算逻辑，利用哪些关键因素，将怎样的结果展示给用户。
举例说明：新闻平台，个性消息推送策略
- 理想态：每天早8点，向用户推送1条消息，内容是他喜欢的热点新闻，促使用户打开app；
- 触发条件：每天早8点；
- 考虑因素：用户兴趣标签、内容分类标签、内容热度（公式相关变量：阅读量、点赞数、评论量）；
- 计算逻辑：依据用户兴趣标签，从用户喜好的类型文章中，提取用户未度过的，兴趣匹配度高的，8小时内发布的内容热度最高的前3篇新闻，推送给用户；
- 呈现结果：推送“最近8小时热点事件：文章标题1，文章标题2，文章标题3”，用户点击推送后打开信息瀑布流，信息流前3篇为推荐的3篇新闻。
4.统计和监控需求
策略产品统计数据的设定和功能产品的指标设定逻辑相同，通过工作经验总结，我个人理解策略会更加关注以下四类数据，前三类为通用数据。
- 触发率：满足条件时，策略触发的比例；
- 展示率：策略出发后，给到用户的比例；
- 点击率：给到用户后，用户点击的比例；
- 后置动作：这个看策略流程相关的路径长度而自行添加。
监控需求就是在数据监控系统里，添加监控指标了。PM列出数据计算公式，告诉开发在哪里埋点，多久统计一次，数据表现为什么状态时，系统自动提醒PM就可以了。
二、总结
我记得刚学产品经理那会，我会把社区里所有的需求文档都看一遍，然后整理一个标准的需求文档模板，作为自己输出文档的标准。
但工作阅历告诉我，文档格式其实并不重要。重要的是用“最精简的内容，在不丢失关键细节的情况下，将事情说清楚”。
处理一部分策略需求和学习策略课程后，我发现策略需求文档在需求概述和详述部分更是会针对不同的需求情况写出千差万别的文档。
除了触发条件，呈现结果，计算逻辑是必须写的内容外，其他内容都要视需求而定。核心就是内容能帮你把需求说清楚就可以了，千万不可照抄模板，生套内容，为了写而写，导致文档中出现大量无用内容，而必要内容还处于缺失的状态。
产品工作注重的还是逻辑的思考和表达，俞军老师不是说过：
“结论可以错，但逻辑不能错”。
本文篇内容到此结束，下一篇我在原计划的基础上添加一个“策略需求文档的编写案例”。
本来想放到这篇里的，但避免帖子字数太长，读起来太累，我们另起一篇进行详细分享吧。
策略产品经理学习笔记目录：
《策略产品经理基础知识：2.3策略需求文档》
本文由 @于言某 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
短视频推荐策略
“最精简的内容，在不丢失关键细节的情况下，将事情说清楚”
对这个非常认同
能不能举几个关于推荐系统PRD的例子呀
该如何界定策略产品人员和相关运营人员的工作界限呢？
举几个关于”新闻平台，个性消息推送策略”的例子：
1、策略制定层面
用户运营对日活啊月活啊特定时间内阅读时长啊文章数目啊等指标都很关心，对用户的了解程度不亚于产品经理，他们完全可以将用户进行细分、决定对不同用户采取什么样的运营接触策略（如push）等等。也曾经有某东的某部门下头目认为推荐策略好是运营到位。
2、操作层面
假设有个中规中矩的运营中台工具，运营可以自行做一些精细化的推送（推送可以做成有输入、计算逻辑的推送输出），那么岂不是不需要策略产品经理再去制定、进一步开发策略了？毕竟用户场景是无限的，但是业务场景是有限的，策略中台化岂不是个解放策略产品经理的方式。
3、数据闭环层面
产品人员不仅要洞察用户还要关心怎么实现如何实现还要把控最终实现后的结果，而运营人员只用做到需求挖掘和需求回归（数据闭环）就够了，更加轻量、敏捷，当然也会依赖策略中台，如此依赖策略产品搭好策略中台就可以把活甩出去了。
所以该怎么界定界限？
你是负责push业务的？你这里有几方面是混乱的
我并不是负责push业务的，而是一名”功能产品经理“。愿意听你说说哪些方面是混乱的，当然也许是我没表达清楚。
我的核心疑问在于，如何界定策略产品人员和相关运营人员的工作界限——这是我看了你写的这篇文章，再结合我过去的工作经验，所产生的疑问。
主要是我连续拜读了你的好几篇关于策略产品经理的文章，然后产生的这个疑问，所以评论在这儿可能并不是很恰当，还请谅解。另外针对评论的回复我这里看是按照时间倒序来排的，也许会影响阅读。
过了一会儿刷新后又发现是按照时间顺序排的了…nvm
之前有人在脉脉上问过类似的问题“怎么划分产品和运营的职权和角色”这是我当时的回答“产品是方向和需求的把控方，包括策略、规则、模式、资源的定性定量等。运营是资源的一线支持方，模式或玩法运转人工部分的推动方。”
你混乱的地方就是三个例子都是目标上不明确。
等等，产品是需求的把控方我没意见，但是运营为什么不能是策略的把控方、规则的把控方、模式的把控方等等呢？
也许是我没描述清楚，也许是你没理解功能产品经理 的“混乱思维”——假如有这么个策略中台，运营人员/增长人员完全可以借助于策略中台去实现各种策略的制定、开展、闭环，并进行不断的迭代，那么不就解放策略产品经理了？
需求的把控、资源定性定量的方向/需求的把控，这个是产品分内事情我没意见，但是关于“策略、规则、模式”的方向把控，我不确定你是如何得出这一定是产品的职责范畴这一结论的，更不确定这一结论是否正确。
顺带着再问个问题，分化出来策略产品经理这一角色之前，是谁在制定策略？功能产品经理，运营，还是工程师之类的？
BTW，策略四要素之输入、算法、输出，我是觉得和ML很像，最终都是看待解决问题的cost function是不是local/global optima。
帖子是我去年写的，我现在的看法，策略是产品经理从业的基本能力。如果现在还要划分策略产品，用户产品 这个思路有点过时了。
其次，产品经理在分析问题和解决问题的场景上很多方法都是公用的。策略只是用来解决问题的手段。
再次，什么是策略中台，策略中台不是产品经理做的吗，不懂策略怎么做策略中台。不懂策略做策略中台的产品经理那叫功能产品经理，给人做功能用的。策略中台，策略制定、开展、闭环 这些策略中台能自己执行？我是真不行，或者我们彼此对策略定义不一样吧。
还有你一直纠结的问题，产品和运营的全责划分。世界很大，什么公司都有。如果某个公司或者团队不能清晰界定好两者的关系，不能效率最大化的各尽其职。那我也没什么好解决答的。
“策略、规则、模式”我没说运营不能做，如果运营很懂策略，比产品经理做的好，运营来做这些事也行。产品经理干的垃圾不能保住自己的职位，谁也没办法。
帖子是我前年写的，时间线记错了。
有推荐学习策略产品经理的培训课程 或者成长方式吗？