产品经理的底层逻辑：理解“研究对象的不可重复性”

在线教育的的教学管理后台，运营人员提出需求：

“我们想知道每个老师的请假情况，希望教学管理后台能和OA系统同步，老师请假了，我们就能看到信息”。

经过进一步了解，他们提出该方案的理由时遇到了这样一个场景：给某个老师排了课，但其实这个老师已经请假了，导致后期遇到了一些麻烦。但是经过产品的思考，就会发现运营人员其实不是想知道老师的请假情况，而是想知道我在排课时，如何知道这个老师能不能排课，如果不能排课，那就应该通过系统规避该问题。

最后给出的解决方案：快速新增一个锁定教师排课功能，该功能开放给教师管理负责人，可由老师本人申请锁定排课，审批通过即可。简单便捷。

我们来把这个需求简单复盘一下：

（1）秉着需求分析原则，要在听到描述后，追问或者思考为什么运营想知道老师的考勤？这个功能什么情况下要用？这两个问题想清楚，就可以知道要不要按照他们提出的方案去落地。

（2）经过两个问题的追问，我们发现“与OA打通”并不是他真实的需求，因此，要根据真实需求，结合对产品总体的思考，设想是否有其他更加高效的解决方案。

（3）解决方案要考虑实现成本，例如我们的人力系统为钉钉，技术打通不一定可行，而且还有很多其他的内容要思考，排课系统涉及的内容也很多，改起来比较费时间。因此，我们不会因为一个场景和频率不是很高的需求去花费过多的精力。

（4）综合考虑，拿出了上文提出的方案。技术上简单可行，但最大的问题在使用上，老师和教师负责人是否认可，是否愿意使用，这毕竟给他们增加了工作负担。因此，需要针对他们进一步交流，可行后方可开发，只有最终能真正被使用的产品才能算作合理。

（5）在与老师和教务交流，要说明该功能的好处和优势，并且在操作上尽量做到简单，并配合增加了排课短信提醒功能，最终，他们认为了方案，一周后，成功上线并使用，顺利解决了之前发生的问题。

产品经理经过需求调研，收集上来了3个需求：

A用户想要吃雪糕；

B用户想要一个电风扇；

C用户想要空调；

…………

如果单纯的考虑如何满足每一个需求，其实是不现实的，每个人都有自己的想法，每个人都有自己想象的“解决方案”。产品要做的是抽象与提炼。

经过抽象与思考，就会发现，他们的真实需求其实是“热”，产品经理要做的并不是挨个满足他们的要求，而是通过通用的方案，解决热的需求。

那么既然都是热，每一个人提出的具体需求为什么千差万别呢？因为每个人所处的环境，人生经历和思考方式其实都是不一样的，上个例子中，可能用户A生活在比较偏远的地区，他热的时候可能认为最好的东西就是吃雪糕，而C生活在城市，热的时候就会想起开空调……

因此，作为产品经理，一定要在纷繁复杂的需求中，挖掘本质，抽象提炼，拿出通用的解决方案。