产品经理工作法则二：不要轻易的向别人承诺和不要轻易的相信别人的承诺
作者:汤圆 |2008-3-17 19:20:36| 原始出处:原创 已阅: 168 说出去的话，泼出去的水，收是收不回来了，如果这些话是些无伤大雅，不伤筋骨的，倒也无大碍，但是作为一个产品经理，在工作中就要格外注意了，每一句承诺都一定要三思而后行才可以。
大道理就不说了，大家也不爱听，就说一个最直接的原因吧。
大家都知道，产品经理的工作有两个明显的特点：
1、横跨业务部门开展工作
2、没有直接业务管理权力
前者要求产品经理必须在资源一定的情况下去做事情，而后者则似乎和前者产生了矛盾，这样就会给产品提出一个非常现实的问题，就是“公司给我的每一个资源，我该如何合理地使用”。
我来举个例子说明一下。
我曾经在一家公司负责过一个产品，是做软件的，当时团队的配置是一个项目经理，负责产品研发的部分，手下有五个开发人员，一个UI设计师，一个市场部的同事，负责产品后期商品化的工作。
不瞒大家说，当时我经验有限，对于从整体把握产品进程还是有些不够成熟，结果问题出现了。
在产品进程进入到后期，也就是产品的主要功能都已经完成，在我看来，可以考虑产品的商业化工作了，并且市场那边也一直在催，等着我这边的消息来做市场策划，于是我毫不犹豫地通知市场部门，可以进入到产品商业化阶段并开始逐步推进。
这个过程我没有和研发部门进行沟通，并获得他们确定的反馈，因为我个人非常坚信研发部门肯定会按时完成，但是让我没有想到的是，一个问题出现了，因为公司另一个产品突然出现紧急情况，需要抽调两个开发人员去支持，于是，我这个团队中本来需要五个人完成的开发现在分配到了三个人身上，虽然进程还在走，并且已经进入到了后期，但是五个人的工作分配到三个人的身上，并且还有一点严重的是，当时我们公司的研发不是太规范，研发人员之间的交流很少，最要命的是，公司并没有对编码规范有明确的要求，结果导致这三个哥们在还得花时间去读那两个人的程序，这从客观上又耽误了进度。
研发进度的延误又直接导致了市场部门推广计划的重新制定，对于我个人来说，就把我搁在了中间，两头不好交待。 这个例子不是要去说明如何进行产品项目的进度控制，而是从另一个角度来说明本文的主题，即“不要轻易的向别人去承诺什么东西，即使是在看似万无一失的时候”。
我们来分析一下这个案例。
1、之所以我会向市场部门有所承诺，完全是基于我对我所负责产品的进程的了解之上，换句话说，也就是我对我这边的资源很比较清楚，例如案例说到的团队配置，产品项目进度以及后期计划等。
2、我这边的资源是公司提供的，而公司的资源是有限的，尤其是在多个产品并行的时候，公司绝对不可能保证给你的资源从头到尾都会一致，例如案例中说到的公司因为另一个项目紧急而抽调我的产品团队中的人手的情况。
3、正因为资源使用的不确定性，因此，产品经理在做出每一个决定的时候一定要慎之又慎，三思而行才可以，案例中我就是在这个上面犯了错误。
就是因为我的眼光只看到了我手里的这些资源，而没有看到公司整体资源的不确定性和流动性，说句不好听的话，产品经理手中的资源只有当前时，永远不会有将来时，公司会在任何时候把资源调配到他认为最紧急的产品上去。
因此，从这个角度来看，产品经理永远不应该有承诺，有的只是基于以往数据的结果和总结，而这种结果和总结通常不应该具有承诺的性质。
再说两句废话，因为这个事情，我们这个产品团队很不爽，向上面提了一些建议，还不错，上面基本上都接纳了，并逐步开始建立公司自己的产品管理流程和规范，而我也不再轻易地向其它部门承诺什么，而只是提供给他们全面的产品进度情况，然后一起来评估后续工作。
有的朋友可能说这是产品经理不敢担责任，我认为这不对，这恰恰是为了少发生失误，因为我想不会有朋友盼着自己负责的产品总出现问题吧。
这就又回到了前面说到的两个工作特点上。
首先，产品经理要横跨部门工作，横跨部门工作最容易出现的问题有三个：
1、信息的衰减
2、成本的变动
3、需求的变更
只有把这三个问题的影响减小到最低，才能保证产品最终结果的良好，那么，靠什么来保证呢？只有两个，一就是资源，二就是时间，如果在时间一定的情况下，只有靠扩张资源来保证产品的结果，但是前面也说到了，任何一个公司资源都是有限的，并且还是变化的，因此，时间就是常量，资源就是变量，如何控制好变量，对于产品经理来说，是非常值得探讨的，如果时间和资源都是变量，那么，困难就更大了。 因此，之所以告诉大家产品经理千万不要轻易的承诺什么，就是因为产品经理所要工作的环境始终是一个动态的，在变化的过程中去保证什么，往往是不客观的，就如同天气预报，我们永远不能通过今天的天气数据来准确得出第二天天气的情况，因此，它只能叫“预报”。
再简单说一下产品经理千万不要轻易相信别人的承诺。
这里说的不要轻易相信不是指不让大家去信任产品团队的成员，而是说产品团队中的成员如果向产品经理承诺了什么，一定要自己多想想，是否应该按照他们的承诺去做下一步的工作。
我在现实的工作中，经常会遇到这样的情况，有一次，我和一个研发团队的成员商量一个功能的实现，我把所有的功能细节都和他描述清楚了，并且我当时也并不想着让他立刻就给我回复，因为一方面是我想让他更深入的想想，尽量把研发层面的细节想好，另一方面也是因为我对技术不是太精通，生怕我有没说到的，或者没有说完整的而影响他的解决思路。
但是，他在听完我的描述后，立刻就说“这个功能实现起来不难，有三天就能完成”，还好，我也算是久经沙场，并没有立刻就拍板说“ok，就三天时间”，而是说“咱们再好好想想，这个功能比较关键，咱们尽量做到一次搞定，这样吧，明天咱们再碰一次，确定一下”。
结果第二天，我俩又碰的时候，他说，“我回去看了看资料，也和我们头说了一下，我们头的建议是三天时间有些确实有些紧，如果是五天的话，就应该保险多了”。
之所以会出现这种问题，我分析有两个原因，一是因为研发人员的经验问题，有时候只看到PRD的时候，尤其是一些经验不足的研发，他们会感觉很容易就能实现，二是因为有些产品经理的PRD做的不够细致，对于一些关键性的描述不够清楚造成的。
对于前者，我们没有太多的办法，最好的办法就是熟知每个研发人员的能力，然后在和具体的人讨论的时候不要催着他们给你承诺什么，让他们多想想，对于后者，就是我们产品经理一定要加强PRD的撰写能力，把一个东西描述清楚不是那么容易的，尤其是把用户大白话似的需求转换成可以让研发人员的思维能接受的文字、流程，也是个学问呢。
以上是直接的原因，有一个根本的原因就是前面讲到的“没有直接业务管理权力”。
这个就很简单了，你管不了他，他就可以不向你负责，不向你负责，他就可以随意的承诺一些事情给你，即使出了问题，你也无法直接对他进行处罚，即使是他的直接领导对他进行了处罚，但是对你来说已经没有任何用了，因为你的产品已经因此而受到了影响，产品受到影响，第一责任人必定是你，他只能是间接责任人。
老大们会质问你，“你作为产品经理，为什么想的不全面些？为什么不和他沟通好？为什么你自己不想想？是你对产品熟悉还是他对产品熟悉？„„”
你根本无法回答，因为你的回答很容易让老大们当成你是在为自己辩解。
怎么办呢？没有很好的办法，坚持一点就可以了，自己多想想，让你的产品团队也多想想，不要咄咄逼人，也不要优柔寡断。
以上说了这么多，有没有一个好的解决方法呢？应该还是有的，谈不上方法，就是一个思路，大家参考一下即可。
1、一定要建立规范的产品管理体系和流程。这个不多说，谈起来就太大了。
2、要全面的看待资源。我们常说，产品经理要有全局观，这个全局观其中重要的一项就是对资源的全面把握，不但要知道自己所负责的产品的资源情况，更要清楚整个公司的产品资源分配情况，公司是一盘棋，每个产品就是一个棋子，动一发而牵全身，动哪个，不动哪个，这就是公司的战略，我们所有的工作脱离不了这个。
3、对团队成员要有足够的信任，对成员的承诺要有足够的怀疑：信任是为了做好工作，而怀疑同样也是为了做好工作，怀疑不是否定，不是俯视，而是为了减少工作中的失误，我们是产品经理，对我们的产品负着第一责任，一个严重的失误就可能使我们的工作化为乌有，使公司的投入灰飞烟灭，公司承受不起，我们更承受不起。
