如何选择正确的产品驱动模式？

前段时间，个人写了一篇《产品经理模式之弊论》，陈述了产品经理模式，即“由产品经理驱动产品团队做产品”的问题，引起了很多人的探讨。其实本问题可以进一步延伸，包括：互联网团队都在以何种方式，改进或孵化自己的产品？哪些方式适合哪类职能，具备哪些特质的人驱动？互联网产品团队应该采用何种模式，又如何兼容多种模式？以及，如何用好“产品型技术”人员等等。

根据产品所处的阶段，以及改进的粒度与方向，互联网产品团队的工作可以分为产品的功能性改进，非功能性改进，以及新产品孵化三类。

“功能性改进”：

（1）抄袭与模仿：互联网产品的抄袭与模仿往往被人诟病，但中国互联网环境的特殊性，已经使得它们成为中国产品改进中最重要的方式。诸多互联网团队都像狼一样紧紧盯着对手与国内外同仁，拷贝产品模式，快速复制新产品，借鉴已有的产品改进经验与思路。成功的案例已经多不胜举；

（2）产品功能的“微创新”：即通过对用户需求与行为的深入理解，在不改动产品的整体思路与定位的前提下，主动创造，改进产品的局部功能。“微创新”也是中国互联网产品的主要改进方向，以求以每一步微小的加分形成大的加分，并在某一点或几点改进上抓住用户的痛点需求，使得用户体验进一步提升。例如360安全卫士，通过操作简化将杀毒软件的使用门槛大大降低，成功攻克中国完全红海的安全软件领域，例如QQ通过表情、QQ秀、好友印象等功能改进压倒MSN，例如百度通过直达优化，服务引入等改进使得TOP词效果优于技术领先的谷歌等等；

“非功能性改进”：

（1）与功能性需求无关的改进：例如产品的运行效率、流畅性与稳定性等等。它们与用户需求无直接关系，但会直接影响其满足情况，是用户体验中必不可少的一部分，甚至可以说是产品成功的基础。这一类改进，可以独立于产品经理，由技术人员直接负责；

（2）功能性需求的效果改进：例如搜索引擎的排序效果，广告系统、推荐引擎的展示效果等等。它们与用户需求的满足情况有直接关系，历来都是兵家必争之地。在《产品经理模式之弊论》中，阐述了这一类改进被产品经理完全主导的问题。

“新产品孵化”：

（1）设计主导型新产品：例如Facebook,Twitter等。这些新产品的涌现与互联网用户环境有关，但与技术无直接关系。它们往往来源于创始人的奇思妙想，来源于一个小构思的不断深化。很多时候，这一类产品的衍生不像是一门科学，而更像艺术，没有规律可循，只能事后被戴上“社交网络”、“社交媒体”等帽子；

（2）技术驱动型新产品：例如初创搜索引擎、推荐系统、风靡当下语音类应用等等。这些产品的理念往往很早就存在于科幻小说、电影、论文与原型系统中，但是一直等待基础技术成熟后，才达到应用层面。这里的“技术”是广义的，包含理论方法与数据等；

非抄袭的“新产品孵化”并不会频繁出现，每次出现都将是一次产品的波澜，甚至导致产业革命。如上的两个分类，其实也并没有完全的界限。部分新产品的衍生本身就融合了设计与技术驱动，例如谷歌眼镜。新产品孵化还有如下一种：

（3）抄袭主导型新产品：在中国互联网环境下，新产品的独立创造并不多见，更多的是更改某些特质后的复制，或者对竞争对手的直接模仿；

那么，互联网团队的参与者又有哪些？一般而言，经典互联网团队成员通过职能分工，可以分为产品经理与技术人员两类，前者负责产品设计，后者负责功能实现。从能力方面，产品经理更接近用户需求，更具备社会化思维，而技术人员则专于工程实现。

由上文不难得出，产品经理适合驱动广泛存在的产品功能性改进，包括抄袭模仿与微创新，以及抄袭主导型新产品孵化。“功能性需求无关的改进”本身即可以独立于产品经理职能。而“功能性需求的效果改进”，原创性新产品的孵化，尤其是技术驱动型新产品的孵化，则并不适合由传统产品经理主导。这些工作必须要主导者兼备产品与技术两方面的能力，即所谓“产品型技术”。具备技术背景的产品经理也比较适合承担这些工作，但一旦职能转化为产品经理，就即意味着不能接触技术平台，不能看到原始数据，这将大大降低其能动性。

在产品驱动模式的选择上，首先要考虑自己产品的特点，如果产品的改进方式仅仅涵盖其中的某部分，例如技术已经完全成熟，或者技术本身与产品需求割裂，那么采用产品经理模式完全没有问题。如果是个性化广告系统等用户需求满足情况完全可以被CTR等指标量化的产品，由技术人员（研究人员）主导也没有问题。但搜索引擎、推荐引擎等产品，既包含有产品功能性改进也包含与需求直接相关的效果改进，在模式选择上则并不那么简单，直接完全由产品经理主导，很多情况下并不合适。

团队分工架构是非此即彼的选择，多数情况下，由产品经理主导也更加合适。但工程师关于产品层的推动作用往往暗含巨大的力量，那么有没有可能兼容两种模式呢？个人认为是完全有可能的。首先需要一个兼备技术与产品能力的整体负责人，能够正确的判断工作由何种职能主导更加合适，并能够统筹技术人员关于产品的改进构思；其次，团队要小，只有小团队，才有足够的灵活性，灵活调配分工，也才能够使得技术人员产生产品层面的构思。产品经理与技术人员更加应该通力合作，相互理解，深刻认知自己的职能、能力与特质，在不同情况下，主导不同的改进方向。

然后，还有一个问题：“产品型技术人员”应该如何定位，如何发挥自己的作用？我看过很多怀揣产品梦的技术人员，在现代精细分工导致的大团队中郁郁不得志，甚至为了实现自己的产品梦想，转型当产品经理。而对于明确分工的大中型公司而言，这一类兼备两种能力的人的确难以用好。另一方面，我又看到无数产品的改进工作以及新产品的孵化工作，没有选择对产品驱动模式，甚至因为没有“产品型技术人员”，退而求次，直接导致了产品质量不佳，延期，甚至失败。这形成了令人扼腕叹息的对比。当前的“大数据”时代，其实是一个由数据与理论方法驱动技术成熟的时代，由工程师驱动产品改进将更加重要，这类人用在合适的点上，将起到画龙点睛的作用，互联网公司，更应该重视此类人员。对于“产品型技术”自身，也要挑选好职能，领导与团队，才不至于放弃自己的梦想。

注：本文系《架构之争,体制之惑》系列文章的第三篇，欢迎交流！