写给产品经理：请时刻保持「怀疑」的态度

保持合理“怀疑”，是产品经理在工作中所应具备的态度，这一态度可以让产品经理更迅速地发现业务疏漏，及时解决未知问题，为工作赋能。同时，这一态度需要贯彻于产品经理工作的各个层面。具体应如何保持“怀疑”？不妨读一读作者的看法。

很多小伙伴都看过下面这张图，“不要相信任何人”是产品经理的生存法则：

我想使用项目中真实发生的案例谈谈我个人的看法——请时刻保持“怀疑”态度。

对业务提的需求

对业务提的需求保持“怀疑”态度，时刻提醒我们再问得多一点，再沟通得深一点。

以下是为我与业务的沟通过程：

业务：产品管理中的“单价”可不可以独立修改，并且放在单独的列表展示，不和基础信息修改放在一起？

我：我们现在已经做了信息修改的功能，其中包含了“单价”的修改，需要你描述一下这个需求详细的场景和单独修改的作用。

业务：我觉得在一起修改比较麻烦，我想单独修改。

我：如果再做一个单独修改的，会导致功能重复，页面功能过多使用起来并不一定很方便哦，而且我们现在技术资源不足，有很多需求在排期，暂时不考虑这种优化功能。

业务：我们小组主要负责价格的优化，如果你不帮我们做这个东西，我怎么去计算价格变化？

我：如果你需要价格的变化，我们可以考虑做一个统计报表，更好地监控和分析价格的变化。

业务：那好吧，可以按照你们的要求去做。

我们本次沟通，最终的方案是做统计报表，监控价格的变化。

不过我心里依旧保持一个“怀疑”的观点：业务方并不一定只是为了看价格的变化，也有可能价格的变化对他们的绩效产生影响，他们拿到价格变化的数据是为了统计绩效。

如果我们可以进一步通过系统直接计算出组内各个同事的绩效，业务方的使用会更加便捷。

需求是隐形的，用户往往不知道自己想要什么，受于自身的认知的局限性，用户提出的方案往往是他所看过的某种方法。

一切真正的需求来源于沟通，我们必须要不断深究，找到核心问题，并提供解决方案。

对技术的方案

对技术的方案保持“怀疑”态度，不代表对技术的水平不信任，只是提醒我们要时刻准备处理未知的风险。

下面是我负责的某个系统发生的问题：

需求：计算过去30天销量的趋势值，过去30天可能销量波动较大，故需要判断使用不同计算公式。

设计方案的计算逻辑：判断过去30天内销量>0的值的个数：

①若个数>15，则计算公式使用中位数；

②若个数<=15，则计算公式使用平均数。

技术实现的计算逻辑：判断过去30天内销量=0的值的个数：

①若个数<=15，则计算公式使用中位数；

②若个数>15，则计算公式使用平均数。

技术为了判断方便，把判断的方式转换了一下。

大部分情况下，这两种方式计算的结果绝对是一致的，测试同学模拟数据进行验证，结果是一致的，需求验收上线了。

上线后，我们用大量真实的数据跑了两天，我在排查数据时，发现大部分数据都是正常的，有个别数据是异常的，经过我大量的验算，发现了实现的方式与原来设计的有点不一致。

在我们实际的业务中，有些产品刚刚上架，只卖了几天，所以并不是所有产品都有过去30天销量的，按照原有逻辑，销量较少的应该使用“平均数”计算，但是按照技术的逻辑，使用的是“中位数”。

我看过一个很有意思的比喻，说程序的代码就像“城中村的电线”——虽然看起来杂乱无章，但是能保证每家每户都有电，使用起来没有任何问题；但如果有一天有人动了一条电线，整个城中村电路就瘫痪了（没有嘲笑的意思，程序员小哥哥勿怪）。

所以说系统上线，正常运行，不代表我们产品工作已经完成，仍然需要一直跟进。

负责产品的全生命周期管理，对于任何的小问题都要有所警醒，复查是否是系统设计方面有所漏洞。

对系统数据

对系统数据保持“怀疑”态度，是指我们不能单纯只看数据，要结合数据背景，进行合理的分析。系统的数据是最客观的，经过合理的分析，可以辅助我们做很多改善。

以下报表是我模拟的一份电商公司的数据（仅供参考）：

图一

看图一，如果仅仅来看这份数据和趋势图，我们得到的第一个结论可能是，公司退款率在不断下降，客服部门做了很多的努力。

图二

再看图二，我们拿到了销售额和退款额，发现1、2月份销售额不高，但是退款额很高，10月份开始销售额开始上升，这个时候我们已经对图一的退款率变化产生了“怀疑”态度。

图三

图三，我将退款率的计算公式换了一种算法，【退款率=当月的退款额/上一个月的销售额】，整体的退款率就趋于了稳定。

在电商行业的同学大概知道：上半年是淡季，下半年是旺季，跨境电商的配送周期较长，订单的退款经常会发生跨月的情况。例如12月的订单，退款集中在1、2月，但是1、2月的销量没有12月份高，所以就出现了图一中的1、2月退款率过高的情况。

我描述的这种算法并不是最合理的算法，只是一个取巧的方式，具体的算法我们还要结合行业的背景进行优化。

脱离了实际业务的数据分析没有任何意义，我们在看任何数据的时候都要附带背景，在得出看似合理的结论之后，仍然要对数据保持“怀疑”态度。

对领导的安排

对领导的安排保持“怀疑”态度，是让我们有“向上管理”的思维，对于领导的吩咐，要洞察背后的含义，若领导安排的工作难以开展，也要及时反馈，与领导达成一致意见。

有这么一个场景给大家举例：

领导：我刚刚开完公司的会议，上面沟通了一个事情，你去把A需求做了。

我：领导，这个A需求是主要解决什么问题呢？

领导：这个是为了解决XXX的问题。

我：领导，您还记得一个月前我们有个需求B吗？当时评审B需求时，B的优先级不高，我们排到了下个月的版本中，我刚才听您的描述，如果要做这个A需求，需要有B作为基础支撑，才能实现A的方案，您看我是不是要把B的优先级提上来，B需求配合A需求去做？

领导：哦，之前我没注意到这个细节，我先考虑一下时间和资源安排，稍后做出决定我通知你。

我：好的，收到。

在“领导”这一角色，由于观察问题的高度不一样，往往会忽略到一些细节点；我们作为方案的执行者，是需要将方案进行落地的，如果经过合理的分析，发现方案上面的漏洞，需求及时反馈问题，并提供可处理的方案，由领导拍板决定如何进行下面的工作。

对自我

每个人都会有犯错的时候，我们自身也不例外，做项目复盘就是为了检查历史项目中的不足，并要求自己在接下来的项目中改进。

有一个名词叫“专家盲点”，大概的意思就是一个精通某领域的专家，正因为他太精通，以至于他忘记了当他不是专家时所遇到的困难。

当我们去做一个熟悉的工作时，很多时候肢体的动作绕过了大脑的思考，使用的是肌肉记忆。

如果带过很多项目，在业务提出需求时，我们很迅速地能判断业务提的需求是否可以实现，从而在短时间内给出答案，这个时候我们很可能会陷入“专家盲点”。

我们需要分析需求的背景，切换不同的视角，来重新审视这个需求的合理性和技术可行性，把每一次需求都当做一个全新的需求来对待。

对自我保持“怀疑”态度，谨防可能发生的风险，并做好随时调整方案的准备。

总结

对业务提的需求保持“怀疑”态度，加深沟通，输出合理方案。

对技术的方案保持“怀疑”态度，持续跟进，时刻处理未知问题。

对系统数据保持“怀疑”态度，结合背景，让数据为工作赋能。

对领导的安排保持“怀疑”态度，向上管理，与领导达成一致意见。

对自我保持“怀疑”态度，切换视角，及时调整方案。

保持“怀疑”态度，保持敬畏之心。

望与君共勉，欢迎评论骚扰~

本文来自微信公众号 “人人都是产品经理”（ID：woshipm），作者：elvin，36氪经授权发布。