欢迎光临
我们一直在努力

转型产品经理必看|我是如何从程序员一步一步走向产品经理的

转型产品经理必看|我是如何从程序员一步一步走向产品经理的

我是@老曹,人人都是产品经理大家长,今天小编妹妹们都休息了,为了坚持给大家推荐干货,没办法啦,只能亲自来审稿了。

这是一篇长文,我花了差不多30分钟才看完,也是我见过有史以来最长最完整的一篇关于程序员转型产品经理的文章。创办人人都是产品经理以来,每天都有很多人问我如何转型做产品经理、转型产品经理会遇到哪些问题,其实我一直没能回答好这个问题,因为我从运营转型产品经理的过程太顺利,并且转型的过程也没有做太多的思考和总结。直到看到这篇文章…作者完整记录了自己一路来从对产品的认知到接触产品到转型产品整个过程,以及对产品的理解、意识的转变、心态的转变,非常完整,由衷佩服作者。

今天推荐这篇文章给大家,尤其是准备转型以及在转型路上的小伙伴们,希望对你们有帮助,文章比较长,但是值得一看。

放下,是一种修行

拿起,是一种历练

写在前面

过去一年,我完成了角色和身份的转变,从最熟悉的开发跨越到陌生的产品,从最初的好奇到中途的迷茫到最近的有一点开悟,一路经历着、成长着,抬笔记录下我这一年心态、意识、思维的转变,算是对过去的一段总结,对未来的一份期许,我因技术而入门,因产品而出门。

我理解的产品

说起产品,或者说互联网产品,我第一次明确的知道这个概念的含义应该是在2011年,那一年智能手机开始兴起,印象很深刻,那一年的Android系统还是在1.x到2.x的升级中,那一年的iPhone对我来说还是个遥远的奢侈品。也是在那一年,我开始学习Android开发到后来学习iOS开发,走上了移动开发的道路,也就是在那时候,我开始做移动App项目,那时候,我把项目当做了产品。那时候对产品的理解是浅层的,跟多的是看得到的界面、用的到的功能,相信很多初入产品的同学都会有这个阶段,设计出漂亮的界面和酷炫的功能就以为是一款成功的产品。也就是从那个时候开始,我边开发项目,边发现自己对所谓的项目设计有了自己的见解,并时常给项目负责人,也就是产品经理提自己的建议,我想那就是我最早的产品感觉了,从此,发现自己对这个创造、设计一个好用东西的过程充满了兴趣,埋下伏笔,在开发的过程中,我开始有意识的去了解这个过程,在做好开发之余,我开始“不务正业”的去学习、去了解什么是设计、什么是产品。我开始从网络、一些行业会议去学习、了解这方面的内容,从此,我开始对这个过程越发感兴趣,从此,我知道,这个过程叫做产品设计,主导这个过程的角色叫做产品经理,也就是PM(Product Manager)。

产品经理,听起来是多么高端的一个词,但此经理非彼经理,产品经理没有行政权力,没有主导商业战略的权力,产品经理负责商业战略的落地实施,负责定义产品、设计产品,协调各方资源在一定的条件下完成产品的研发和上线以及上线后的运营和维护。如果把产品比喻成一个孩子,那产品经理就是孩子他妈。现实中,产品经理的工作远没有本身称呼那么高端,产品经理需要处理每一个跟产品相关的问题,产品经理需要与各方沟通取得共识,需要去现场解决问题,需要处理大大小小的杂事,忙碌奔波于跟产品相关的每一个场景中,所以,在互联网,伟大的产品经理们自嘲为产品汪或产品狗。在我看来,产品狗是一个褒义词,它忠诚,对自己的产品忠诚,它勤奋,对产品每一个问题都努力解决,它乐观,每一个小小的进步能让它高兴,每一个不足都是它前进的动力。

细数全世界优秀的产品经理,群星璀璨,乔布斯是极致的代言人,他定义并设计的苹果系列产品改变了一个时代,引领了潮流。他的苛刻、极致、改变世界的初心影响着互联网所有领域的产品经理们,奉为经典。张小龙,微信之父,深谙人性,理解潮流,能把一款产品做到人们的生活中,几亿人都为之买单,实属境界。相信每一个产品经理都有改变世界的梦想,也都在这条不归路上螨跚前行,改变世界的毕竟是少数,能改变的只有自己,在产品之路上修炼自己、完善自己,不经意间业务就会发现自己已经做了一件了不起的事,脚踏实地,仰望星空,有宇宙的胸怀,同时也要有蝼蚁的勤奋。

我转行做产品到现在正好一年,我所在的是一家创业公司,从技术转行产品也实属巧合,这一年,从产品角度来看,我的产品之路总共经历的三个阶段,也是截然不同的三个阶段,这一路,我的心态、意识、思维都在经历着变革,或者说蜕变,伴随的是艰辛和一路不放弃的韧性,总的来说,在思维意识上我经历了工程思维、功能思维、产品思维三个阶段。思维决定心态和行动,记录下我的转变。

阶段一:工程思维

我从2014年10月份开始正式做产品,从那个阶段开始的三个月左右,我做产品的思维更多的是以技术和系统角度出发,我定义这个阶段为工程思维阶段。为什么这么说,因为我在设计产品的时候,第一出发点是技术实现层面的,通过实现的难易程度和系统角度去定义产品和设计产品。这么做有一个最大的弊端,就是脱离“实际”,我说的这个实际并不是技术实现的“实际”,而是需求和实际场景。容易变成为了设计而设计,相信做技术的同学都会有一种感觉,当接到一个需求的时候,首先是从现有工程架构的角度和扩展角度去考虑,一个需求或者一个功能的实现与否第一考虑要素是对现有系统的兼容性以及扩展难易程度。这是一种很正常的思维,因为我也是这样。但从另一个角度考虑,一个需求的价值不在于它本身的技术难易,而在于是否解决了产品用户的问题,如果把一个需求定义为技术产物,那我们是在做一个科研任务,相反,产品做的是商业任务。所以,我在一开始从技术模式切换到产品模式时,相当一段时间都是在通过技术定义和设计产品,这个时候的产品脱离现实场景,远离用户需求,我开始反思。

工程思维下的产品产出更像是一个工业品,而不是一个能站在人的角度解决现实问题的产出。它是技术产物或者说是科研成果,远离实际需求和场景,最后会发现,这样的产品投入市场后几乎处于不可用状态,这是非常严重的问题。工程思维模式下,缺乏用户意识,当然就更谈不上用户体验了。有问题不是坏事,可怕的是发现不了问题,发现问题后我开始解决问题,于是,我逐渐进入第二阶段。

阶段二:功能思维

发现工程思维下的产品工作不尽如人意,于是我开始有意识的思考,如何去分析和理解需求,如果通过技术手段将一个需求转化为一个给用户使用的功能。这是我的第二阶段,即功能思维,这个阶段维持了近半年,这时候我开始意识到,产品最终是交付给用户使用的,所有的设计过程都是将一个业务需求转化为一个具体场景下的特定功能。而每一个功能都具备完整的业务逻辑和功能体验。

好在的是,这时候我开始站在用户的角度去设计产品,将一个业务需求转化为一个技术能实现的功能,于是我开始围绕功能而思考,每一个需求或者优化我都首先从功能角度入手,如何让用户更好用,应该展现哪些信息等等,我将注意力集中在功能体验和视觉体验上,开始学习市场上各种优秀的产品设计,于是我在解决产品可用性的前提下陷入了一个功能设计怪圈。会为了完成一个需求开始考虑功能体验上的各种可能性,重点都是关注产品功能本身,而忽略了其业务目标和业务价值。而且,这时候我发现,一个产品从商业战略到最后的落地产品上线,期间不仅仅是一个技术产品,还包括业务定义、全业务流程设计等等,产品始终与业务并行发展,真正好的产品应该做到产品驱动业务,在产品设计过程中我忽视了与业务的互动,包括产品上线后产品运营和业务运营,这些环环相扣构成一套整体来支撑一个产品的运转。而且做产品的都知道,与各方的沟通和达成一致实际占到了产品工作的很大一部分。我的思路再一次被打开,开始关注业务、关于产品战略和定义、关注产品需要实现的业务目标,在保证实现一个正确功能的前提下更多的思考这个功能的业务目标是什么,不以结婚为目的的谈恋爱都是耍流氓,不以实现业务目标为目的的产品设计都是扯淡。

功能思维下的产品产出具备了一定的可行性,因为它结合实际需求,在功能思维下我对整个移动App的产品功能设计有了深刻的认识,从信息架构到产品交互设计和部分视觉设计都形成了自己的思维模式。同时,我开始站在业务角度去思考产品问题,产品究竟实现了什么业务目标,与产品相关的各环节究竟该如何定义和设计才能保证最终产品产出是具备可用性的,于是,我逐渐进入第三阶段。

阶段三:产品思维

产品思维,也是我目前所处的阶段,这个阶段我关注的更多的是业务价值和业务目标,在充分理解商业战略的前提下来完成产品定义和产品设计,通过充分了解产品所围绕的业务场景去提升产品的可用性和易用性,改善业务体验和产品体验,提升整体的用户体验。返璞归真,回归产品的本质。在产品思维下,我理解产品的过程超出工程和功能,但又涵盖工程和功能,正是因为有了前两个阶段,才让我对产品整个过程和每一个细节有了更进一步的了解和认识。在产品意识和产品思维的驱使下,我在前期定义产品的阶段会充分了解业务并清晰定义业务目标,衡量在目前的产品环境和可用资源下如何快速实现。期间需要完成大量的沟通工作,与业务、运营、设计、技术和公司其他相关职能部门等等。在共识和可行性的基础上再开始进一步的详细设计工作。

产品思维其实可以大大简化产品工作,在思路梳理和分工协作上相比之前有了效率的极大提高。整个产品体系从下到上分为战略层、范围层、结构层、框架层、表现层。最下层的战略层决定了业务和产品需要实现什么目标,为什么人和什么场景服务,范围层需要定义清楚在既有战略的基础上做哪些东西来实现战略目标,结构层需要基于范围层的内容完成基础信息架构和交互设计,框架层完成我们能看的到的界面设计,表现层则是视觉表现设计,让产品看起来更友好。一个完整的产品定义和设计过程都需要经历从下到上的每个阶段,缺失某一个阶段都会导致产品的不完整,重点关注某一个阶段也会导致产品的不平衡,所以需要产品经理找到其中的平衡点。但就重要性来说,越往下,重要程度越高。

产品思维还有一个非常重要的环节就是对业务流程的设计,产品经理为最终的产品质量和用户体验负责,在设计前期就需要考虑产品从设计到开发到最终投入使用需要经历哪些环节,需要与哪些人进行合作。比如需要数据准备的产品,在产品设计阶段就需要与数据提供方达成一致,保证产品上线时数据准备是ok的,比如需要运营介入的产品设计,需要在前期沟通阶段就邀请运营人员加入,确保其对整体业务流程和产品环节是足够清晰而且理解一致的,才能在最后产品上线时大家集体发力保证产品能高效运转,而不是产品单方面思考和定义然后交付给下游配合方,这样会导致产品与业务脱节。所以,产品思维需要在考虑整体性的同时顾全细节,心里要装下业务、运营、设计、研发,这个过程很累,但也足以让人成长。做好产品的同时,也做好了自己。

我的产品方法论

在整个互联网产品行业里,我属于产品新人,需要学习和掌握的东西还有很多,在此不敢高谈阔论,只把自己的理解记录下来。在这一年的修炼过程中,我慢慢形成了自己的一套做产品的方法,分享出来,算是接受批评建议和与大家讨论。产品和技术一样,需要通过不断的学习和积累加上不断的思考才能突破才能破局,所以对我来说,这是一次重新学习和突破的旅程,好比当初学习技术一样,学习、理解、掌握、整理、思考、突破。以下五点是我做产品过程中的五个关键步骤:

1.定义产品战略

定义产品战略需要基于商业战略,我理解的商业战略和产品战略还是略有不同的,商业战略的目标是实现组织利益最大化,而产品战略的目标是实现用户利益的最大化,在确保围绕商业战略的前提下落实到产品战略。所以,对于产品战略的定义需要建立在对商业战略的充分理解上。这就需要从组织高层也就是组织商业战略制定者那获取到一手信息,以最完整的状态将商业战略的定义做到充分理解。接下来就根据完整的商业战略定义来制定产品战略。

一个组织或者公司可能有多条产品线,这时就会有个产品战略,但是商业战略只有一个,所有的产品战略都是为了实现这一个商业战略而制定的。定义产品战略需要分析清楚产品的目标用户是谁,使用场景在哪,关键资源是什么,当然最重要的一点是产品解决了用户什么问题,如果要用一句话来回答什么是产品战略,我总结就是:“我们用什么方法为谁解决了一个什么问题”。这里的“我们”就是组织,是团队,“什么方法”是指我们的核心业务,是服务,“谁”是指我们的目标用户,是客户,“什么问题”是指核心需求,是场景。这个过程不需要用到什么工具或特别的方法,只需要做到组织和团队的理解共识,通过文字记录下来即可,关键是思考清楚。通过对关键问题定义,回答清晰后就可以进入下一步,对业务流程进行完整的梳理了。

2.梳理业务流程

梳理业务流程需要基于对产品战略的清晰定义。业务流程围绕产品战略目标而设计,需要明确业务目标,流程围绕目标进行最简化设计。在这个过程中最关键的是定义好业务目标,明确清晰业务目标即要达到什么目的后再进行进一步的流程设计。梳理业务流程的过程中需要考虑整个业务流程中涉及哪些关键角色,这些角色的关键动作是什么,业务流程中包括哪些关键信息,同时要定义清楚各角色间信息流动的方式。完成对业务目标、关键角色及动作、关键信息的定义后,可以使用流程图将设计好的业务流程通过图的方式表达出来。流程图的画法就不赘述了,有很多方法,关键是明确业务流程设计中的三个关键环节。

在梳理业务流程的过程中,需要定义清楚哪些是需要人去参与和处理的,哪些是需要技术处理的,这样一个完整的业务流程梳理下来后就已经很明确,技术产品的边界在哪,而边界之外的需要协调各方资源来完成。同时,整个过程中需要与组织各方进行充分的沟通,确保设计的业务流程在现有资源环境下是可行的,也要与研发团队就技术产品在业务流程中所扮演的角色和定义进行充分沟通,确保在现有技术上是可行的。总的来说,梳理业务流程的过程就是产品经理在现有资源下为实现产品战略目标而设计的一套可行的业务操作流程。

3.产品原型设计

业务流程梳理清晰后,就可以开始产品原型的设计了。产品原型设计包括信息架构设计、功能设计、交互设计和视觉设计。产品经理首先需要对产品信息架构进行定义,产出完整的产品信息结构图,接下来基于基于对业务流程的理解开始进行功能设计,功能设计的目的是为了满足业务流程的设计,所以是先有业务流程设计后有功能设计。产品功能设计时确保采用最小化原则,我们采用的是最小化可行性原则,也就是MVP(Minimum Viable Product)原则,这是精益创业中的一个概念,关于什么是MVP什么是精益创业大家可以去了解一下,我觉得这是一套非常好的业务和产品设计实践。

功能定义完后就是交互设计和视觉设计了,在大公司可能有专门的交互设计师和视觉设计师,但我认为,产品经理还是需要有比较强的交互设计能力和视觉审美能力的,之说以说需要具备交互设计能力,是因为前期的业务流程定义和功能定义都是产品经理直接参与的,而最能理解并将其直接转化为一个技术产品的非产品经理最合适不过,这是我认为的一种比较高效的方式,当然,用什么方式取决于其所在组织的实际情况,像大公司就是人多工种细,但弊端就是效率低。而我们作为创业公司来说,我是极力倡导产品经理需要进行功能和交互设计,最后产出产品功能交互图,这个过程称之为低保真设计。当然这个过程可以和设计师一起沟通进行,吸取专业建议。之所以说产品经理需要视觉审美能力,就是最后由视觉设计师完善高保真设计,但是一个好的产品经理我认为是能分辨出什么是好的设计和不好的设计,而且用户的第一感是从表现层开始,也就是看的见的界面和用的着的功能。

产品原型设计过程中可以用到的工具有很多,我常用的有苹果的keynote,用它来制作产品界面原型快速而且美观,交互设计逻辑用简单的文字加上连线标示来标示跳转关系即可,当然还有很多的工具可以选择和使用,就不赘述了。这一步完成后应该就能产出一个所谓的RPD了,之所以说所谓的PRD是因为我认为创业公司最好不要去弄一大套文档来各种说明,PRD的目的是用来记录整个设计产出,同时作为业务各方和研发团队的输入材料,做到描述清晰、利于业务和技术理解即可。这也是精益创业的核心所在,不要做多余的东西,简单直接、达到目标。

4.沟通协调资源

完成产品战略定义、业务流程梳理、产品原型设计后,就进入设计实施落地阶段了,这个阶段主要是沟通和资源协调工作。同时需要对设计产出进行微调和优先级处理。这个阶段是考验产品经理优先级处理和沟通协调能力的阶段。团队里每个人的思维方式和角度不同,如何使大家在理解上达成一致本来就是一个浩大的工程,沟通技巧在中间就起到了非常关键的作用。与业务的沟通不能完全用产皮技术思维,与技术沟通不能完全用业务思维,所以,产品经理起到承上启下进行信息传递的关键作用。在确保业务目标的前提下保证技术产品能在有限的资源和时间内完成。

沟通讲究的是找对人,同时注意沟通顺序。明确沟通目的让后找到能解决这个问题的那个最关键的角色,如果找错人付出的就是时间和精力然后还得不到结果。找对人后接下来就得确定沟通顺序,要确保事情顺利开展和问题的快速解决,定义一个沟通顺序很重要,一般来说,我按照问题阶段来确定沟通顺序,比如处于问题定义阶段,需要和问题提出人和相关决策定义人完成问题的定义,问题定义清楚后针对具体的解决方案,再和与这个解决方案相匹配的资源各方进行充分沟通,然后确保在解决方案的执行过程中执行各方的理解是一致的。全程确保沟通的直接、高效,避免出现重复沟通和沟通不到位的情况。

在沟通协调这个环节中,产品经理千万不能怕麻烦,重要的事说三遍,沟通、沟通、沟通,很重要!

5.验证改进产品

经历以上四步后,产品能按期上线了,这时候需要监测业务和产品的实际运转情况,深入现场了解问题,回来后及时总结并制定改进方案。这是精益创业中的验证环节,前期的设计在某种程度上都可以说是先验的设计,上线后就需要根据实际运转情况来反向验证业务和产品,这也是之前为什么要做MVP设计的原因,因为前期设计越简单后期验证改进的成本就越小,好产品是在不断验证和改进的过程中打磨出来的,没有一次性完整的设计。

在验证和改进产品的过程中,我认为最重要的一个环节就是去现场,去到业务发生的地方,去到用户中间,在实际场景中体验产品,发现问题并制定解决方案。避免接收二手信息,这样会误导产品经理做出判断。改进产品的时候,可以结合业务流程中的每个节点,找到现场很重要,去现场,在现场定义问题,回来制定解决方案,快速验证、快速试错、快速改进。

写在最后

过去这一年,我完成了一次转型,从一个专业技术人员转型到产品人员,技术让我入门,看到这个行业的细节,产品让我出门,让我看到更广阔的空间。这个过程中没少走过弯路,经历过开始的好奇、憧憬,到中途的迷茫、自我否定,过度到现在的慢慢开悟和真正理解产品。人的成长本来就是一个过程,春天播种秋天才能收获,回想这个过程感受到更多的是收获和成长。我的产品生涯才刚刚开始,路还很长,我会坚持在这条路上走下去,走好,走漂亮!以上说的这些都是我个人的一些总结,不代表任何观点。放下,是一种修行,对过去的珍重和告别,拿起,是一种历练,是对未来的信心和期待。

就写到这,我所说的不一定都是对的!

本文由 @唐韧_Ryan 原创首发于人人都是产品经理

赞(0)
未经允许不得转载:电商之家 » 转型产品经理必看|我是如何从程序员一步一步走向产品经理的

登录

找回密码

注册