最近看了一篇其他云计算服务商的产品手册，涉及到对运营维护类产品的产品功能规划，这类产品是很常见的产品，我们也有类似的产品，例如BC-OP用于运营管理，BC-DeepWatch用于客户应用运维的服务化，BC-OPS是系统层面的运维。但是看到这个竞对的产品手册，发现里面有不少功能是我们没有的，而且更主要的是，其一级功能和我们的明显不同，看上去竞对的某些一级功能设计更为合理一些，在功能名字方面也显得更为合理和贴近客户。但是为啥我们的产品就没有对上标呢？我来深入的分析一下：

看上去最主要的原因是：我们在产品对标的时候采用了“以我为中心”的对标思路，这个思路的出发点是假定我们的产品一级功能是无需变化的，因此对标的重点就放到了二级、三级功能方面了，这样看来，很有些丢了西瓜捡芝麻的味道。用同事的话就是“对标了果子，没对标树干”。

究其根源，还是产品经理的话语权太小了，产品经理没法撼动研发经理的决策权力。调整功能的级别越高，对代码的改动也就越大，研发经理也就越不会同意调整。因此产品经理就只能缩在一个有限小的空间内活动，这个活动范围取决于研发经理的资源和日程。考虑到运营类产品的研发任务是不会停止的，而人也是有惰性的，改变已有的可用功能需要付出的决心决定于工作量的大小。

其二，还有一个“试错容错”的问题，如果研发经理下决心调整高级功能，那么难免会有缺陷，那么就会遭受到投诉或者故障，如果运气不好，遇到批量投诉或者重大故障，这样肯定会影响团队的绩效，这也让产品经理和研发经理都会怀有多一事不如少一事的想法。

通过上述分析，可以发现产品是否可以演进的好，并不是表面上简单的产品管理问题，还有其他深层次的原因。一年多以前曾经写过一篇文章，《产品管理：错误的对标分析》（http://www.brofive.net/?p=5357），本文是这段时间之后，对前一篇文章的深化。