一切问题，产品经理背锅

分享入职半年多的几个小收获、思考。

一、一切问题，产品经理背锅

产品经理是结果导向型岗位，结果导向型换句人话说就是：我们所做的一切工作，都是为了拿结果，对于PM而言，就是看上线之后的结果，是否创造了价值。如果拿不到结果，这个过程中的一切问题，产品经理都要背锅。

如果是因为整体链路太长，某一个环节因为重要人员临时缺位导致需求无法上线，这证明产品经理在初期拉通链路的时候并未识别到关键环节的风险并找到backup方案，风险把控意识不强。

如果是因为团队内设计同学和开发同学之间因为沟通不充分无法达成一致导致需求无法推进，那么产品经理没有充分充当团队的粘合剂，拉通团队内部的信息，拉齐团队的共同目标。

如果产品被推广给了错误的用户，这证明产品经理和商务/运营的同事沟通不充分，对方错误的理解了我们这款产品的定位和目标用户，导致选择了错误的投放渠道；

如果是因为用户的使用方式不对导致的不符合预期，那么证明产品本身的设计就有问题，只满足了可用性，没有满足易用性，部分指引还不够清晰明确，导致用户用错误的方式打开了产品。

如果是因为初期资源有限产品打磨不完整导致结果不佳，那么证明产品本身并没有能够创造足够大的价值导致公司不愿意投入足够的资源，或者是产品经理本人在上下游的沟通中不够充分，导致没能让团队充分认可产品的价值。

总而言之，拿不到好结果，产品经理有责任和义务去背锅。但背锅不是目的，明确结果导向型是为了让我们不局限于细节，而是跳出来从产品的全局去思考。

二、面向结果决策，而不是面向困难决策

作为结果导向型的工作，需要明确，我们的目标不是完成老板的任务，而是拿到自己满意的结果。如果遇到的困难影响到我们拿到结果，那我们就必须毫不犹豫选择拿结果。

举个例子：完美主义者希望每一个产品细节都打磨到极致，但是在时间和资源都有限的情况下，如果沉浸于抠细节可能影响到需求的正常按时上线，是不是可以让渡部分细节保证功能正常的上线。

当然，上线不是我们要的最终结果，我们要的是解决用户的问题，满足其特定场景下的需求，用我们的产品为他们创造价值。当让渡的细节过多，需求质量滑坡的话，那么即使是上线也拿不到我们想要的结果。

如果我们遇到的阻力不影响是否上线，只影响到上线的效果，那么需要考虑的就是ROI的问题，考虑向困难妥协之后对结果的影响是否可接受和不向困难妥协需要付出的成本是否能承担，两者孰轻孰重。

三、产品的工作是交叉复杂多线程的

去年有一阵子工作比较忙，某几天疯狂被各种内部外部的需求方催，每当被人催促我总是会很紧张，担心没能按时完成会影响到对方的工作正常推进，会影响到合作过程中对方对我的认可度。

但是时间是有限的，多个ddl逼近，多个需求方催促的时候，我就慌了阵脚，不知道该做哪个，甚至一度怀疑自己，有啥资格可怜被系统压榨的外卖小哥，自己做的工作和外卖小哥有什么区别，外卖小哥被外卖的ddl追赶，我被需求方的ddl追赶。

事后冷静下来回想，还是有区别的，最大的区别在于外卖小哥的工作相对是单线程的，以时间为维度，按照时间顺序逐一完成ddl即可。

而产品经理的工作不是单纯的以系统分配的时间维度为唯一准绳的，时间维度只能说明紧急程度，不能说明重要性，如果我们只是被动的根据被需求方催促的紧急程度去完成工作，就意味着大量的时间被浪费，更重要的事情被放弃，而产品经理本人在单位时间内的产出也会变低。

产品经理的工作是交叉复杂多线程的，根据需求方不同，需求的价值不同，需求的紧急程度不同，我们需要自己去安排事情的先后顺序。

我们的存在不是为了被动的响应需求方的夺命连环ding（被系统催促送达外卖），也不是为了完成所有需求方的需求（送完所有的外卖），而是在自己时间资源有限的情况下，识别出真正重要的事情并完成。

这个结论也解释了我的另一个疑问，为啥产品经理没有官方的解bug时间。

开发同学在需求正式上线之前有稳定的进入开发的时间、提测的时间、解bug的时间。产品经理要陪着开发解bug，要面临需求上线之前的各种问题。大部分时候，解决这些或大或小的问题比我花在写需求文档的时间要多得多，可能白天都在用于拉通，串讲，讨论，解题，晚上2-3个小时才能用来写文档。

所以我就一直很好奇，为什么产品的工作不能像开发一样留出一段解bug时间呢？

原因是：开发要找的bug有两个特点，有稳定的出现时间和有衡量标准。这些bug会在开发完成后的提测阶段稳定的出现，对于什么是bug，产品、开发和测试都是以产品文档想要实现的效果为准绳进行衡量，并且逐一解决。

因此，开发要解决的bug有判定的标准（PRD），有稳定的出现阶段（提测阶段），但是产品要面临的bug并不是这样。

PRD是衡量开发效果是否ok的标准，但是PRD本身是否能够解决用户问题，是否能够创造价值，这个是更主观更难判定的，每个人对产品的标准不一样，接受程度也不一样。

某些时候，也会有同事吐槽你这个产品的实现效果不佳，但是只有你自己知道，这个是在资源有限的情况下能够达到的最好的效果了，产品经理是对需求的实现背景和过程了解最清楚的人，所以对需求本身有最终解释权。

此外，推动产品上线过程中，产品经理要面临的挑战也没有稳定的出现周期。

• 它可能会在链路拉通的初期出现，各个业务方不肯认同你的需求价值，不愿意配合；
• 也有可能出现在需求推进的中期，你预期的效果开发说很难实现，或者实现成本异常高；
• 也有可能出现在需求推进的后期，关联的业务方突然离职，换上来的新人完全不了解背景，不知道如何配合你；
• 甚至有可能出现在产品上线之后，出现了一个测试阶段从未发现过的问题，短期内出现大量用户吐槽或者舆论等。

所以，即使给你留下3天的解bug时间，但是bug不在这三天密集出现，预留时间也于事无补。

四、产品的职责在于解决问题

不仅仅是解决用户的问题，还要解决为了解决用户问题提出的方案/需求上线过程中遇到的各种问题。

表面上，产品经理的工作只是发现需求，明确需求，设计解决方案和推动上线。但实际上，产品经理还有一条暗线工作，就是在推进的过程中，识别潜在的风险并提前规避，遇到困难/阻力的时候如何克服困难/阻力。

产品的能力就是通过这一个个大大小小的问题锻炼出来的，产品能力的区别也从一个个大小决策中分化，最终体现在结果上。

有些时候，为了我坚持的产品效果，会导致需求正常上线存在风险，当我和主管报完风险之后，会发现师兄和我做出了不同的判断，他认为让渡部分产品效果可以接受，相比之下，产品的如期上线才是更关键的。

最近很多剧本杀和密室都流行多结局，也就是说，你在玩游戏的过程中，在一些关键情节做了不同的选择，就会引导你进入不同的结局，之前我们去玩过的一个密室就有多达8个结局。

产品经理的工作也类似一场多结局的探险游戏，每一个分叉口你选择向左还是向右，选择前进还是后退，选择直面问题还是绕过问题，都会引导你解锁不同的结局，影响到你的需求最终是否能上线以及上线的效果。

五、新人最大的贡献是少做错误方案

作为新人，其实很担心自己会闲下来，特别是看到其他人都在忙忙碌碌的时候，如果自己手上没有需求，就会担心自己逐渐边缘化或者没有发挥价值。

但实际上，为了提需求而提需求的话，可能会导致需求思考不够完善或者方案的价值有限。按照产研比1:5来算的话，一个错误的需求会耗费5个研发的时间成本。

所以，在没有想清楚做不做，没有想清楚怎么做的前提下，不做就是最好的选择。不做也是某种程度上对公司做贡献，因为释放出来的资源可以去做更重要的事情，也算是帮助公司提高了资源的效率。

如果经历了一段很忙的时间，突然闲了下来的话感觉到不太适应的话，不用急着找需求把自己的工作填满，可以试着整理和分析各种渠道的用反，可以试着阶段性的复盘自己最近这一个周期的表现，是否符合预期，是否还有值得提升的点等等。

#作者#

李涛，微信公众号：柠檬two。新人产品经理，专注于产品求职分享和社交/社区赛道产品思考。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！