通过冲突模型，可以先来理解双方的替代网站选择，来确定强势和弱势。

对于业务方来说，大概率是可以压着产品按需实现需求的，毕竟一句“你们不懂业务”就可以压垮产品的1万句用户思维。而产品如果和业务方真的闹得很僵，走的人大概率是产品。

在这种天然的强弱关系下，可以从核心诉求入手，去驳斥业务的合理性，以及给自己找论据支撑。

首先可以从以下方面驳斥：

需求和关键目标的相关性分类：这个需求真的能实现关键目标吗？它们之间是怎么样起到网站作用的？如果要起到这些作用，业务要做的一些准备工作或者先决条件有没有具备？

需求对关键目标起的作用的大小：这个需求对内部网于业务向上的动力真的可以起到那么高的作用吗？值得放到高优吗？有没有其他的业务认为重要但不紧急的，工作量很大的活儿也可企业以拿来先规划着？业务的近期，中期，远期规划如何，同时间内外部竞争和环境又会有什么样的发展，需要产品做什么样的准备？

设计方案对关键目标的影响：这样设计操作流程真的会影响关键目标吗？按钮放哪里，界面怎么排布会影响目标达成吗？同时也需要请业务放心，产品的设计一定不是空穴来风，是基于未来需求演化进行的框架设计。

其次产品也可以给自己找外援。

• 用后果做外援：列出业务方案可能产生的最严重问题和后果，如果业务没法解决这个问题，他就不太会再去坚持了。
• 用竞品做外援：同类产品的状态做外援。竞品做了的不一定适合我们，但也有比较大的参考价值，而没做的可能就要谨慎对待了。
• 用用户做外援：找产品使用者的观点来支持。
• 用数据做外援：找之前的相关或者类似的案例，来证明自己是对的。

另外要做到以上的点，核心要点是——比业务还要懂业务。

用我自己现身说法。有一块历史悠久但支持收入体量大的业务系统，主要处于维护状态，很少去做改动，也没人了解里面的背景和逻辑，但是由于业务量大，仍然会不时的有需求过来，所以决定还是有必要去深入了解下这部分的内容。

那我怎么做的呢？

首先我请资深的业务接口人从头到尾讲企业了一遍系统的前世今生，形成了初步的文档。

同时欢迎业务丢需求过来，不管做还是不做，我都会顺着需求的场景去了解现有的功能模块，也增加对于五花八门的业务形态的了解。

与此同时，也抽空几内部网次去现场观察学习，实地看到大家的现场流转和系统使用是怎么对接的，当中又有什么问题。

通过这一系列的操作，我成为了业务心中的贴心小能手。直到现在，业务在这部分有了新的问题，不管是技术问题甚至业务问题，都会找到我询问解决方法，我真的成为了这个板块的专家，也自然在这个板块有了核心的话语权。

四、妥协后的选择

当然要说的信息是，有的时候环境并没有那么理想，哪怕做出了所有的努力，也会不得已按照业务规划的来走。

那么此时可以做分类的是什么呢？

放下情绪，正视最后的结果。

当时争论内部的过程一定是有意义的，虽然不能达成想要的效果，也可以奔着理解对方在想什么做努力。

和业务一起复盘。

当时争论的焦点内部，可以一一记录和保留。在功能上线后，拉着业务去复盘和对照。证明谁对谁错不是本质需求，重要的是双方可以在真实的结果面前，一起回顾为什么这个决定对了这个决定错了，背后的思考方式是什么，渐渐摸索出大家都能认可的思考方式，让业务更靠近产品思维，让产品也更能理解业务思维，也为大家信息的信任埋下基础。

五、总结

个人视野有限，只能以工作覆盖到的场景，也就是企业内部系统作为引子，来聊聊自己的思考。

但竞争和博弈的思路，应该不仅仅适用于企业内部产品这一环境，只要有资源的争夺，涉及多方合作的各种形式，都可以往这两个关键词上去延伸。

最后再回顾一下文章最后中给出的三点建议。

1）转化思路和行为，扭转自己的价值链地位

规划主线，有节奏有重心地控制业务往前推移。短期可以用“大事件”法则，中长期可以串联主线。拔高定位，直接避开在当前价值链的争锋，自己以企业最关心的指标为目标，以内部孵化的思路去新开辟一条价值链。

2）通过塑造专业力量在博弈中取得进展和认同

具体的冲突中，可以使用驳斥对方的观点，以及寻找自己观点支撑的办法来进行有理有据的沟通。日常的积累中，要努力做到比业务还要懂业务。

3）非理想情况下可以做的

放下情绪，正视最后的结果。

一起复盘。

做心中有光的产品，正能量的产品，你就会在不顺中先反省自己，改变自己，从自己出发去寻找出路。

这是我从前后两位领导身上学到的道理，也和你共勉。