在做了几年的互联网产品后，尝试了2b，2c，商业化，中后台，工具型等诸多维度下的产品方向后，越来越多的发现，就产品经理这个岗位而言，我们开始承担平衡者的角色。
本文将从产品解决方案设计与实施的矛盾，来讨论产品是如何在其过程中体现平衡之道的。
-------------------------------
由于社会化生产协作的需要，我们一方面，在工作流程上，处在业务，商务，运营，市场，销售等团队的下游，同时也是交互视觉研发测试等团队的上游；另一方面，我们在工作内容上，往往也成为了需求项目或是产品本身的第一负责人，在很多团队，产品甚至的职责本身，产品也本身包含了项目经理的角色，当组织范围足够大之后，更多的我们开始面临，多个产品团队的协作，多个业务线的协助，中后台支持团队的协作等等，偌大一个项目，动不动也就牵扯到了十几个业务线，七八个中台服务，甚至在某些互联网巨头组织内部，还可能会跨多个事业群，通力协作以达成项目目标。
因而，我们说产品经理在日常工作中，无可避免的需要在各方之间进行平衡，需要在各个视角下进行平衡，最终找到一个问题的最优解或是满意解。当组织范围越大，项目复杂度越高，涉及团队越多，这种平衡就显得明显。更准确和真实的描述，可能不是协作，而是各个独立团队的利益成本博弈。
当我们无法从战略层面，强势进行需求目标推进时，各方必然会陷入局部目标的考量和评估中, 又或者是尽管有集团在战略层面的倾斜支持，但在实际落地上，所谓的协作关系，自然也会演化成组织内的利益分配、资源内耗、撕逼扯皮。这种情况非常真实的发生在今天的每一个互联网大厂，项目发起方，通常是主产品发起方，开始举步维艰推进着一个可能涉及到几百人的项目，诸多合作方其实并不关心的需求，因为在局部视角下的利益低程度相关性，冷漠和阻力也就成为了最为真实的情况。
理所应当的，当一个诉求，与合作的某一团队利益完全无关，那这种冷漠在局部视角下，恰恰已经是资源配置的最优解了。但当目标在更高层面，有这深切意义和价值，但在某些局部场景下，又无法凸显出来的时候，这种本质由组织结构带来的弊病，就无法隐藏，而这种根深蒂固于组织中的问题和矛盾，绝不是一两个场景下的诉求，就能够顺带解决的。就像纵使是古往今来的圣人一般，也难以改变环境，组织结构的变革何其困难，又会触碰到多少既得利益者的蛋糕，那么，我们该何去何从呢？
最常见的处理方式，便是上升处理，于是组织内，有了各种各样的撕逼和上升会。不得不说，这种组织内部随着时间演进演化出的处理方式，确实目前为数不多高效且可实施的解决方案。这种处理方式的本质，在于将原本就是全局问题的部分（这种全局问题，既可以使纵向协作流程的全局，也可以是横向其他产研团队的全局），归还到全局的领导者本身，因此，就实际情况而言，往往也是最有效的。
于是，可怕的事情出现了，我们迷恋于这种处理方式，以至于，在很多时候，忽视了这些所谓的全局（高层）问题，是项目需求问题本质带来的，还是解决方案带来的，我们提出了一种基本忽视了诸多合作方价值诉求 的方案，给合作方团队或是 上下游带来了高昂的成本和难度，但实际上，业务方的价值和意义却十分有限。
举一个多团队协作中为满足业务要求互相撕扯的例子，
业务需求方，希望能够在某个大流量场景，进行商品文案化展示时。尽管商品推荐本身，是非常成熟的能力，但是在进行商品信息转文案信息话信息加工时，由于部分业务特殊优惠限制，文案拼参等特殊处理的工作，接口服务的tp999本身压力较大，难以满足前端页面的诉求，在这个场景下，考虑到用户体验，又必然对推荐出的商品sku进行必要的库存校验。上述流程涉及多个上下游团队，满足前端性能要求，各方处于自身难度和利益，均不愿做优化和让步，因此该需求难以推进，此时，产品平衡业务方和多个研发团队的利益矛盾，讲库存校验调整为全国库存校验并稍作缓存，通过一定程度的需求降级，达到了技术和业务实现的平衡，避免了无尽的撕扯升级。
在举一个技术成本资源的例子，
业务方希望用户能够查询到，业务线为用户提供的各种优惠明细信息，该部分数据底层存储在订单中台，作为也业务平台如果要存储几十个亿级别的订单数据，则需要在向中台数据存储部门申请存储资源，该流程繁杂冗长，切申请量级较大，业务价值有限，基本不可能拿到期望量级的redis存储资源。这时，我们回到业务目标的最初出发点，尝试需要解决的问题，解决用户不信任权益在订单中实际产生价值的问题，露出全量订单明细固然是一种合理的解决方式，但代价过高。这时，运筹学思想下，我们放弃寻找代价极高的最优解，而是寻找满意解。严格意义上说，这种方式无法解决部分吹毛求疵用户的需求，但产品解决方案本身，就从来不应该被定义必须完美解决所有问题，当我们能够以高效的方式解决多大多数核心问题时，就以足够，换句话说，这才是解决方案的本质，在已有资源的限制下，去寻求问题的高效解法。于是，我们选择给用户露出近3个自然月的订单，极大的减少了存储资源，甚至不再需要额外的存储自愿申请，问题就得意解决了。
由此可见，产品解决方案本身或是产品设计本身，就是在以高效可行的方式，去分析和解决本质问题。解决方案不一定能够解决所有用户（客户）的所有问题，解决方案也往往不是完美最优解，但解决方案却必然是诸多约束下能够解决问题且能达获得可行满意解。
----------
后续，会在讲一讲，产品解决方案，是如何在业务目标和用户价值之间，寻求平衡的。
