最近团队成员的口头禅变成了，我太难了。身为产品狗的我们还是比较有发言权的，经常会顶着来自各方的压力去把事情做成，事情做好了还好，做不好的话，就比较难交代了。
由于职责上承上启下，在协作的过程中，经常需要游走于各方之间，根据以往的经验来看，大多数担心会发生的事情，最终的确发生了，大多数没强力推动的事情，总归会卡在哪一环。然而并没有什么办法，除了产品，大多数的职能也确实无需为最终的结果负责。
在推进事情的过程中也总是会有各种状况，有的时候我们会坚持己见，有的时候我们会由于种种原因而妥协。
本文列举了几个高频的角色，分别是与其他产品，与运营，与开发，与老板，下面来分别看下。
与其他产品
产品之间还算是好沟通，大家就看优先级和性价比嘛。但这个又分两种场景，一种是团队内的，一种是团队外的。
团队内的倒还好，本来就比较熟，大家的目标也基本一致，刷个脸，吃个饭，再不行没有一顿下午茶解决不了的，一顿不行那就两顿。
团队外的就不好说了，可能是业务上下游关系，也可能只是求别人合作。如果你们是强势业务部门，这就比较好过，但如果你们是弱势业务部分，这就真的比较难了。
跨团队协作可以分这几种场景，互利，不损人利己，损人利己。
互利当然是非常理想的情况嘛，大家都好过，但问题在于你这个利对于对方部门而言，是芝麻还是西瓜，不同大小的利，待遇当然不一样。
不损人利己也是时有发生的，比如需要XX业务部分给提供个接口，或者需要XX部门做一些定制开发，虽然对别人没啥大的损失，但毕竟是要占据人力和时间的。
损人利己这种事是最难推的，比如你们需要更大的曝光入口，需要更多的流量，但上级的业务部门需要背负着点击率和转化率的指标，一旦放量势必会导致转化率下降，这样别人肯定不愿意帮你去做这种事情。
其实大家也都能理解，换个角度，把自己放在对方的位置，可能自己做出来的决策也是类似的。
所以啊，只能尽可能的求同存异，找双方互利的点。实在不行，只能去求助了，自上而下的去推动这件事情。
与运营
大多数时候，运营的目标是以短期目标为导向的，而产品的目标一般是短期目标+长期目标，不能说过完2019年最后一个季度，就不过2020年了，所以有时候难免会出现意见相左的情况。
之前和一个运营小伙伴在一个问题上争执了很久，当时在制定一个运营策略，我们讨论当用户与商家的利益发生了冲突，这个时候平台需要偏向于哪一方。
细节记不太清了，当时他认为应该偏向商家，因为我们是从商家手里拿的提点。我认为应该偏向于用户，因为有用户了，商家才能赚到钱，才会留下来，用户流失最终必然会造成商家的流失，并且举了美团的一个例子。
当年团购行业对于已下单，未消费的订单，是一概不退的，这样平台上就会沉淀大量的资金，商家平白多了一笔资金，平台也能有部分资金沉淀，但王兴最终决定把这笔钱退给用户。
支持未消费的订单退款，看上去是损失了平台和商家的既得利益，但从长远看来，未必是一件坏事。假定不支持退款，用户购买的时候一定会产生顾虑，万一我有事去不了怎么办，还不能退，假定支持退款，用户就不会有这种顾虑。
现在想想，当时还是比较善良的，因为现在的我发现当时少考虑了一个限制条件，那就是供需关系。
比如同样是做二手电商平台，二手书和二手房的逻辑一样么，规则应该偏向于用户还是商家？
个人觉得二手书应该偏向于用户，二手房应该偏向于商家。
我的逻辑是这样的，二手书是一个买方市场，用户有很多选择，用户在哪里商家就会在哪里，所以平台需要留住用户，这样才能留住商家。
二手房则不一样，这是一个卖方市场，一个城市二手房的数量是存量市场，总数量就这么多，同一个小区，你的房源越多，话语权越大，用户要买只能来你这，所以平台需要拓展商家，才能留住用户。
有的时候，运营同学也会提不少需求，有的合理，有的不一定合理，可能是目标不合理，可能是方案不合理，也可能是方案和目标不匹配。
比如运营过来找你说我要用一个XX功能，这个不是现成的么，你在上面帮我稍微修改一下就好了，但从产品的角度来考虑，这可能只是个一次性的东西，不太适合功能化，而且也不能和原有的业务耦合性太高，上线之后后期的维护成本可能也不小。
这个时候我们能做的就是一起探讨一个相对更合理的方案，有的团队运营话语权比较强，产品决策的范围比较有限，但也需要能有着自己的坚持。
与开发
产品和开发一直是相爱相杀的存在，优秀的开发会帮你考虑很多临界情况，有的开发就是你说啥做啥，多了也不做。
一般老大难问题就是，这个实现不了，和预期不相符，或者效果不行。
这个实现不了在大多数开发那里都会遇到这个问题，曾经为了一个想要的效果跟开发掰持了一个多小时。
一般我会问这么几个问题，是技术上实现不了，还是我们目前的情况实现不了？
开发一般会balabala。
如果是技术限制，那就比较难了，如果是后者，我会接着问如果我们想实现这种效果的话，或者类似的效果，需要怎么做，有什么好的方案嘛？
开发一般会balabala。
这个时候你一般会获得一些有效的信息，比如是工期不够，还是需要XX业务提供支持，或者是需要翻一下历史的代码，按问题去找对应解决的方案就好。
和预期不相符可能有很多种原因，是文档没写清楚还是沟通不到位，还是理解有偏差。没什么好的办法，文档写清楚一些，多沟通，多解答疑问，不要在开发过程中玩失踪，然后最后蹦出来说这个不是我想要的效果啊。
效果不行，改呗。
按照目前的经验来看，一般担心会出问题的，最终很有可能真的会出问题。如果目前来不及改，后续很可能更来不及，然后我们自己也会变成历史遗留问题的一部分。
开发同学是我们的战友，多次项目合作之后，在开发心目中的形象决定着后续他们跟你合作的态度，拿出你的专业程度，靠谱一些，多帮他们解决一些问题，尤其是资源和沟通协作方面，你会发现很多最开始你遇到的问题，后面都不是问题。
与老板
这个是肯定绕不过去的问题。
一般会有这么几种情况：
- 老板觉得靠谱，你也觉得靠谱；
- 老板觉得靠谱，你觉得不靠谱；
- 老板觉得不靠谱，你觉得靠谱；
- 老板觉得不靠谱，你也觉得不靠谱。
情况一、四没啥好说的，觉得靠谱就做，大家都觉得不靠谱就不做，主要分歧点在二和三。
老板觉得靠谱，你觉得不靠谱。这里面又有两种场景，一是经过历史证明或者严密推导过的，这个就是不靠谱，二是你只是觉得不靠谱，而不知道是否真的不靠谱。
如果是前者，那你去找找数据、用户反馈来佐证你的观点，看看和老板是在目标上不一致，是路径上不一致，还是节奏上不一致，然后再看后续怎么说服老板，自己不行就再拉上几个团队成员一起。
如果是后者，把你的想法先说出来，有的时候信息不对称，视角会不同，看到的问题和方向也会不同。
老板觉得不靠谱，你觉得靠谱。这就需要你能说服你的老板，毕竟没Ta的支持，后续推进，资源协调可能都是问题。
如果屡次都证明你的老板的决策比你靠谱多了，那你还是老老实实多学点东西吧，如果屡次都证明你的决策比你老板靠谱多了，那么恭喜你，你可以考虑当自己的老板了。
你需要的是对自己、对结果负责，而不是对你的老板负责。很简单的问题，你要是决策和行为都是对你的老板负责，万一哪天换了个老板呢？
你已经非常适应现在环境的生存法则，突然把你丢到一个新的环境，你能适应么，或者说你有能力去一个新的环境么？
有的时候折腾一个项目真的挺累的，或者需要各路求爷爷告奶奶，或者需要处理各种突发问题，或者需要说服别人按照自己的意愿去做事。
结果是好的固然很好，结果不好也会很令人沮丧。
但看到数据上升，看到用户好的反馈，看到自己被同事和上司认可，那种成就感会让你觉得之前所做的一切，都是非常值得的。