首先，这个平衡点肯定是模糊的，定性而非定量的。而且偏主观，所以大家一般都会说 “拿捏一下” 平衡。在对方提出与自己不同的意见时，妥协之前我们需要尽可能地进行一番就事论事、有理或有据的辩论。然而，并不是每个决策点都能看出不同方案的明显差距的。所以会出现双方都有一定的道理，但谁也说服不了谁的情况。说白了，就是大家的侧重点不一样，导致最终的选择也不一样。面对无法通过辩论而达成一致的情况，有以下几种解决方案：1. 双方做进一步的理论或资料调研，再次 PK2. 通过纸上原型、展示页面效果图或可交互 Demo 进行用户测试（User Testing）3. 两套方案都开发，投放至线上进行 A/B Testing4. 一方主动/被迫妥协。
我个人本身也是产品经理，大学毕业后一直在创业公司工作，没有过BAT等大公司的工作经验，不知道大公司如何运作。但是在我们这些小团队，我个人工作几年来的最大感受，就是要珍惜资源，尤其是时间。作为产品经理，你提出一个功能，提出一个需求，提出一个发布计划，本身就是对团队资源的一个分配。我所有做的努力和学习，都是为了让这个分配达到最合理的状态，把每一份资源都用在刀刃上，也就意味着，我必须清楚知道，我们目前要做的事情，是不是能够被市场、被用户认可，给他们创造价值从而让我们获得回报。如果我拿捏不定的，我可能会换一种做法，自己用更多的低成本的试验方式，来进行测试和验证，只有我确定的，我才会放到发布计划中来。因此我必须清楚认识到，每一个解决方案背后所要付出的成本，权衡投入产出，这样才能保证我们做事情事半功倍，因为我们资源少，更需要把资源集中在最能够产生回报的地方，如果我们拥有专门的产品设计部门或者UED部门，我们也想把产品设计、用户体验做到极致，但是我想这个东西，更适合资源过剩的团队来操作，对于我们创业团队，抓产品价值和需求，回报要远远大于完美的用户体验。
说实话，很多产品经理之所以没地位，是因为自己太差，甚至自己都不知道自己很差，以为挂着产品经理头衔，就可以掌控整个产品的开发节奏、需求计划，口上常常挂着用户体验，实际上什么都不懂。先说说程序员和产品经理之间的问题，程序员会和产品经理有冲突，除非这个程序员实在是消极怠工，否则大多数时候都是产品经理的问题。首先一点，好的程序员，跟你产品经理一样有理想，甚至比你有理想，他们也想做好的产品，做好的功能，做一些独特的有竞争优势的功能，而不是在看了你的8000字的需求文档后，发现TMD这不是XX对手的那个功能么，又或者看完只有一种感觉：这TMD有谁会用这个玩意。然后程序跑去跟你沟通，问你这玩意到底是什么东西，你跟他说，“啊，这个是老板那边要的，很急，周一上”，“这个功能对手已经有了，我们要马上开发，否则产品优势就没有了”，“根据百分之XX用户反馈的，他们就是要这个玩意”，“运营那边提的，我也不清楚”……之所以有产品经理和程序员的分工，不是产品经理逼格较高，天生要站在什么用户角度、战略角度指挥程序员，而是程序员的工作，太需要专心，太需要钻到细节里去，而钻入技术细节，就很难有精力再去顾及其他的事情，但这个不代表程序员就没想法，没战略眼光，不懂产品。产品经理的工作，特别是跟开发靠边的这些工作，本身就是要为程序员省时间，你要为他们，把所有的需求转化为能够实现的、有效的解决方案，要把所有的需求给排好合理的优先级，就这两个事情，就需要产品经理很大的功力。
