为了保持内容的连续性，整理一下之前花几千元学习过的课程。课程来自三节课。上一篇有总结什么是策略产品经理，以及策略的四要素，那么实际工作中的工作流程是怎样的呢？
简单总结为4步：
发现问题
撰写需求
跟进开发评估
上线后的效果回归
如何发现问题呢？
首先需要明确的是，项目产品经理与功能性产品经理有些区别：
功能性产品经理：面对一个人相对聚焦的需求，例如确认bottom放在右下。通过流程和原型表达产品实现效果。收敛的解决方案。
策略产品经理：一群人更多样更有统计意义的需求，抽象的粒度比功能性产品要小。发散的解决方案，通过逻辑描述和效果示例表达产品的实现效果
因此策略产品经理面对的是一群人的问题，这也决定了策略产品经理要以上帝视角去发现问题。
发现问题有4种方式：
方式一：用户反馈
用户在使用产品的过程中，会遇到很多问题，有时候他们为了继续使用会主动反馈，收集这些问题并纳入到需求池，这是很多产品迭代的重要依据。
收集问题有2种渠道：
自有渠道：端口的用户反馈、客服收集的问题外部渠道：各类应用商店（APPstore、应用雷达、wetest）、微博贴吧等渠道的评论
由于这些反馈是用户自己写的，基本是描述问题，更多的是需要认真分析的，如前段时间钉钉收获全国小学生的“五星好评，分期付款”点评。因此数据处理的工作量比较大，基本都是要一条条阅读并标注，标注后还要对问题进行分析、总结、归类，常见问题归类有[不是问题]、[未知问题]、[已知问题]
下面是一个真实的例子：
这只是一部分，可能会有上百条的数据需要清洗处理。
这个方式有一定的局限性：收集到的问题比较随机，很难反映产品现状的全局。虽然可能代表一类问题，但是问题的影响面和优先级比较难判断。但是，我们必须清楚的一点是：每一个反馈背后都是一个真实用户的情感表达，以敬畏心态深入分析每一个问题。
方式二：系统监控
监控是一种针对相对稳定的产品，通过对数字性指标的收集和观察，自动、实时发现问题的有效手段。因此在使用系统监控之前，需要先定义好监控指标和报警规则，即什么情况下我们需要以什么样的方式收到通知。
定义指标前我们需要对产品框架进行拆解，常见的方法是黑白盒分析，所谓黑盒即后端模块，白盒是用户行为。
以淘宝消息推送为例：黑盒：准备各类素材→选择待推荐用户→将内容和用户进行推荐匹配--->白盒：用户收到消息→点击浏览
定义报警规则通常需要根据产品历史数据得到正常波动区间，在正常区间外发起报警给相关负责人。
系统监控需要根据重要程度和影响面来决定响应的及时性以及报警方式。
方式三：效果回归
效果回归可以简单概况为：
定义理想态——拆解未达理想态的情况——提出解决方案——验证是否解决
效果回归是解决问题的终点也是起点
效果回归有3个步骤：
启动前
明确预期，产品和项目的目标是什么
指标体系：该目标可以用哪些指标来衡量呢？
问题和目标是什么
解决问题的关键路径
新的路径伤害了谁
开发上线
确定上线方式：小流量和全量
上线后
收集第二步中的指标，看是否到达第一步中的预期
分析问题，产出结论（符合预期则中止；不符合预期新的循环开始
方式四：阶段性调研阶
段性调研是针对产品现状进行的系统性分析。通常出现在以下时间节点：接触新产品：接手某个产品方向的时候 周期性回顾：每个月/季度/半年等固定周期的回顾 不定期回顾：其他需要临时回顾整个产品现状时阶段性调研需要经历3个步骤：
1.找到理想态：定义理想态并以数字化的指标衡量
2.抽样分析：将所有不达理想态的case抽样分析，并做统计分类，明确满足不好的原因。
3.优先级判断：影响面、严重程度、解决成本确定优先级，作为接下来的项目计划
发现问题的环节结束了，撰写需求就比较简单了
如何撰写需求呢？
需求作为开发的参考文档，主要包含以下几个部分，核心是将策略的四要素描述清楚
项目背景：为什么要启动这个项目
项目目标：背后解决的问题是什么？怎么才能达到解决问题这个目标
需求概述：理解整个文档的需求框架——待解决问题
需求详述：所有产品细节是什么样的——输入、计算逻辑、输出效果（示例case）
其他：（统计需求、监控需求）
需求写完后，可以对照检查一下是否合格：
结构：逻辑清晰，层次分明
背景：背景描述清楚，待解决问题一目了然
目标：产品理想态或考核指标是什么
示例：通过示例辅助，让问题更明确清晰
跟进开发评估
评估方法：
1.策略质量评估策略质量评估需要关注2个指标：召回率R和准确率P，其实就是F-measur
a是需求权重值，a越小需求强度越大；F值越大，说明对需求的满足程度越好关于召回率和准确率后面再分享。
2.diff评估：good same bad
基于理想态，找问题
汇总或抽象问题，提出解决思路或方向
给出结论
效果回归
效果回归与发现问题中的方式三相同，此时效果回归就是问题终点了。策略就是这样循环往复，直到到达产品定义的理想态。
