专栏名称: 人人都是产品经理
产品经理不再是一个单纯的职位,而是一种思维方式,这种思维是所有互联网人必备的,做互联网的人不能不懂产品,关注产品,改变生活。
目录
相关文章推荐
三节课  ·  99%运营人,都需要具备的能力 ·  5 天前  
91产品  ·  保姆级直播话术.ppt ·  6 天前  
人人都是产品经理  ·  怎么成为年薪53万的AI产品经理?我分析了2 ... ·  1 周前  
人人都是产品经理  ·  “打假博主”的正义与生意 ·  1 周前  
51好读  ›  专栏  ›  人人都是产品经理

同质化产品时代,产品是否可以标准化?

人人都是产品经理  · 公众号  · 产品  · 2017-02-08 18:55

正文

大概三年前,互联网和移动互联网都出现了很明显的同质化趋势。现在想来,也许“同质化”只是“标准化”出现的征兆。


作者:枯叶

全文共 4513 字,阅读需要 8 分钟


—— BEGIN ——


“同质化”与“标准化”


移动互联网发展至今,出现了许多优秀的企业,越来越多的人,涌入到这个行业;相应的,在资本、人才涌入的背景下,APP 也越来越多。


同质化的现象已经被人们选择性的回避,不同软件相同的功能与我们而言似乎不再那么新鲜。我们身处产品经理的角色,分析竞品、分析优秀产品的行为,加深了同质化的影响面积。


  • 为什么分享都在右上角

  • 为什么扫一扫都是一样的

  • 为什么登录还是那个登录?

……


在阅读到本文之前,我们会将这一切的现象,定义为“同质化现象”,又或者是定义成“抄袭的结果”。然而,我却想提出另一种可能性的构思。


我需要强调:目前阶段,这个提议,任然只是概念阶段,就如同新概念汽车一样,我们看材料是非常的酷炫,但现在却是无法投入到实际生产中;从概念到现实之间,还有一段不短的历程,需要我们共同的努力。


同质化也许只是“标准化”出现前的一种征兆,如同黎明前的黑暗。


产品可标准化吗?


产品可标准化吗?


这是我思考许久的一个难题,不仅仅是对我而言,我相信对于我们大部分从业者来讲,这都是一个极具“争议性”的难题。


我能够理解:产品经理需要思考,需要创新,是个重思考的角色;但这不代表我们没有动手技能。


一次偶然的机会,我将“想”与“做”分开了,过了一段时间,明显的感受到我“做”的事情,其实完全可以标准化出来。


对于开发者来讲,编程思维便是“想”,写代码的过程便是“做”,不论想的多么好,开发的代码都需要遵从编程语言的“规则”,也需要遵循开发者的“规范”,还需要遵循团队内部的“协议”。


规则也好,规范也好,协议也好,均是某种意义的标准化输出。


这个发现让我开始不再相信自己所从事的这个行业,也许产品经理这个行业正在向我们发起挑战,也许他正在悄无声息的孕育自己的规则,也许我们即将迎来的不仅仅是产品经理起点,也是产品经理的终点。


这个时候,我只是模模糊糊的有所感觉,但却不清晰,让我更加清楚的看到这场变革的事情在于我所组织的几次入门培训。


产品经理可培训吗?


如果……我们将其标准化下来


为什么不能呢?


对于开发者而言,真正掌握编程思维的大牛很少,但能写代码,能实现功能的却很多。


这是因为开发者有一份标准化的规范,标准化的规则,正是因为这样的标准化,开发者有许多编程工具,并且这些工具都很强大,比如自动纠错,自动引用。


作为产品经理的我们,深知一款工具,最大的依赖便是一些可标准化的规范,而不是为每一个人量身定做。


只有标准化,才能适应一个群体的共同诉求,也才能建立这个群体共同遵守的“规范”。


标准化产品


相对于“抄袭”而言,我们其实都是在遵循一些“标准”,很多的做法,我们甚至无法追溯到设计的源头,只知道大家都在这样做,于是我们就这样做了。


在不经意间,其实我们已经开始尝试标准化了,只是我们自己尚未意识到而已。


比如,我们需要引用第三方系统时,遵守他们的规则,其实这就已经是一种“标准化”的应用现象了。


我们使用微信登录,就必然要登录微信的 unionid(只有 unionid 能作为多终端使用的唯一身份标识),要获取用户的个人资料,就需要使用微信的 OpenID( unionid 不能获得用户资料,Openid 唯一但不固定,使用不同终端会生成不同的 Openid )。


我们使用 talkingdate 来做数据统计,我们就需要遵守他的规范,罗列出要统计的页面,要统计的点击事件,并且遵守他的使用规则,我们需要为每一个埋点设定一个英文名,需要一个 ID ,需要一个对应的中文名。


除了在引用第三方系统时会有标准化的概念,其实我们在设计时也在潜意识的遵循一些“标准化”的规则。


  • 为什么我们在设计底部菜单时,只允许最多5个按钮呢?

  • 为什么我们的“搜索”都会用新的一个页面来做呢?

  • 为什么对于内容列表,我们都会有加载更多和刷新的功能?

  • 为什么点击用户的头像,就会跳转到对方的个人主页?


其实这些都是我们现在,可“标准化”下来的做法。


我们将这些“标准化”的现象归结于所谓的“用户习惯”却说不清楚他为什么是“用户习惯”,我们很清楚这些是基础的做法,但却说不清楚为什么要这样做。与我而言,这一系列的现象,既不是“用户习惯”也不是所谓的“基础”,而是一种标准化的运用方式。


对于有编程背景的产品经理可能更容易理解,这就像代码语言里的“语法”或者“封装”,并没有过于华丽的解释,只是某种标准的应用,只是我们包装了一层华丽的词藻,结果弄得自己也说不清楚了。


对于标准化而言,是一种技能的沉淀,需要长时间经验的积累,我们通过反复的做同一件事情,摸索到这件事情的规律,找到他的共性,就将他沉淀下来,在需要用时,便可以直接使用。


这就导致产品经理的培训成为了一种可能,你并不需要花费与我相同的时间,只需要遵循我的“标准”,在解决相同问题时,由于我们遵循了相同的“标准”,我们的结果便是相同的。


对于研发而言,一年经验和十年经验的开发相比,如果遵循相同的“标准”解决相同的问题,结果也必然是相同的。可能这会让大家有所争议,是因为我们会习惯性的被时间所欺骗,比如一年经验的开发不可能和十年经验开发结果相同。


我能理解大家的想法,但还请注意我所提到的前提:遵循相同的“标准”解决相同的问题。


我们的差距很多时候体现在遵循的“标准”不同,一个功能的实现方法有许多,十年和一年相比,所使用的标准必然是不同的,这就会导致差异的产生。


这样也许会让大家更好的理解。


一年经验的开发,和十年经验的开发,使用相同语法,打印“ Hello Word ”结果相同。


在这个命题下,十年经验是否和一年经验没有区别了?因为他遵循了一年经验所遵循的“标准”


标准化的趋势


我已经告诉大家一个成长的捷径,如果你是刚入门的产品经理,遵循5年经验的“标准”,在该标准所能解决的问题上,便不会与其有太大区别。


这可以是一种成长的捷径,但更重要的却是推进行业的进步,其实我们的社会,乃至人类史都是不停的演变,继承,积累,“标准化”的一个过程。


我们不断的将自己的经历,演变成一些“标准”,而后被其他人继承,后者则在我们的基础上继续经历,积累更多的信息,然后演变成新的“标准”。


仔细想想,我们的生活中随处可见关于“标准化”的现象。


我们都知道 1+1=2 ,却不再探索为什么 1+1=2 ,这是一个标准,我们在这个标准上继续积累,得到了 2*2=4 ,形成了一个新的标准。


如果每一次的科学发展都需要将前人的“标准”都重新推演一次,我们的时代就会止步不前。


我们在做移动互联网产品经理时,也遵循了相同的原则,比如我至今尚不明白“互联网如何实现”的,未来我也不会去研究如何实现互联网。


我们只需要在前人所演变出来的“标准”上,进行应用,进行积累,从而形成新的“标准”。


我相信,未来已来,在极小的面积里,已经有与我相同观念的前辈在做这件事情,将自己的经历演变成“标准”,并将这些标准传递给身边的人,我也很期待产品标准化时代的来临。


因为,标准化的意义远超我们惯性思维的认知和预测。


产品标准化的意义


帮助新人快速成长,只是“标准”的诸多意义之一,现在,我们来探讨一下,如果产品经理有标准,我们所处的这个行业,我们所想要将事业、梦想、未来所寄托的行业会是什么样的。


1. 我们的工作效率会更快


标准的应用会让我们的工作效率更快,甚至出现数十倍的差距,这是因为标准的演变需要长时间的积累,而一旦形成标准,我们就会处于应用状态,几乎不需要思考,不需要反复,直接使用即可。


内容列表被广泛的运用到许多产品里,如果我们把内容列表的需求演变成一种“标准”会出现什么结果呢?


在未来的工作中,如果遇到“列表”型的需求模块,我们便可以直接将已经标准化的需求直接用于项目中。


这大概只需要几分钟的时间,而现在呢?每当我们遇到列表时,都需要重新设计,重新撰写他的需求文档,这个过程都会重做一次。


2. 极大的提高我们的输出质量


标准化的过程,需要我们解决许多问题,积累许多次的实验,这就导致被标准化下来的方法论或者某种意义的技术,具备很高的稳定性,轻易不会出现问题。遵循这样的标准,必然会提高我们的输出质量。


这就好比在开发过程中,我们使用了一套非常成熟的 SDK ,这套 SDK 足够完善以至于我们在使用的过程中,不会出现 Bug ,我们想要的功能,也都被很好的兼容了。


反之,并不稳定的标准,就类似于一套粗糙的 SDK ,不仅仅有许多的 BUG ,还会有代码冗余、兼容成本高,增加我们的使用成本。


任然是内容列表,标准化以后,我们在任何一个项目里使用时,都会直接使用一套完整的基于列表的需求文档,几乎不会有遗漏和缺陷。


即便出现了缺陷,只需要在相应的标准之上建立新的标准,下次使用时,就不会再出现相同的错误。


3. 催生专业的产品经理工具,减轻工作负担


作为产品经理而言,我们能使用的专业工具有那些呢?思维导图并不是我们的专业工具,其他角色也可以使用,Word 、Excel、PPT 也是如此。


真正的产品经理工具,大概只有 Axure 这类的原型图绘制工具了,相比开发行业的各种编码工具,项目管理工具,实在过于缺乏了。


而一旦我们出现了标准,便会涌现出一系列以“更快,更方便,更强大”为命题的工具性产品为我们所服务。


工具方向的产品经理,应该非常了解这三个词语,毕竟几乎所有的工具,都离不开这三个词。


比如我们来做一款能够在画原型图的时候,自动生成需求文档的工具可好?


这是个美丽的构思,不过在现在是不可能实现的,因为即便是需求文档,我们目前的环境也尚未将其演变出“标准”。


即便是产品经理最基础的技能“需求文档”也任然停留在“概念”阶段!


难道,这样不是很奇怪吗?


4. 催生“专业”产品经理


现在的产品时代,谁能说自己“专业”呢?缺少统一的“标准”,那么专业便也无从提起。


我们所谓的专业是指对某个行业的专业程度,同时也是对某种技能的掌握的熟练度,一旦产品经理涌现出大量的“标准”,我们就会催生出更多的“专业”产品经理。


我详细不论大家是处在什么阶段的产品经理,都会对下一个阶段感到陌生,以至于我们很难触碰“专业”:


  • 入门的产品经理面对各种花式技能:有用的,无用的;现在用的,将来用的;社交领域的,工具性质的,无从下手。

  • 3 年产品经理面对产品使命、用户痛点、市场面积、运营策略、迭代策略手忙脚乱;

  • 5 年以上的产品经理又会受到商业模式、产品矩阵、市场战略感到筋疲力尽。


谁也不敢说自己是专业的,因为不管是那一位产品经理,我们都只是部分技能专业,部分技能初级。


而正是这样的一个行业,我们甚至连自己所具备的技能都无法清晰的描绘出来,并且相同的名词在不同的产品经理身上所体现出来的意义,还既有可能是完全不一样的。


缺少标准的现在,何以专业自居呢?不仅仅是自称,甚至无法将“专业”作为自己的成长目标,因为实在太不清晰,太模糊了。


现在的我们,真的很难想象,“专业”的产品经理,到底是什么样的可如果“标准”形成的未来,我们大概就都有了一个明确的成长方向,先学什么,在学什么,学会后如何使用。


我们将会在一条很明确的路上健步前行,没掌握一个“标准”就能直接投入到实际使用中,每到了一个瓶颈,就去学习相应的“标准”,然后继续前行,直到我们自己积累了足够的材料,就会形成我们自己的“标准”。


每一位产品经理,都在摸索自己的方向,探索自己的方法,却忘记了人类发展至今最大的工具,便是“知识的继承”。如果没有继承前人的知识,我们现在任然在钻木取火。产品经理的行业已经发展了十余年,许多技能已经具备“标准化”的雏形。


你是否做好迎接产品经理“标准化”时代的到来?


—— END ——


作者:枯叶,近6年经验的产品经理,人人都是产品经理专栏作家。擅长社交,社区,细分群体挖掘。微信公众号:枯叶咖啡馆。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

产品经理实战训练营火热报名中,理论+案例+实战式教学,全面提升产品能力,实力挑战“薪”高度! 

点击“阅读原文”查看课程详情!