2018年4月，在产品立项期间写下一篇文章《产品立项的形状》，主要是阐述了立项过程中，项目组对项目对标、项目目标、实际能力的各种认知。最近回顾了几个立项材料，却发现了一系列更为深入的问题，即如何选取产品的对标物，有些产品经理为了说明自己的项目重要，或者为了强调立项的必要性，就开展了广泛的旁征博引。列举一些情况如下，引以为戒：

1、目标是软件产品，但是对标物选择了云计算服务。这两种产品的形态有很大的差别，软件产品会重视丰富的功能，会考虑安装部署，会考虑兼容性，会考虑运维监控。但是云服务不一样，云服务考虑等多的是简单易用、API等等，虽然云服务也涉及到安装部署，但是这都是难以对标的。

2、对标陈旧的产品。众所周知，即便是大公司，也会在风口看错方向。比如Oracle，就曾经发布了Hadoop一体机（OEM原Cloudera的软件），但是这款产品和客户需求匹配度不高，并未获得规模应用。2017年后不再发展。因此与这种产品对标，并作为立项需求就不科学了。

3、对标一系列产品。产品之所以成为产品，而不是定制化项目，其主要原因是产品是标准化程度很高的系统，往往聚焦在一个或者少数几个单一的功能点，产品功能的扩展，往往是通过产品之间的组合而成，这就类似Office。但是如果用一个集成的产品产品来对标Office就不科学了。

4、多对多产品对标。在业界，我们可以看到一些非常模糊的产品。特别是大数据类产品，往往把所有开源大数据放在一起，形成了一个复杂的开源内核。这类系统，我称之为开源集成产品 – 其核心价值在于把一堆开源软件组合在一起，变得可用。考虑到组合很多，会带来很大的集成问题。如何与这类系统对标呢？重点来了 – （方案1）要抓住其主要方面，对标开发；（方案2）100%对标，做的和竞品一模一样。

5、私有云和公有云对标错位。在开发中间件类产品的时候，一定要考虑好到底是用于公有云，还是私有云，到底是要和IaaS集成，还是要和PaaS集成。看到过好几个类似的立项。对标的时候对标公有云，心里想的是又支持公有云，又支持私有云，又支持IaaS，又支持PaaS，结果后来做不出来了。云计算的兼容性问题比传统软件多少还是要简单一些，但是工作量依然很大。

6、局部对标。仅仅选择了对自己有利的竞品特性来对标，这样就显得自己工作有了亮点，但是由于不全面对标，造成了功能不连续，特性不完整，难以形成一种全面的观察。

产品经理或者研发经理，往往会根据对自己汇报立项有利的方式来对标，会造成研发方向的错误。一个周期的研发，可能就浪费了，或者形成一个不完善的产品，并且可能对上级领导造成误判。

要消除这种问题，主要方法是加强专业化评审，一方面可以设置总部级别的产品管理专家，侧重基础能力的评审；另一方面，利用专家组开展评审；还可以通过各个条线的产品经理交叉评审；通过QA审查整个评审环节。

相关文章：

1. 产品立项的形状