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