本文将从产品解决方案中，涉及到诸多参与方的价值诉求矛盾，来讨论产品是如何在其过程中体现平衡之道的。
-------------------------------
如果说产品方案的设计，从目的上，是需要考虑如何在用户和业务之间寻找价值的统一，同时解决用户和业务面临的问题，那么从实施上，产品方案的落地可行，则是需要将诸多服务提供方组织协调到一起，共同协作达到既定的目标。
由于社会化生产协作的需要，我们一方面，在工作流程上，处在业务，商务，运营，市场，销售等团队的下游，同时也是交互视觉研发测试等团队的上游；另一方面，我们在工作内容上，往往也成为了需求项目或是产品本身的第一负责人。
组织的复杂性，让协作成为了几乎所有大公司都面临的问题。产品要对接多个产品团队，多个业务线，以及中后台产研等团队的协作，牵扯到了十几个业务线，七八个中台服务是非常常见的，甚至在某些互联网巨头组织内部，还可能会跨多个事业群，通力协作以达成项目目标。
产品经理在日常工作中，无可避免的需要在各方之间进行平衡，需要综合考虑多方利益和诉求，进行平衡。如果说产品目标，是用户价值和业务价值的统一结果，那么在既定的产品目标下，具备可行性的产品方案必然是各服务提供方的价值统一。
协作本身，是各个团队的利益-成本博弈。公司内多个部门间，已经演化出了利益分配、资源内耗、撕逼扯皮等诸多问题。这种情况真实的发生在今天的每一个互联网大厂，项目发起方，通常是主产品发起方，开始举步维艰推进着一个可能涉及到几百人的项目，诸多合作方其实并不关心的需求，因为在局部视角下的利益低程度相关性，冷漠和阻力也就成为了最为真实的情况。
当一个诉求，与合作的某一团队利益完全无关，那这种冷漠在局部视角下，恰恰已经是资源配置的最优解了。但当目标在更高层面，有这深切意义和价值，但在某些局部场景下，又无法凸显出来。本质上，这是组织结构的弊病。这种根深蒂固于组织中的问题和矛盾，牵涉诸多既得利益者利益，出于维稳和ROI考量，组织变革无疑阻力重重。最常见的处理方式，便是上升处理，于是组织内，有了各种各样的撕逼和上升会，虽有扬汤止沸之嫌，但好歹也一定程度上缓解，或是偶尔解决了一些问题。
由于各个细分组织的定位和目标各不相同，因此解决该问题的价值对各个合作方而言，也是各不相同的，甚至对于个别团队而言，可能是与既定组织目标相背离，或是无关。这时，实际利益矛盾的本质便是组织顶层设计的原因，因而上升处理，在解决的问题便是调整了现有难以支持公司业务发展的价值评估标准，得以让真正有意义项目得以推进。它将原本就是全局问题的部分（这种全局问题，既可以使纵向协作流程的全局，也可以是横向其他产研团队的全局），归还到全局的领导者本身。
上升决策，是在借助高层决策者力量来解决一些难以缓解的组织矛盾，更多时候，我们还是要学会借助合作方的力量，来达成自身的业务目标。在复杂组织内，基于多方已有能力，进行产品可行方案设计，并完成目标是业务产品经理的工作常态。
作为产品，我们终究要去将这个需求，在阐明对用户或是客户价值的基础上，也让各个服务提供方的利益价值和付出成本相一致。
举一个业务合作的例子：当新业务团队，需要基于当前已有的业务模式，来提供增值业务服务时，往往会遇到一些与其他业务或是运营团队在利益成本上的冲突。在电商交易流程中，由会员团队来为付费会员用户提供一些额外的券，那么对于日常维护券的商家和采销，在设置出了用户适用范围标签的基础上，在进行这种券对应子权益业务线打标的工作，就不是采销或是商家期望的工作范围了。尽管这种细分业务的打标，对业务后续的垂直场景券权益服务非常必要，但对于采销或是商家来说，确实并不带来额外价值的人为工作。这样由于业务方的角色不同，会员业务团队和采销或是商家的运营，在协作和工作范围划分上，就出现了分歧。这个时候一味强迫外部团队，往往是徒劳的，依旧需要对现有服务流程和工作范围进行调整，把这部分业务工作调整到会员团队侧。毕竟，谁受益，谁才有动力去做日常的维护，多业务团队的协作模式，势必是需要调整的，由此带来对应的产品功能服务，也自然需要进行流程重构和功能新增了。
再举一个产研合作方的例子：为实现业务产品目标，我们往往需要多个产业团队协作，基于已有的中台基础服务，进行前台业务服务的建设。对于订单基础数据而言，该部分数据在订单中台维护，但业务侧需要基于这些生产库数据，进行业务逻辑的加工处理，这种场景下，往往中台团队，不会倾向于处理任何业务个性化逻辑。这是可以理解的，个性化的业务应用诉求，与中台抽象，高效，能力沉淀的定位并不相符，且往往面临着已有线上服务框架的局限性和拓展性问题，改造成本和风险均较高，且由于业务团队往往背负KPI压力，需要敏捷迭代迅速支持，因而迫于无奈只能由业务的产研团队自行承接，由局部的利益获得团队自行处理。尽管上述结果在既定组织架构下，往往是最合理的处理方式，但由此带来的结果是，一方面业务产研会面临诸多基础工作的研发和资源成本浪费，另一方面，多套相似服务难免会存在逻辑冲突的风险，且业务团队往往在处理这类问题上，并没有充足的经验，就更加容易出现问题。项目草草上线，后续问题重重，中台一方面无法支持一线业务，一方面又在焦虑的论证自身价值。这也是为何阿里如今又要拆分中台了，合久必分，分久必合，实乃正解。
