最近在阅读《从点子到产品：产品经理的价值观与方法论》，特在此做记录。
1）三类需求不记
- 没说清楚原因的需求，例如你做个XXX出来，别管那么多。
- 不说清逻辑的需求，例如这里我也没搞懂，你先看看。
- 不说实际遇到的需求，例如我觉得困难有人会这样用。
记录需求的时候，要确保格式：问题+方案，例如XXX在用我们的XXX功能时，感觉XXX，我们可以尝试XXX的方案。
2）需求优先级
判断需求是否重要，可以参考以下排序（从强到弱）：
- 不做，会产生严重的问题和恶劣的影响。
- 做了，会产生巨大好处和极佳的效果。
- 跟核心用户利益有关。
- 跟大部分用户权益有关。
- 跟效率或成本有关。
- 跟用户体验有关。
判断需求是否紧急，可以参考以下排序（从强到弱）：
- 不做，错误会持续发生并产生严重的影响。
- 在一定时间内可控，但长期会有糟糕的影响。
- 做了，立刻能解决很多问题、产生正面的影响。
- 做了，在一段时间后可以有良好的效果。
每个需求为什么在目前的位置和状态，产品经理应当了如指掌。
需求的各种变化、调整和意外，应该同步到整个团队。
3）发现问题
跟我们的预期不符的状况，就是我们需要解决的问题。
问题的合情合理意味着不仅要有能说服自己的理由，还要有能说服别人的理由，不能只提问题，却不去证明问题的合理性。
把问题描述清楚，背景、涉及的人、解决问题的预期，对定量的问题，要有量化的指标；对定性的问题，也要有具体的对于好的定义。例如：
- 跟技术人员的协作在可行性评审中出了问题，经常导致开发延期（不延期就是解决了问题）
- 功能A上线后用户使用率只有10%，至少应该达到50%（达到指标就是解决了问题）
- 文档写得太简略，逻辑流程图有缺失（流程图补全就是为了解决问题）
没有疼痛感也要主动发现问题，这是产品经理的基本素质。去发现问题出在哪里，尝试解决，或者协助别人解决。
4）分析问题
把复杂的问题抽象出容易理解、方便解决的本质。
在看数据或通过很多信息来判断事务时，不要先入为主地认为两件事肯定有因果关系，要看一看它们是不是只有相关性，是否是由别的诱因导致的，而并没有逻辑上的先后关系。
在问题中，任何可能会造成歧义的词语、短句都要明晰其定义。不管是自己分析，还是跟大家讨论都要避免前后不一、有冲突的情况。
从现象中归纳出原理和本质，再用演绎的方法解决更多情况下的问题。
在分析问题时，不要太过主观臆断，还要看最初的假设是不是正确，以及找到真正解决问题并且让我们自己满意的方案。
产品经理应该对统计数据敏感，但不能误读统计数据的含义，平均数就是一个很容易造成误导的数据。
5）解决问题
在发现和分析问题时面向事，而在解决问题时面向人。
当解决不了一个复杂的问题时，就要试着拆分这个问题，按层次、步骤、逻辑拆分，直到你觉得每个小问题都达到自己能够解决的程度再去解决。
对于解决方案跟发现问题时一样，确保它是完整而可行的：
- 问题和背景，为什么要做这件事？做这件事的所有逻辑的缘由是如何的？问题是在什么情境下提出的？
- 内容，完整和有可行性，并且不能模棱两可。
- 负责人，方案应当由谁来负责？为什么由他负责？
- 目标和验证方法，方案达到怎样的效果才算可以？如何验证？
如果是要协助别人或需要别人协助的方案：
- 确保对方获取到所有的信息，让他清楚整个方案的背景、内容和相关的各种信息。
- 了解对方的态度，如果对方不认可，找时间讨论问题出在哪里，确保达成共识。
- 设定一个期限，定期关注方案执行的情况，确保方案的相关人员没有搁浅或忘记此事。
- 解决后检验效果，与发现问题时相比是否缩小了差距，复盘检查整个处理问题的过程。
posted on
