产品经理的坚持与妥协

最近团队成员的口头禅变成了“我太难了”。

身为产品狗的我们还是比较有发言权的，经常会顶着来自各方的压力去把事情做成，事情做好了还好，做不好的话，就比较难交代了。

由于职责上承上启下，在协作的过程中，经常需要游走于各方之间；根据以往的经验来看，大多数担心会发生的事情，最终的确发生了，大多数没强力推动的事情，总归会卡在哪一环；然而并没有什么办法，除了产品，大多数的职能也确实无需为最终的结果负责。

在推进事情的过程中也总是会有各种状况，有的时候我们会坚持己见，有的时候我们会由于种种原因而妥协。

本文列举了几个高频的角色，分别是与其他产品，与运营，与开发，与老板，下面来分别看下。

一、与其他产品

产品之间还算是好沟通，大家就看优先级和性价比嘛；但这个又分两种场景，一种是团队内的，一种是团队外的。

团队内的倒还好，本来就比较熟，大家的目标也基本一致，刷个脸，吃个饭，再不行没有一顿下午茶解决不了的，一顿不行那就两顿。

团队外的就不好说了，可能是业务上下游关系，也可能只是求别人合作；如果你们是强势业务部门，这就比较好过，但如果你们是弱势业务部分，这就真的比较难了。

跨团队协作可以分这几种场景：互利、不损人利己、损人利己。

互利当然是非常理想的情况嘛，大家都好过，但问题在于你这个利对于对方部门而言，是芝麻还是西瓜，不同大小的利，待遇当然不一样。

不损人利己也是时有发生的，比如需要XX业务部分给提供个接口，或者需要XX部门做一些定制开发；虽然对别人没啥大的损失，但毕竟是要占据人力和时间的。

损人利己这种事是最难推的，比如你们需要更大的曝光入口，需要更多的流量；但上级的业务部门需要背负着点击率和转化率的指标，一旦放量势必会导致转化率下降，这样别人肯定不愿意帮你去做这种事情。

其实大家也都能理解，换个角度，把自己放在对方的位置，可能自己做出来的决策也是类似的。

所以啊，只能尽可能的求同存异，找双方互利的点；实在不行，只能去求助了，自上而下的去推动这件事情。

二、与运营

大多数时候，运营的目标是以短期目标为导向的，而产品的目标一般是短期目标+长期目标；不能说过完2019年最后一个季度，就不过2020年了，所以有时候难免会出现意见相左的情况。

之前和一个运营小伙伴在一个问题上争执了很久，当时在制定一个运营策略，我们讨论当用户与商家的利益发生了冲突，这个时候平台需要偏向于哪一方。

细节记不太清了，当时他认为应该偏向商家，因为我们是从商家手里拿的提点；我认为应该偏向于用户，因为有用户了，商家才能赚到钱，才会留下来，用户流失最终必然会造成商家的流失，并且举了美团的一个例子。

当年团购行业对于已下单，未消费的订单，是一概不退的，这样平台上就会沉淀大量的资金，商家平白多了一笔资金，平台也能有部分资金沉淀，但王兴最终决定把这笔钱退给用户。

支持未消费的订单退款，看上去是损失了平台和商家的既得利益，但从长远看来，未必是一件坏事；假定不支持退款，用户购买的时候一定会产生顾虑，万一我有事去不了怎么办，还不能退，假定支持退款，用户就不会有这种顾虑。

现在想想，当时还是比较善良的，因为现在的我发现当时少考虑了一个限制条件，那就是供需关系。

比如同样是做二手电商平台，二手书和二手房的逻辑一样么，规则应该偏向于用户还是商家？

个人觉得二手书应该偏向于用户，二手房应该偏向于商家。

我的逻辑是这样的，二手书是一个买方市场，用户有很多选择，用户在哪里商家就会在哪里，所以平台需要留住用户，这样才能留住商家。

二手房则不一样，这是一个卖方市场，一个城市二手房的数量是存量市场；总数量就这么多，同一个小区，你的房源越多，话语权越大，用户要买只能来你这；所以平台需要拓展商家，才能留住用户。

有的时候，运营同学也会提不少需求，有的合理，有的不一定合理，可能是目标不合理，可能是方案不合理，也可能是方案和目标不匹配。

比如运营过来找你说我要用一个XX功能，这个不是现成的么，你在上面帮我稍微修改一下就好了；但从产品的角度来考虑，这可能只是个一次性的东西，不太适合功能化，而且也不能和原有的业务耦合性太高，上线之后后期的维护成本可能也不小。

这个时候我们能做的就是一起探讨一个相对更合理的方案，有的团队运营话语权比较强，产品决策的范围比较有限，但也需要能有着自己的坚持。

三、与开发

产品和开发一直是相爱相杀的存在，优秀的开发会帮你考虑很多临界情况，有的开发就是你说啥做啥，多了也不做。

一般老大难问题就是，这个实现不了，和预期不相符，或者效果不行。

这个实现不了在大多数开发那里都会遇到这个问题，曾经为了一个想要的效果跟开发掰持了一个多小时。

一般我会问这么几个问题，是技术上实现不了，还是我们目前的情况实现不了？

开发一般会balabala。

如果是技术限制，那就比较难了，如果是后者，我会接着问如果我们想实现这种效果的话，或者类似的效果，需要怎么做，有什么好的方案嘛？

开发一般会balabala。

这个时候你一般会获得一些有效的信息，比如是工期不够，还是需要XX业务提供支持，或者是需要翻一下历史的代码，按问题去找对应解决的方案就好。

和预期不相符可能有很多种原因，是文档没写清楚还是沟通不到位，还是理解有偏差；没什么好的办法，文档写清楚一些，多沟通，多解答疑问，不要在开发过程中玩失踪，然后最后蹦出来说这个不是我想要的效果啊。

效果不行，改呗。

按照目前的经验来看，一般担心会出问题的，最终很有可能真的会出问题；如果目前来不及改，后续很可能更来不及，然后我们自己也会变成历史遗留问题的一部分。

开发同学是我们的战友，多次项目合作之后，在开发心目中的形象决定着后续他们跟你合作的态度；拿出你的专业程度，靠谱一些，多帮他们解决一些问题，尤其是资源和沟通协作方面，你会发现很多最开始你遇到的问题，后面都不是问题。

四、与老板

这个是肯定绕不过去的问题。

一般会有这么几种情况：

• 老板觉得靠谱，你也觉得靠谱；
• 老板觉得靠谱，你觉得不靠谱；
• 老板觉得不靠谱，你觉得靠谱；
• 老板觉得不靠谱，你也觉得不靠谱。

情况一、四没啥好说的，觉得靠谱就做，大家都觉得不靠谱就不做，主要分歧点在二和三。

老板觉得靠谱，你觉得不靠谱；这里面又有两种场景，一是经过历史证明或者严密推导过的，这个就是不靠谱，二是你只是觉得不靠谱，而不知道是否真的不靠谱。

如果是前者，那你去找找数据、用户反馈来佐证你的观点，看看和老板是在目标上不一致，是路径上不一致，还是节奏上不一致；然后再看后续怎么说服老板，自己不行就再拉上几个团队成员一起。

如果是后者，把你的想法先说出来，有的时候信息不对称，视角会不同，看到的问题和方向也会不同。

老板觉得不靠谱，你觉得靠谱；这就需要你能说服你的老板，毕竟没Ta的支持，后续推进，资源协调可能都是问题。

如果屡次都证明你的老板的决策比你靠谱多了，那你还是老老实实多学点东西吧；如果屡次都证明你的决策比你老板靠谱多了，那么恭喜你，你可以考虑当自己的老板了。

你需要的是对自己、对结果负责，而不是对你的老板负责；很简单的问题，你要是决策和行为都是对你的老板负责，万一哪天换了个老板呢？

你已经非常适应现在环境的生存法则，突然把你丢到一个新的环境，你能适应么，或者说你有能力去一个新的环境么？

有的时候折腾一个项目真的挺累的，或者需要各路求爷爷告奶奶，或者需要处理各种突发问题，或者需要说服别人按照自己的意愿去做事。

结果是好的固然很好，结果不好也会很令人沮丧。

但看到数据上升，看到用户好的反馈，看到自己被同事和上司认可，那种成就感会让你觉得之前所做的一切，都是非常值得的。

最后，附赠互联网生存指南，拿好不谢。

以上就是本文的主要内容，欢迎斧正、指点、拍砖…

#专栏作家#

王家郴 ，公众号：产品经理从0到1，人人都是产品经理专栏作家，喜欢网球和骑行的产品汪，目前奔走在产品的道路上，漫漫产品路，与君共勉。

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

题图来自 unsplash，基于 CC0 协议