产品创新之前,请先跳出细节怪圈

小程序这么火爆,作为产品经理,还不了解小程序如何设计?4周在线学习,抢占职场优势。了解一下>>

创新能力是产品经理的核心能力,如何在日常产品工作中做好创新?这是考验着每一个产品经理的问题。

最近有一篇俞军老师回答知乎提问的文章,作为产品届的前辈,看待问题一针见血,而文章开头就讲到了创新。

俞军老师认为“如果你想成为产品经理,那么创新能力是必须的,这是任何一份基础工作基础薪酬所不能比拟的

做产品这个岗位需要创新精神,不然乔布斯为什么被称为一名伟大的产品经理,但今天我要讲的是在具体实践过程中如何跳出摆脱不了的细节圈。

01 清空

对一项事物的创新既需要一定的了解和储备,同时又需要跳出固有的模式和思维去重新看待,摆脱刻板印象,一切从0开始。

就像俞军老师在回答中说道“创造力不会凭空出现,在某个领域创新所需的具体知识,你掌握的数量和质量,对创造力的影响很大。

但是,掌握该领域的过多知识,有时反而会导致一个人观念顽固封闭,不能用新视角去看待问题。

比如市面上现在有很多种方式来解决一个痛点或者需求,而你如果对这些现存方式做优化那只是对现有产品的改进,而不是创新。

真正的创新或者说微创新一定是一种新的模式、新的产品形态亦或是新的解决方案。就像iPhone 问世是对诺基亚等手机的颠覆式创新。

当你问用户需要什么,他们只会说需要一匹更快的马,直到出现了汽车。这是产品届流传已久的一个例子,也恰恰说明了创新的真谛。

02 纳新

清空之后就是纳新,从全新的角度和视角去思考,用发展的眼光去看待问题。现在市面上产品的出现一定是基于当时的技术水平和可实现程度。

而在没有更好选择的情况下,用户也接受了这种方式。如果以现在以及未来会成熟可实现的方式来解决问题,是否有新的办法可用。

同时,对产品节奏的把握需要做到心中有数,比如现在疫情期间增加了很多测温隔离等需求,那么这个是长久需求还是短暂需求。

如果你针对这个情况在产品创新上增加很多比重,那很有可能研发出来面世之后疫情已经结束,所有的投入都是竹篮打水。

纳新的角度要从问题出发,而不是从现有解决方案着手。一个产品的诞生是基于需求,对现有产品的改良属于优化,对需求如何被更好解决的探索才是创新。

03 大处着眼

如果把一个产品比作一个人,那么大框架就类似于骨骼,探索前期我们会做一些调研和现状考察,那么调研之后一定要先梳理出框架,而不是一下子就到细胞层面。

从大处着眼可以让我们不必一下子陷入到细节层面,而且框架大纲也有利于梳理出整个脉络,先有大的点再去针对性的做延展和补充。

这一方面可能会是产品人特有的一种感觉优势,相比于纯执行层面来说,从大到小,从抽象到具体是我们在规划并落地一个产品时常用的方式。

那么同理在产品创新亦或是新的解决方案设想中,一定要有几个大点的抓手,而且要足够开放,不设边界。

创新需要大胆,想法需要筛选,那么在想法发散时期,你的所能想到的力之所及就是边界,千万不要被固有框架套住

很多时候我们的解决方案会局限于现状或者技术不成熟等因素不得不受到制约,但如果连可能性设想的想法都要受制约束缚的话,创新无从谈起。

04 可行性着手

经历了清空-纳新-想法之后,到具体落地层面我们就要分出优先级,像软件产品的功能设计和需求池一样,重要紧急四个象限。

而对于产品创新来说,个人认为四象限可替换成价值和成本的划分。通常来说硬件产品的创新投入会比软件产品投入更多。

所以最能看得见价值以及成本代价最小的那部分,一定是可以优先尝试的。当然如果公司有独特的战略以及技术优势另当别论。

可行性是将上部分我们发散的想法具体落地的过程,这时候可能会按当前阶段可行性以及成本价值等排一下顺序和优先级。

但随着市场变化以及外部条件的成熟,这些可行性可能会随时出现顺序及实现条件的变化,所以要时时留意。

产品创新不是一件容易的事,万事开头难,但唯有创新才能获得绝对的竞争优势,正如《从0到1》中所说的那样:

做大家都知道如何去做的事,只会使世界发生从1到N的改变,增添许多类似的东西。但我们每次创造新事物的时候,会使世界发生从0到1的改变。

虽然现实中能改变世界或者改变大众生活的人是少数,但既然做了产品经理这个岗位,梦想还是要有的。

一起加油,共勉!

#专栏作家#

慕斯姑娘,微信号:musiguniang,公众号:产品那些年,人人都是产品经理专栏作家。关注金融科技和大数据领域,擅长产品规划和落地。

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

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 写的挺好

    回复
  2. 写的挺好的 只是创新的成本摆在那里,需要资源支持,又要承担风险。

    回复
    1. 我们的程序员就是阻止你创新的存在

      回复
    2. 程序员只是不希望你天马行空,逻辑理清楚还是很好沟通的

      回复