身为产品经理，由于业务的繁杂性，经常会苦恼于一个问题——背锅，如何做到让自己不背锅呢？同为产品经理，作者为大家总结了以下经验，给大家提供一些参考建议。

前言

作为产品经理，背锅算是过来人，写在这里无非是想给自己一个总结，让自己以后的工作能尽量少出差错，同时给刚入行的产品一个善意的温馨提示。

所谓甩锅，调侃而已，并非不负责任，我一直认为，当大家都会甩锅的时候，会降低错误的发生概率，当然，我这里有一个大前提就是，如果的确是自己的锅，烫手也要接着。

以下言语之中，如果伤害到了其他岗位伙伴的情感，那只能说声抱歉，都是为了工作，我这里只是自己的总结，但愿你能见谅。

一、产品

• 自己没有权利决定的事，永远不要自己决定，要和老大确定好，最好有书面确定。这个不是为了甩锅，老大的锅得背着，就是为了让自己心里舒服点，同时也得让老大知道自己在背锅。
• 多个人负责同一个产品迭代时，要注明哪些是自己的需求，哪些是同事的需求，涉及到数据分析以及埋点，自己搞自己的不要一个人大包大榄。
• 嘴上说的需求永远不要相信。没有放在需求池里的需求，都不叫需求，凡是需求必有书面的记录。
• 自己做需求时，功能上最好别创新，看看BAT，看看MTD，社会认知已经形成，抄着来不会错，他们都没有的需求，就看看竞品，毕竟有人已经试水，创新留给体验创新，流程创新与模式创新。

二、测试

• 最好不要看测试用例，异常情况你永远不会考虑的有测试详细，如果测试拿测试用例找你，无法推脱了，那就一定要仔细看，还原到各种场景，最后要问一下他写测试用例的各种场景的复现几率，然后，产品还要再说明自己需求的各种场景。如果测试用例真的出现了自己之前没有考虑到的问题，及时补充到需求文档，并同步开发。
• 改任何需求都必须与测试确认，最好有书面文档，条件允许该需求测试，开发都在场。
• 产品验收的问题，只验收自己的需求的流程与逻辑，不要验收bug，整理说明，最好有书面文档，产品上线后概不负责。
• 最好不要跟进bug的修改，那是测试的事，把控结果和进度就好了

三、开发

• 把需求写清，如果有更改，一定第一时间同步所有人。
• 与开发交流需求问题，最好用文字，因为很有可能开发普通话不太好或者开发表达不清自己的意思，产品会理解错，没法用文字的情况下，交流最后，一定要把自己理解的开发的意思，从自己嘴里再说出一遍，让开发再去确认。
• 做埋点需求时，无论是客户端，h5埋点还是服务器埋点都必须在需求里写清。不要口头告诉。
• 尽量了解开发的实现需求逻辑，但是要假装不知道，和开发沟通需求就说场景，别探讨实现逻辑，因为产品不太懂，开发会挖坑，两三句就给你整懵逼了。除了你真的是一个技术型产品。
• 各种前端与客户端的实现逻辑很简单，要尽量搞清楚，但是要装不清楚，搞清楚是出于对于排期以及实现的可能性为目的，装糊涂是为了让开发提高自己的创造力。
• 安卓与ios实现逻辑尽量统一，否则再次迭代遇到困难几率会增高，展示统一不了勉强就接受吧。
• 做需求时，尽量不要发现问题就改问题，要从根源解决，产品思维是网状的，前端开发思维是点状的，很有可能你改了这块，开发就真的改了，和原来逻辑冲突，你不知道，开发也不知道，上线就该有用户反馈了。

四、数据分析采集师

• 要什么数据同样书面通知，不要只考虑pv，uv，那个太简单，符合你定义的条件的数值，要说场景，别跟他探讨怎么取数据，他实在做不了，就自己去数据库看看有没有相映字段，或者找开发聊聊。
• 数据采集师每天都需要配合别人的工作，所以尽量催着自己的需求

五、运营

• 产品运营不分家，最好和运营搞好关系，但是对于运营活动，运营想法可能会很多，实现不了的要跟他说清楚，自己必要定义活动，配合运营去搞事情，他做主，你画图就可以了。然后哪里什么逻辑一定要口头与书面全告诉运营。

六、UI设计师

• 最好设计文案想好，让他直接看需求文档，这样他会了解设计图出现在哪减少沟通成本。
• 自己需求里最好颜色区分一下你要表达的内容，降低点沟通成本
• 自己抄的需求，让设计也去抄吧，不会出啥大差错。
• 设计文案提前想好，要不然被喷死。

结尾：

欢迎广大产品伙伴说说自己的背锅经历，背一次锅就学习了一次，大家一起进步。不喜欢的就别喷了，留点口水需求评审的时候用吧！

本文由@产品汪汪汪 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议