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

Mon, 03 Nov 2014 15:02:47 GMT

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

“功能性改进”:

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

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

“非功能性改进”:

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

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

“新产品孵化”**

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

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

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

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

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

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

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

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

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

产品经理模式之弊论

本文为《架构之争,体制之惑》系列文章的第一篇,作者王小科笑笑

产品与技术人员在合作中,因为思维方式与视角不同,本身便存在着可能造成问题与矛盾的地方。

但实际上,除非遇到非常糟糕的,不善交流并不善站在对方角度考虑的产品与技术方,一般的产品与技术相处还是很融洽的。尤其是当产品方是漂亮妹子,技术方是技术宅男,两者之间更多的情况是水乳交融(起码我当下在的团队是这样哈^_^)。
本文观点是,产品与技术分离的团队体系架构、完全由产品驱动的任务推进方式,本身可能导致问题,需要身处其中的人警醒,需要团队的负责人明了。
产品与技术的职能分离,是行业发展的必然结果。原因一是业务难度逐渐增加,从业人员期望专注于部分职能,从而提高效率;另外则因为个人能力的单一化,一般人并未受到过两个专业领域的训练。**产品与技术所需要的能力与思维方式有相当大的差异**,所以理所当然,对产品与技术进行了拆分。
所以,**诸多互联网公司形成了这样的模式。产品方告诉技术方,应该怎样改进产品,技术与产品沟通具体的解决方案。技术方进行解决方案的实现,产品验证效果,如此迭代。**绝大多数情况,这样的拆分的确有利于团队竞争力的提高。然而,职能划分的**副作用在很多情况也比较明显,其中核心问题在于部分创新能力的缺失**,我总结为如下几种:
**1,技术革新型创新:**
** **
假设当年福特雇佣了一个产品经理,让他确定用户关于出行的需求,他能得到什么呢?他拿得到的,可能只是一辆跑得快外表拉风的马车需求而已。产品无法考虑到“汽车”这个概念,这个概念的创始人必须为技术人员。为什么呢?
我们一直说,**技术应该以产品的思维去考虑问题**,但是产品则不合适通过技术的视角考虑问题。但是在高科技领域,在技术革新的阶段,产品形态的创新首先需要技术壁垒的攻克,所以产品思路与技术几乎完全融合在一起。**根本性的技术革新,甚至由此带动的产业整体革新是必然是由具备创新能力与意识的工程人员推动的。所以,无技术基础的产品人员,更加适合推动技术架构与思路已基本确定的产品微创新与表层创新。**
**2,高技术深度产品改进创新**,或者说以逻辑思维为主导的产品改进创新:
一般而言**,产品的思维更多是柔性的,感性的,而技术的思维更多是理性的,逻辑的**。然而,很多产品的某些方面,理性与逻辑思维占据主导。产品方容易看到表象,但是无法分析深入,无法看到内在,我以“搜索引擎排序”这项工作为例。
例如,产品容易提出,排在第一个的重要性比第二个大,第二个比第三个大。但是,并不能奢望产品独立的提出DCG与NDCG模型。产品容易提出,你所关注好友喜欢的东西,往往你也喜欢,但绝不能奢望产品提出UserItem推荐模型。产品方可以提出Case,制订初步的测评策略(甚至这项工作,也应该由技术方主导),但是,如果要让产品放提出具体的排序权重计算方案,那几乎是不可能的。
产品方,本身便不应该承担这样的职责。虽然从职能划分上,这些更偏重是产品方的工作。负责排序改进的技术人员,必须通过产品反应的表层现象与基础思路,不停深化,看到深入的用户需求,看到背后的问题。如果在这些问题的解决方案上,被产品主导,不主动思考,就容易被表象赶着走,始终无法为系统带来实质性提高。这实质是技术方的失职。
另外,搜索引擎排序等效果改进工作。是一个细化排序因素,并根据不同情况,归并排序因素的过程,是一个自底向上的过程。从完善排序因素到呈现在用户体验,周期很长,类似于垒塔,一步步走坚实才有好的最终效果。完全由产品主导,意味着过分的结果导向,会很容易打破这个过程,导致基础不牢,所以在这个过程中,需要两方折中,甚至说,更需要技术主导。
**3,产品架构、技术架构创新:**
** **
产品方往往生存在工作流程的起点与终点。工作由产品推动,并由产品验证。然而,真正跟产品、UED、运维、测试等所有环节都进行接触,并深入了解系统架构的,更多的是技术方。所以,**体系架构、技术架构上的创新,也必须由技术推动**。多数互联网公司,工程人员在这些方面的创新多数都被良好的鼓励与支持。
**4,商业模式等架构策略颠覆式创新,全局创新:**
** **
周鸿祎说,如果要想做一个新产品,要试试看,能否让“付费的不付费”,让“封闭的变开放”等等,**有架构层策略层创新,才能跟巨头有得玩**。但是,在中国恐怕从未有一个产品经理能够主导这样的创新,如果一个产品经理敢提出“将付费转化为不付费模式”,恐怕不会受到上司支持,更不用说真正实行。马斯洛需求模型告诉我们,人都有惰性,都害怕,都首先需要安全感,才敢大胆实现自己的价值。很多创新必须要免除KPI压力,必须要具备即使失败也不被责难的权利,才敢于被实施。何况多数产品经理,顶多只有产品经理内部的调配权,对于运维、BD都没有多少话语权。如何进行此类创新?
这些问题严重不?**在浪潮汹涌的互联网大势下,创新能力是企业非常重要的核心竞争力**,而上述几类的创新,都是非常重要的创新形式,往往可以决定一个产品线甚至一个公司的发展。
那么如何解决?
第一个思路是,颠覆产品经理架构方式。一般而言,互联网公司已经不会采用惠普、微软等巨型公司的流程控制模式,所以,可以取而代之的方式一般有如下几种:
**1,老板模式:**即,老板推动创新,推动部分工作进行。典型的例子是360的一系列商业模式策略颠覆创新。360的很多成功都是源自于此。但老板模式的弊端在于,“老板牛则牛,老板熊则熊”,反正“老板说这么干”,那就这么干。除了老周等奇葩式牛人,中国互联网采用老板模式成功的也不多,因为老板,往往太忙。而在中国,“产品经理模式”可以视为“老板模式”的“缩水增强”版,即资源缩水,权力缩水、自主性缩水、胆量缩水、全局观缩水而时间投入增强、对产品线的熟悉增强。
**2,工程师模式**:即,工程师主导创新,主导工作进行。典型的成功范例不在中国,而遥远的大洋彼岸:谷歌与脸书。这两个公司的巨大成功很大程度上得益于此。他们的工程师对产品有比产品经理更大的主导权利,产品经理说服不了工程师的,工程师可以不干。这种方式不仅可以吸引到最优秀的工程师,并且也极大的发挥了工程师的潜能。但是,这是一种典型的精英IT文化,需要从业者不仅具备极高的专业能力(专且博),也要具备极高的自主管理、思考、创新的能力。在中国的当下,除了极少数人,多数都达不到。
第二个思路是,维持产品经理模式,辅之于工程师模式与老板模式。即,“制度往往是死的,但是人是活的”:
1,培养工程师产品意识,努力跨界:工程师并不要被职能束缚,工程师与产品经理,本身并存在着很多共性,存在着转化的可能。我一直认为,很多数学模型与系统架构不过是产品思想从抽象到具体的映射。例如有了“买了同样一个东西的人可能买其它东西”这样的思想,才有了UserCF、ItemCF这些协同过滤方法,又有了,“热门物品不具备太强代表性”这样的思想,才有了改进的UserIIF与IUF模型。这些模型与思考都不是产品经理提出的,所以,技术人员要大胆拓宽自己的能力,多从产品层面考虑;
2,几类创新形式,不要由产品牵头:上面提到的1-3类创新形式,牵头者一定要有产品与技术两头的深度把握,一般不可由产品主导。不然“老实巴交的”,“听话”的技术同学容易被带到沟里;
3,老板参与并主导模式创新:策略类创新,只有老板与大管理者可以干;
4,鼓励工程师自主创新:鼓励工程师自主创新,需要实际的东西,实际的东西是什么,大家都懂。