0°

产品方法论真的有那么一点用……真的!

正所谓工欲善其事,必先利其器,产品经理亦是如此。掌握产品方法论体系,在日后的产品经理工作中,也会避免一些无谓的坑,自己也明确成长的途径。就好比要成为一名伟大的篮球运动员,需要先掌握篮球的基本规则,有扎实的基本功,不断增进的进攻手段,日益丰富的比赛经验是一个道理。当然并不是说一定要参照方法论来执行,只是提供一种参考方法,希望这种方法可以有所助益。


自己的一套方法论,帮助自己构建一个自己的逻辑体系。


产品方法论真的有那么一点用……真的!


接下来,放一张腾讯的产品方法论:


产品方法论真的有那么一点用……真的!


那么根据John自己的方法论,其中需要重点去解释的:


一、关于逻辑体系


逻辑是什么?


我不是哲学家,不是数学家,所以我不可能上升到一个高度去解读这个名词,所以我说描述的只是我的看法。就产品而言,逻辑是一个很重要的东西,什么是逻辑?在我看来逻辑就是条理性,合理性的结合。带入到产品中来说,整体框架是否合理?技术架构是否合理?用户体验是否合理?功能架构是否有条理性?市场定位是否合理?都是逻辑的一种体现,虽然这样说有点儿狭义,但是我感觉产品的逻辑思维就是要这样服务于产品。


John之前总结的逻辑三段论,所谓逻辑:

  • 聚类   就是把你见到的任何事物, 用不同的分类标准进行分类

  • 递归   把你遇到的 任何事物, 用不同的排序规则 进行 排序

  • 因果   把你遇到的任何事物,用不同的视角思考它们之间的因果


其实你根据项目、功能和流程去思考逻辑,我相信你会很清晰。


沉下心,慢慢来


其实做产品,对于时间会有许多“浪费”,需要会去细化我所要梳理的东西,需要去了解整个项目的框架,结构。(其实我并不推崇想转行的小伙伴从文档方面入手,因为我觉得最应该提升的首先是自己的逻辑思维,至于原型,文档什么的,抽出一个礼拜来好好了解就OK了)


刚入门的时候,我一直告诫自己你是个“白痴”,别装聪明人。我很少在公开的场合发表自己的意见,因为我怕错,但是我会记录了下来,会下问问我老大,为什么要这样?是不是有更好的方法?还别说,我还真就提对了几次建议。这一方面增长了我的信心,一方面也促使着我遏制自己的野心。还不到你掌握话语权的时候,别急。其实我知道每个人都渴望着成功,渴望着那种产品是由自己创造出来的那种感觉,但是功夫不到位,到头来吃亏的是自己。


什么是方法论?


说了怎么多,到底什么才叫方法论?其实这个和逻辑一样,没人可以准确的定义,只能说这就是你做事的一些准则,一些套路,一些方法的集合。每个产品的方法论都不一样,却又很像,因为我们最终追求的东西,本质都是一样的。


小伙伴入职,我总是会让小伙伴去体验产品,然后又针对性的去拆解竞品,然后形成文档一起内部分享。真的能成长不少。同样在我刚毕业时,老大专门做了一个关于他总结的方法论的PPT给我们分享,真的是受益匪浅,也在我后来的工作上避免了很多坑(虽然依旧踩坑,但少了很多)我后面也会慢慢的都分享出来,因为我想通过自己的理解去表述,而不希望直接引用他人的成果。


需求到底是什么?


其实做了产品以后,经常会有疑问,运营、商务提出来的需求千奇百怪,可是我们应该怎么总结这些需求?是提出来的就做?还是我们再去思考一下?有的时候按照他们所描述的做出来的东西他们未必真的会用到,因为他们也不知道自己到底想要什么。所以,作为产品的第一个能力就是追根问底,找寻这个需求的真正面目,还原最真实的场景,这样才能避免我们踩坑。


按照我的你方法就是,问五个为什么,追寻它的本质,问到底。然后想一个方案去解决,但是一定要站在他的角度用他的思维去考虑这个问题的核心是什么,往往只有这样,你才能发现最本质的需求。另外就是多维度去思考,除了五个为什么,还有五个W一个H,也就是何时(when),何地(where),什么人(who),什么事(what),为什么(why)和怎么做(how),通过这几点来发现最基本的需求场景,往往是比较接近于最真实的需求的。


作为产品我认为最需要具备的,第一是较为缜密的逻辑思维,因为产品是一个项目从诞生到成熟需要操心最多的人,因此一定要对整个项目有一个清晰的结构,第二是大局观,通过局部看到整体,又从整体来细分局部,并且实时进行一些调整,使之符合现在的市场需要,用户需求。如果我们这个项目是to B的,因此我们的整体就是市场,就是通过商务,运营来反馈的,这就引申出了第三点,对需求的把控,对伪需求的辨别,或者说是找到真正的需求。


二、产品与用户之间的思考


用户不是“傻子”!


在我接触的一些产品小伙伴中,经常会说一些这样的话,“把用户当白痴”等等。。。


其实我是真的很懵逼,谁说用户都是傻子的?对于这几句话,我认为核心意思应该是用户懒的思考,不要让用户付出更多的认知成本。我觉得我们应该把握一个度,既不能为用户考虑的太多(想当然的觉得用户需要),也不能让用户的认知成本太高。


但是怎么去衡量这个度?


这时候就会需要一个神奇的技能,“一秒变小白”!这也是为什么马化腾特别牛逼的一个点,能很快的进入到用户这个角色,把自己当成一个一无所知的用户,从这个角度来衡量我们的一些功能和需求。但是这也是一个需要经验积累的能力,所以一定要多去分析产品,不管好的坏的,不管是哪种类型的,多去分析体会,好的功能到底好在哪里?差的地方到底差在哪里?


所以千万不要抱着“用户是傻子”这个想法去开发一些功能,而是锻炼自己能从一个小白的角度看待整个产品。


除上面这一点,还有一点需要注意的就是不要站在“上帝视角”。


什么是所谓的“上帝视角”?就是一个产品的惯性思维,喜欢站在整个框架上来看待某些功能,如果发现有类似但用法截然相反的功能,会想着把两个功能合并,或者把二者弱区分。但是站在用户的层面来讲,他并不知道二者是一样的,如果产品做了合并或者把两个功能的区分度变弱了,那就是在引导用户,“这两个东西其实差不多”,这时候在用户的角度,这就是一个冗余的功能,之前所做的东西就全白费了,投入的资源都成了无用的。


所以,和之前的一个观点相同,就是把自己当成用户,从用户的角度出发,从用户的角度考虑,这样才能让一个产品收益最大化。


所谓“用户体验”


之前说了那么多,其实核心目的是什么?就是为了一个产品的用户体验,可是我们又没有想过,我们毕竟不是真正的用户,就算我们将自己带入用户这一角色,就算我们从用户的角度去思考,我们有没有想过这样一个问题,我们想给用户最好的,但这是不是最合适用户的?


追求极致的用户体验固然重要,但是如果这个做的过了,那就变成负优化了。我们在做的时候,要考虑到的一点就是,这是不是最适合的?所谓用户吃亏原则我感觉就是服务于这里的,因为正优化的效果要优于负优化!所以,当我们不知道该怎么做的时候,本着这个原则,让问题暴露出来,到时候再去优化,这样做起码可以让用户看到的是正优化。


“习惯”至上


说到了用户体验,就不得不说一下使用习惯这个东西。


初入产品很多时候都想大展拳脚,希望自己的想法能得到实现,希望自己能掌握一条产品线的“生杀大权”,将自己的新想法,新创意融入其中,让自己可以变得很牛批!但是你怎么知道,用户会喜欢这个新的创意?如果ios的系统变成了上下切屏你会习惯么?如果点击一个垃圾桶本来应该是打开回收站,却把东西清空了你能习惯么?


所以,并不是不去做创新,而是一定要三思自己的这个创新点到底可不可行,是否会颠覆用户的整体认知,是否新的改变会让用户不太习惯,是否可以接受这个由创新带来的成本。


二八原则


这个原则肯定很多人都知道,这条“真理”学名很多,用在不同地方有不同的说法,但不管怎么用,都离不开它的核心“学会避免将时间和精力花费在琐事上,要学会抓主要矛盾——百度百科”。


我之所以把这个人尽皆知的原则拿出来说,也是因为在工作的时候,不知道怎样分配权重,虽然同样属于所做产品里的功能,但是还是会有优先级。其实二八原则就是在教我们如何分配权重,同样,在产品与用户的关系中,我们要把大量的权重放在能带给我们80%收益的那20%的用户里。


其实我感觉对于用户的理解这块儿还是有很多欠缺,所以也是一直更多的体验不同的产品,找它们之间的让我感觉很舒适的一些功能。作为“设计者”,尤其是做to C的产品,一定要把握好产品与用户之间的关系,怎样的功能设计,交互设计能让用户感到舒适,要在保留特色,还是尊重体验这两者之间博弈。


三、产品和开发的“爱恨情仇”


“相爱相杀”


做过开发的朋友们一定知道,开发最恨的就是产品经理这个角色,时常该需求,时常穿插需求,对自己的代码指指点点。甚至当时爆发的一件事情在互联网圈疯狂转发“某外包开发和产品疯狂互殴,原因是要手机主题能根据手机壳变色!”这件事情一出,尤其是了解到它的原因后,真的是让人啼笑皆非,这到底是什么鬼?


我想大家应该会很明白为什么开发小哥们想“杀了”产品经理了吧,哈哈哈~

但是,我为什么还会说“相爱”呢?因为产品经理的职能,在整个产品生产到上线的过程中,起了很大的作用。如果没有产品经理,而是让需求方直接和开发对接,那这个情况就会变得很糟。


产品经理产出需求的流程的开始就是收集需求,一堆杂七杂八的需求整合到一起,去其糟粕,取其精华,将梳理的内容输出成一份需求文档,产出给开发。试想一下,如果每个开发按模块和客户或者需求方对接,那么,这个项目得乱成什么样?


我该拿你怎么办,我的产品经理!


整理需求,讨论需求,产出需求,协调开发、UI、UE等等,都是产品经理需要干的,跑前跑后有时还需要赔笑脸,经常为了使一个功能,一个需求做的更加完善,更加符合预期,要经常的“骚扰”开发,虽然被厌恶,但是还是会厚着脸皮的去完成。


所以,我其实很希望开发小哥们可以理解产品经理的难处,多一分理解,其实能让我们之间的合作交流多十分。


我拿什么爱你,我的开发?


其实我想分享的重点就在这儿,作为产品经理,我们怎么去“爱”我们的开发小哥?


静下心来仔细想想,为什么开发和产品之间会有矛盾?还不是因为那些神仙需求的存在?但是,那些神仙需求为什么会存在?这个问题的根源就是,产品经理不懂技术,他不知道这个可不可以实现。


那么重点来了,在我看来,不懂技术的产品不是好的产品经理。作为一个产品经理,如果不懂交互,你起码能看懂UE的交互图,不懂设计,你起码能看懂UI的设计稿,不懂开发?你是真看不懂代码啊!!!所以,我认为产品经理至少需要去尝试了解一些开发知识,不需要你来写代码,但是你要明白这个产品是怎么运作的,那么在和开发的交流上,就少了那一份障碍,互相理解起来就更加便捷畅快。


这也许不是方法论,但是这是经验。成长路上,希望一起多交流。


近期文章:


产品经理天天提MVP,到底该怎么用?


为什么说产品设计要有简洁性?


一文弄懂用户画像以及如何召回用户


欢迎关注John的公众号:

产品方法论真的有那么一点用……真的!


也可以加John微信:xiaoteng1234567890 一起交流。

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论