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

一些事  •  扫码分享
我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

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

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

  “功能性改进”:

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

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

  “非功能性改进”:

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

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

  “新产品孵化”:

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

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

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

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

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

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

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

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

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

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

本文链接:http://www.yixieshi.com/it/13618.html
关键字:互联网新闻|产品经理|产品驱动|产品团队|
若无特别注明,文章皆为互联网的一些事原创,转载请注明出处

本文被转载1次

首发媒体 一些事 | 转发媒体

随意打赏

提交建议
微信扫一扫,分享给好友吧。