admin 发表于 2022-6-24 10:34:52

技术8年转产品经理,这1年我的经历


导语:本文作者对1位从事技术8年后转产品经理的朋友进行采访,还原了从技术转产品的心历路程和思考,对于1-2年的产品新人有普适性建议。

https://p3-sign.toutiaoimg.com/pgc-image/SNT0R0q34LsixH~tplv-tt-large.image?x-expires=1971400782&x-signature=DFoffXQx5nWatKYD69aGQo02NAs%3D

一、前言

从读者反馈中,渔歌感受到不少从事技术的读者想转产品经理。有的读者犹豫要不要转型,他们担心技术的职业生命周期短,认为产品经理的职业职业周期更长;有的读者则坚定要转产品,但内心依然忐忑,不知前路几何;也有的读者觉得自己无所不能,从技术转产品就那么点事,难不倒自己。还有的读者就是个好奇宝宝,转不转再说,就想知道从技术转产品经理,有什么好处,有哪些地方很难。

渔歌有4位资深好友,他们从技术转产品都已经8年以上,整体发展也还不错。

其中,2位认为重新选择的话,不会从技术转产品,因为产品经理的性价比差,要操的心多,自己的性格也不合适。

另外2位从技术转产品的朋友则认为从技术转产品后,最重要的收获是打开了自己的认知,更客观的认识社会、认识自己,让自己的人生选择变的有多种可能,即使哪天不干产品经理了,也饿不死。但如果把产品经理当做一份赚工资的工作,性价比差,而且和技术一样没有可持续性,因为互联网人的职业生涯就这么短。

渔歌的观点:产品经理不是标准化的岗位。从技术转产品经理,有人成功,也有人失败,但不能因为别人的成败来判断自己该怎么选择,因为对于产品经理来说,有2大要素非标准化,要因人因地制宜:

1. 每个人的特质非标准化


每个产品经理自带天赋和不足,比如有的人天生擅长洞察问题,有的人擅长沟通,有的人擅长写文档,有的人抗压能力超强。反之,有人随波逐流,有人不爱沟通,有人不喜写文档,有人抗压力差。但每个人都有多面性,人是立体的。既不能只看长板,也不能只看短板。

2. 每个人所处的环境非标准化


每家公司对产品经理的要求不一样,有的公司要求产品经理全能,有的公司只要求写文档,想法都来自领导,有的公司要求产品经理狼性,能抢资源、抢地盘。

不同的行业、业务领域对产品经理的要求不一样,2C、2B、2G领域差异大,电商、互金、游戏、社交、车联网等、新能源等各行业的互联网进程差异大,行业背景迥异,对产品经理的要求也就不一样。

每个人从技术转产品的机缘不一样,有的人运气爆棚,遇到了好的领路人,有的人则一路都在被人设伏而不自知。环境对个体的影响很大,甚至会直接影响一个人的信心。

所以,面对大家对从技术转产品经理的疑问,每个个体和环境的千差万别,渔歌认为没有标准答案。但现身说法会有参考价值。

渔歌尝试以采访的形式,和一位从事技术8年后,转产品经理1年的朋友聊天,请他还原从技术转产品一年多的的心历路程。

用朋友的原话说,技术转产品有很多挑战,经历越多,越心怀敬畏,越需要认真的审视自己是否适合做产品经理,产品经理是个多元的综合性岗位,从技术转产品经理,有优势,也有劣势。

此文仅以当事人和旁观者聊天的视角,让大家身临其境感受从技术转产品的会遇到的问题,没有对从事技术的朋友们的不尊重,也仅代表一个转型案例,请根据自己的情况综合判断可参考性。

全文以聊天的方式展开,渔歌表示渔歌说的话,哥们表示“从事技术8年后转产品”的朋友说的话。

二、从技术转产品的暴击

渔歌:你在从事各类型的开发8年后,已然成为一名优秀的全栈开发,而后又从技术开发转产品经理。现在转产品已有一年多,并在客户现场成功落地了一个项目,可以算成功从技术转产品,感觉怎么样?

哥们:我不认为自己已成功从技术转产品经理了,未来我也不一定会继续做产品,可能还是会回到技术。

渔歌:为什么你觉得还不能算成功从技术转产品?甚至未来不打算继续做产品经理?

哥们:差距与是否适合。一方面身边有很优秀的产品经理,我在自己和他们身上感受到的差距很大。另一方面,在客户现场的这一年,虽然从项目结果看还不错,但我知道自己内心还有很多问题没有解决,也不太愿意去解决。

渔歌:什么样的差距?又是什么样的问题你觉得还没有解决,又不愿意去解决?

哥们:有很多。有的话说起来很简单,比如客户视角,但真在其中时,是否理解什么是客户视角,客户视角也有深有浅。我现在做很多事情,是没有客户视角的。虽然我知道自己没有客户视角,但也不太愿意客户视角,因为担心自己一旦客户视角,我也出不了好的产品方案,技术资源也不够,所以还不如不客户视角。这是我到现在都一直存在的问题。渔歌:客户视角是产品经理工作中最源头性的,我们晚点展开详细聊。先整体说下,从技术转产品,你觉得最重要的是什么?

哥们:思维的转变和意识的扭转。

渔歌:什么样的思维,什么样的意识?哥们:最主要的是从代码视角到客户视角。这种思维的转变我经历了至少四个阶段:
一开始认为用户视角是个可有可无的东西,无所谓。在摔的很惨之后,才知道用户视角不可或缺;知道用户视角很重要,但以为掌握用户视角很容易,在被现实打脸多次之后,才发现“客户视角”4个字做到很难;知道自己没有用户视角,但不知道怎样能有用户视角;知道用户视角很重要,但不愿意从用户视角去思考,因为有很多思想负担,总觉得自己没能力出好的产品方案,技术也实现不了,心有余而力不足,这也是我现在觉得自己不适合做产品经理的一个原因。

渔歌:看来这一年,经历很充实。这4个阶段,我们都可以展开讲讲,你经历了什么,又是怎么熬过每个阶段。除了用户视角以外,还有其他什么很重要的吗?哥们:建立产品的系统化思维,不做没有产品架构的功能设计。格局小了,就永远在打补丁,补丁打补丁,就像小时候看电视剧,丐帮的衣服一样。还有就是要有补短扬长的意识,不是扬长补短,不要老想着技术是自己的优势,就去指挥技术写代码,搞的合作的技术方不爽,这样很尴尬,一方面自己的产品功底没长进,同时,合作下游还不满意,那就太失败了,容易对自己没信心。渔歌:这个总结也很到位。那根据你前面提到的,我们后面的聊天就分成6个部分来讲:
你是如何意识到用户视角不可或缺的?你是如何发现拥有用户视角是件很不容易的事?在发现自己没有用户视角,为什么无从下手?又怎么解决的?发现没有用户视角,也知道用户视角不可或缺后,为什么你不愿意用户视角?产品的系统化思维是什么?什么让你感受到做产品一定要有系统思维?补短扬长和扬长补短的差别是什么?

哥们:好的,可以。好的产品经理都像你一样,有超强的逻辑归纳能力。

(听到来自朋友表扬,渔歌感觉如沐春风,哈哈)

三、不可或缺的用户视角

渔歌:我们进入到第1个话题,你是如何发现做产品的过程中,用户视角不可或缺的?

哥们:自己经历了从技术转产品的阵痛,客户对我的沟通和产品方案一直不满意,这时有一个高手在旁指点,瞬间形成反差,就意识到这个问题了。

渔歌:来,要听详细故事。

哥们:你知道我是从全栈开发,被迫转产品经理的。当时组织架构调整,团队职能做了调整,客户的项目做了一半,原来的产品经理被强行调离,我被强行放到产品和交付的位置上,在没有培训、没有人带的情况下,就直接被扔到客户现场了,要对整个项目兜底负责。

渔歌:这个过程,你遇到了哪些超出自己预期的问题?

哥们:整件事情都不在自己的预期内,每件事情都硬着头皮上。没勇气和客户沟通,在去客户现场前,要给自己打很多次气,还是没勇气去,都是不得不去的时候才去。实际上我需要和客户建立好的关系,时不时和客户聊。但我就一直拖着不跟客户聊,因为我不知道怎么聊,也不知道产品要怎么做。自己纸上打了好几次草稿,也打了好多次腹稿,先跟客户说什么,再说什么,依然没有信心。

渔歌:有这么难?我以为你去客户很顺其自然,不知道内心这么挣扎。

哥们:我是个后台技术呀,忽然所有的事情都压过来,要直接面向一线。刚开始做产品经理,真不知道怎么和用户沟通,对这个业务领域懂的也不多,也不敢问客户,怕客户嫌弃我不专业,压力太大,真的担心自己哪句话就搞砸了。

渔歌:那后来呢?

哥们:丑媳妇总要见公婆,我拉了项目的商务负责人一起去客户那。反正商务和客户关系很好,即使我搞砸了,商务都会收场。

渔歌:这是很聪明的做法,给自己找靠谱的战友。

哥们:是啊,也幸好有好战友,要不然不知道怎么搞。现在想想,我干了很多糗事,回想起来后背发凉。渔歌:比如什么?

哥们:第一次去客户现场的时候,险象环生。客户当时在讲他们遇到的业务问题,业务目标。做为产品经理,本应顺其自然的往下深挖问题的表现是什么,又是哪些原因造成这些问题,这是产品原型的重要输入,也是产品经理在和客户深度沟通中建立信任关系的过程。

但我不懂怎么聊,又很紧张,于是不鸣则已,一鸣惊人,一开口就问客户:“这个问题应该怎么解决?我要判断下我们来不来得及做,我们资源很紧张,万一来不及怎么办?”

客户原本在低头刷手机,被我这几句话瞬间提神,抬起头,微微睁了眼睛看了我一眼,稍有不悦的说:“产品方案你后面会出的吧?到时一起评审。”

听到这话,我瞬间就更紧张了,我说:“X总,我们现在资源真的很紧张,老板们天天问我什么时候能结项?”

这时,我们负责商务的同学可能被吓到了,踩了我一脚,示意我不要说话。商务圆场道:“X总,哥们是钢铁直男,太紧张了。他这么问是因为项目很重要,我们公司内部管理也有要求,他已经向公司额外申请了开发资源,并且全团队的同学后面几个月都没有周末,不管怎么样都要保证您的项目保量。所以从技术角度看,需要提前判断什么样的解决方案是最合理的,他也能更好的协调资源。”

渔歌:你真是语不惊人死不休。你们商务估计被你吓出汗了。

哥们:哈哈。客户听到商务的解释后,立马转阴为晴,还笑着跟我说:“不要这么大压力,该休息休息,别把身体搞垮了。如果对需求有疑问,可以到我们这里来驻场几天,你就理解了。理解了需求,出方案对你们来说是很简单的事。”

我们商务又赶紧接话到:“X总,您说的对。后面我们会多过来和您沟通,一定保质保量完成项目交付,不能给您丢面子。”

渔歌:有个靠谱战友,你很幸福啊。

哥们:我当时还是懵的状态,感觉自己反应过来,又似乎没反应过来,又捅了一刀。

渔歌:你又干了什么?

哥们:我当时说,“X总,我们确实压力很大,我还是要问清楚项目什么时候能完成交付?交付标准是什么?来不来得及写代码?到底要上多少功能?要有一个明确的结项时间点,我的资源要撤出去做其他安排。”

渔歌:我冷汗都出来了。无法想象,你一年前是这样和客户沟通的。

哥们:我们负责商务的同学,在桌子下不轻不重的踢了我一脚,明显比前一脚重的多,还很严肃的朝我闭了眼睛,示意我闭嘴。商务同时陪笑脸道:“技术直男癌,有药吗?今天算是见识了,哈哈。X总,他的问题还是在考虑背后的资源,看要不要协调更多的资源进来,项目的市场影响力很大,你们是行业风向标,多少人看着呢,也是我们的标杆客户,所以格外重视。”

然后,客户哈哈大声笑道:“没事的,一步步来。咱们一步步把需求理清楚,交付时间和标准按照合同来。交付早了,你们就可以提前撤出,交付来不及,我们也都可以协商,大家一起把项目做好。”

会后,客户私下问我们商务,我为什么这么紧张?因为一直以来双方合作都非常好,我的问题让客户感觉很奇怪,感觉要随时撤离项目,不是要把项目做好。

渔歌:你们商务是怎么帮你圆场的?

哥们:商务知道我从技术转产品,被直接扔到了客户现场,心理压力很大。但他不能这么跟客户说,因为客户如果知道项目产品&交付负责人不懂业务,不懂产品,是技术出身,这对双方合作会产生很大的质疑,双方的信任关系就丢了。

所以,商务只能说:“为了更好的支持好项目,公司决定让我所在的团队来支持这个项目的产品和交付,因为我们的资源、差旅都比其他团队更有保障。只是哥们是直男,刚来压力有点大,有的问题也不知道怎么跟您沟通,但人是很靠谱的。X总您放心,我们会全力保障项目,你也知道这个项目对我们的意义,有问题我们都会解决的。”

渔歌:然后呢?

哥们:这个客户是好客户,商务也是好商务。客户跟商务说,让他转告我不要有压力,我们项目一直合作的很好。

渔歌:这是你们商务跟你说的?哥们:是啊。我跟商务是一条船上的。商务那天私下来找我,跟我说不要有这么大压力,不然压力会传递给客户,本来好好的项目会被搞砸。我当时还认死理,继续跟商务掰扯没资源的问题,现在想来我可能当时真的是猪队友。

渔歌:对你来说,从技术转产品,又直接到客户现场,这需要有个过程。以前做技术的时候,扮演的角色是怎样多快好省的完成开发。现在做产品了,你得自己定产品方案,让别人来开发。

哥们:当时我们商务说了我几句,我当时听着不太爽,现在想来还是有些醍醐灌顶的。

渔歌:说了什么?

哥们:我们商务跟我说,不要紧张,这个项目妥妥的是必胜项目,有任何问题他都会兜底,我瞬间感觉被打了一剂安心药,没那么惶恐了。商务说,最重要的是先弄清楚客户的需求是什么,要解决什么问题,再看产品怎么设计,然后才评估技术资源。如果需求和产品设计有问题,随时沟通,再不清楚就跟客户对。但不要老想着要写多少代码,代码不是按斤卖的,也不是按行数卖的,客户要的是解决问题,不是多少行代码。我当时听着心里挺不爽的,他们站着说话不累,代码都是要人写出来的,我是真担心资源不够。

渔歌:那你现在为什么觉得你们商务说的是对的?

哥们:其实当时我就觉得商务说的是对的,只是一时自己很难接受和改变。毕竟自己一直是写代码的,忽然有人跟我说代码不重要,要搞清楚客户需求,好像我以前的工作都没有意义了。但他的话确实是对的,我一直没有从技术视角切到产品视角,哪怕现在我都觉得自己没有完成这种思维转换。

渔歌:你的经历有特殊性,从技术转产品,没有任何过渡,也没人带,直接到客户现场格斗,还是被迫转型,所以就直接暴露问题了。但也真实的反应了从技术转产品后,首先要学会站在客户视角,去思考问题,看客户的需求是什么,然后怎么设计方案,而不是上来就直奔怎么写代码,什么时候能把代码写完,怎么能多快好省的写代码。

哥们:从技术转产品,会有一定的思维惯性,但用户思维的转变是第一位的。这样的场景在这我身上发生了大概有五六回,都是被外力强行刹车,我才开始有这种思维转变。

渔歌:我理解用户思维的关键:
让自己成为用户,设身处地的站在用户的角度看问题,梳理问题,把自己当成客户本人,感同身受,痛用户之痛,急用户之所急,思用户之所思。产品经理要学会把自己秒变小白,聆听、观察、感受客户的需求,不是自带优越感藐视客户,甚至把自己的想法强加给用户。超越用户,大部分用户只能提出他们遇到了什么问题,只有少数用户能给出背后的原因,更少有客户能给出解决方案。产品经理必须要在成为用户之后,从用户问题中抽离出来,超越用户问题,抽提出解决方案。

哥们:其实我内心到现在还是战战兢兢的,因为我很清楚自己没有站在客户视角,成为用户这步我都做不到,更不要说超越用户。

在我从技术转产品的过程中,一开始完全没有意识到自己的技术惯性,后来意识到客户视角很重要后,我时常提醒自己忘掉技术,先看客户需求。

渔歌:有了用户视角,知道怎么去发现需求,定义需求后,其实后面就顺理成章了。

哥们:这是对你这样优秀的产品经理来说,对我来说不是的。即使知道用户视角很重要后,我依然走了很多弯路,比如:
知道用户视角很重要,但误以为用户视角是件很简单、很容易的事;知道用户视角挺不容易的,但完全不知道该怎么有用户视角;因为各种思想包袱不愿意用户视角,后来发现一开始错了,后面基本都是错的;


四、误以为用户视角很简单,其实不是

渔歌:一开始误以为用户视角是件很简单的事,这个想法是怎么被击碎的?

渔歌:你在用户现场被暴击,又被商务拯救后,已经意识到用户视角不可或缺。那当时为什么觉得用户视角是个很简单的事?哥们:那是自以为是的阶段,愚蠢的以为知道和会是一回事,实际上是两码事。渔歌:具体的过程是什么样的?

哥们:当时一方面觉得前任产品经理在项目交接前,已经把产品框架、结构、细节都铺垫的七七八八了,他跟客户都聊过了,客户也很满意。当时前任产品经理就差没写PRD了。而我做这个项目的开发也有半年了,觉得自己对这个业务多少还是了解的,虽然自己是技术,但挑战产品经理的事也没少干,没吃过猪肉,难道还没见过猪跑吗?

所以一开始被安排到这个位置上,自己内心是有担心,但也没有那么担心,觉得还是可以搞定的,因为商务靠谱,也可以请教前任产品经理,技术资源都在自己手上。所以内心觉得也没有那么难。尤其当我在客户现场被客户鄙视后,我们商务还能完美圆场,更坚定了项目必胜的信念。

渔歌:后来,你怎么发现用户视角不是很容易做到的?

哥们:当时和客户现场沟通方案,举个例子来说,要上10个功能,前任产品经理已经把其中8个功能的框架、细节完成,并和客户沟通好了。问题就出在那2个还没有画的功能,当我自己动手出产品方案的时候,真不知道该从哪里下手,画了删,删了画,内心煎熬了好几天,越煎熬越心慌,越不知道要出个什么东西。

心里想着就剩下2个功能要交差,反正一定要交差,怎么交差不重要,重要的是交差。可是怎么办呢?我不是用户,不知道用户要什么,我也不是这个行业的专家,如坐针毡,然后也没人可请教,因为这个业务领域很纵深复杂,身边懂的人就只有前任产品经理。

渔歌:那后来,怎么办的?

哥们:后来只能厚着脸皮找前任产品经理,让他帮忙出方案。幸好有好人卡,前任产品经理在A4纸上详细画了业务实际操作流,一共分成八个步骤,以及每一步的详细内容和关键点。

其实我当时还挺想恬不知耻的请前任产品经理帮忙把PRD出了,但又想着画在A4纸上都有3页多,内容太多了,所以没好意思开口,况且他也忙的脚不沾地,不会有时间帮我出PRD。

但好歹有了A4纸上的内容,自己也算心中有数,然后我就又回到了第一个状态,觉得不就是从线下的纸上到PRD,就那么回事,没什么搞不定的。

渔歌:再然后呢?又遇到了什么问题?

哥们:我就自己出PRD,也没跟客户沟通,直接开发了。后来,去客户现场演示,前任产品经理之前准备好的8个功能都没有问题,但客户对我出的2个功能始终不表态方案是否通过,但客户也提不出更好的方案。

从客户现场回来后,我继续求助前任产品经理,请他帮忙看方案。前任产品经理问我客户反馈,我说客户问我有没更好的方案,其他客户也是这样的做的吗?但客户自己提不出建议。

前任产品经理笑着说,一般来说客户能把他的痛点和诉求告诉产品经理,就已经是很好的客户,你还指望客户给你出方案,那这是绝顶优秀的客户,这概率太小。产品经理不能寄希望让客户出方案,客户只能说需求,甚至很多客户需求都说不清楚,得产品经理自己去挖需求。

然后,前任产品经理帮我重新梳理了产品框架和细节,告诉我哪些要在第一屏展示,哪些在第2屏展示,哪些要缩起来,被他指点一二后,产品结构变的很清晰,跟我出的方案截然不同。

渔歌:那挺好的。他第一次在纸上给你画的可能是业务流、信息流,需要你自己抽提成产品。你原本以为出产品方案是一件很简单的事,结果发现不是那么回事。

哥们:是的,从技术转产品经理后,发现自己以前经常BB产品经理,其实BB的挺没道理的,以前不知道产品经理要考虑这么多,首先要客户视角,挖掘出问题,就连这点,很多人都做不到。然后产品经理要把客户需求产品化,形成有框架、和有细节的产品方案,这其中体现了结构化思维、逻辑思辨能力,画demo只是最表层的结果。而所有的产品设计依然要站在客户视角,并且有结构、有重点。所以我也就知道其实客户视角4个字,听着容易,做起来很难。

五、不知道该怎么有客户视角

渔歌:前面我们聊到用户视角不可或缺,也不是一项很容易具备的能力,所以你后来用了一些什么方法培养自己的客户视角?

哥们:其实很长一段时间是不知道怎么做。后来才慢慢的找到一些小技巧。而且我现在也依然不认为自己已经有客户视角了。

“客户视角”这4个字涵盖了太多的意思,可浅可深。我的认知是逐步构建的,对需求的理解也是逐步深入的。

就好像很多年前我可能觉得凡事都有对错,现在不会再这么想。对用户视角的理解也有这样的过程,一开始以为就是这样,就是那样。等过一段时间,回头一看,发现其实不是那么回事。真正能客户视角的人并不多,对客户需求的理解层次也千差万别。

渔歌:罗马不是一日建成的,但总要有建成罗马的目标。

哥们:一开始真的不知道该怎么做。更多是向客户学,向优秀的产品经理学。

渔歌:有案例吗?当时是怎么学习的?

哥们:向客户学,更多的是去听、去观察、跟客户混的很熟,这样才能看到立体的、最深刻的东西,不然多是表象。客户也不会在还没有和我建立信任之前,掏心窝子的告诉我很多背后的东西,毕竟2B的产品,客户内部的组织形态、人员都有很大影响。

渔歌:你是怎么向客户学习的?

哥们:其实是一种交换,如果我身上一无是处的时候,客户不会待见我。虽然在产品方面我还很菜,但在我有其他的优势,比如我比客户更了解整个行业的变化,我能看到很多客户看不到的东西,虽然这些东西我也是向别人请教来了,但这些信息由我来告诉客户,客户会觉得我还是有价值的。

一旦我有价值,客户就会愿意跟我聊天。再加上随着我的成长,适当的时候我还能给客户一两个小彩蛋。时间长了,客户对我的信任增加,就会把我当朋友。

客户把我当朋友后,即使我有些做的不好的地方,客户对我的容忍度也高了。客户把我当朋友后,也就会慢慢跟我讲背后的问题和思考,我也就能逐渐看的更清楚,为什么会有这样的问题,产品设计要怎么处理,这就是向客户学习的过程。

我还是很感谢我们商务的,我们商务帮我在背后搞定了好几个彩蛋,对客户来说都是好消息,但商务为了帮我在客户那建立信任,主动把这些彩蛋都提前埋伏好,并且让我来打开这些彩蛋。

渔歌:你们商务完全可以把功劳都算在自己头上,为什么要帮你呢?

哥们:因为大家是一条船上的,商务不能一直帮我擦屁股,他太忙,要兼顾的事太多,商务也需要产品去帮整个项目加分,项目做得好,大家的结果都好。但能这么无私的帮忙的,很难得。

渔歌:你转型的运气不错,有靠谱的带路人。这对职场人来说可遇不可求,当然前提也是你自己靠谱。

哥们:我有两个贵人,一个是商务,还有一个是前任产品经理。前任产品经理是领域专家,杠把子。在离开这个项目后,几乎有求必应。

渔歌:这位贵人为什么会这么热情的帮你?

哥们:这可能就是优秀产品经理的情怀。这个项目他是始作俑者,也是力排众议坚持抗下来的人,没有他就没有这个产品。虽然他被动调离,但他对这个业务领域深信不疑,事实上确实在整个市场上掀起了一股热潮。但这是纵深、复杂的领域,需要足够的耐心和恰到好处的时机。在他身上,除了学到很多业务和行业知识外,我看到了产品经理的信仰。

渔歌:产品经理的信仰,很喜欢这个说法。

哥们:产品经理有很多种做法,可以是赚钱养家的一份工作,也可以浑水摸鱼,也可以是信仰。我接触到的大部分是前两种,有信仰的产品经理还是很少的。

渔歌:哈哈。越来越深刻的讨论。这部分,有机会的话,专题讨论,说说我们身边那些有信仰的产品经理。

哥们:好呀,我无法成为有信仰的产品经理,但不妨碍我欣赏他们。

六、思想包袱太重,不愿意客户视角

渔歌:话说回来,你在理解了什么是客户视角,怎么逐步建立客户视角后,为什么会不愿意客户视角?

哥们:之前提到我出的方案客户不认可,我只能找前任产品经理帮忙。在前任产品经理帮我调整产品方案后,我按照自己的想法,对方案做了减法,做了一些调整,然后去客户现场沟通。

渔歌:为什么做减法和调整?

哥们:因为技术资源不够啊。前任产品经理出了一个很完整的方案,但我就这么多资源,要考虑技术兼容性、可复用性、持续迭代的节奏,还要考虑能不能搞定那帮开发。这业务太复杂,开发理解不了其中的业务逻辑,让开发了解复杂的2B业务逻辑实在太难了,因为2B的业务和他们的生活简直就是两个星球。

既然开发不理解,就肯定会反弹,挑战这不合理,挑战那不合理。既然要被各种挑战,我干脆就把需求砍了,因为我说服不了他们,说服的成本也太高。干脆砍了,省心省力。

渔歌:那客户那呢?

哥们:可能是因为我第一次给客户的方案太差了,就把客户期望降下来。前任产品经理的方案虽然被我改了很多,那也比我第一次给客户的方案强,至少逻辑清楚了,客户知道怎么用这个产品了。所以客户说比上次好,但我能感觉到明显没超出客户的期望。客户开心的时候会连连点赞,但客户对我调整后的方案只说那试试吧。

渔歌:那后来又怎么发现所有的问题都绕不过去?

哥们:因为产品上线后,当用户真的用起来,就发现缺胳膊少腿,因为我为了节省开发资源,最小化开发成本,砍掉了前任产品经理方案中的内容,结构也做了调整。产品上线后,客户不断提优化需求,比如少了筛选项,客户没法在海量的商品中找到他关心的那个,客户吐槽产品用不起来,这产品看上去好,实际上上下左右都是断的,被架在空中。所以客户视角真的没那么容易。

渔歌:那后来怎么处理的?

哥们: 因为这是给客户做的定制化方案,会有下期项目,就包在下期项目中。在这个项目,如果没有商务加持,没有前任产品经理友情帮忙,项目很难收尾,所以我也是沾了别人的光。

项目过程中,我一开始以为用户视角是个很简单的事,后来发现其实不是那么回事,再后来不知道该怎么有用户视角,到不愿意用户视角,因为各种产品、技术、沟通顾虑,到最后产品上线后问题暴露,发现必须有用户视角,前期回避的问题后期都无法有无法逃避。但这个认识不是一蹴而就的,是一个反复螺旋上升的过程。

七、强技术惯性思维,缺产品结构化思维

渔歌:前面你讲到,做为产品经理,除了用户视角外,还需要系统化、结构化的思维能力,还需要取长补短,不是扬长避短。你觉得从技术转产品后,最大的几个转变是什么?

哥们:一是角色转变,做技术的时候,主要是接活、干活,怎么能多快好省的把活干了,不出故障;做产品经理后,最重要的是自己找活干,用产品经理的话术来说,叫定义需求,这需要很强的用户视角、行业理解和产品规划、设计能力。

二是要有产品经理的专业技能,比如系统化、结构化思维,产品框架是什么,业务流程是什么,怎么做产品规划,怎么做产品设计。在我刚做产品经理的时候,想法很天真,客户要什么,我给你什么,就像一堆柴火堆在地里,用户要什么就自取。实际上做产品至少是搭积木,再往上是设计积木。先说搭积木,也有上下左右的结构关系,不是一堆柴火堆一起,结果用户就连多看一眼的兴趣都没有,因为看不懂或者懒得看。

三是要最大程度的补短扬长。其实从技术转产品,并没有太大的优势,一不小心仅有的那点技术优势还容易变成劣势,因为喜欢自以为是的指挥技术去写代码,总觉得他们技术资源评估多了,还有产品经理要事无巨细,评审、测试、bug修复、资源协调都要找产品经理,除了这些之外,要命的是产品经理还要花很多时间汇报,这种事无巨细,还要高度对我的挑战挺大的。每点都是挑战,如果不是喜欢做产品经理,会挺难的。

渔歌:听上去主要的问题是定义需求、产品设计、产品规划、项目管理,还有自己的心态和定位调整问题。

哥们:是的,这也让我至今依然觉得自己不适合做产品,更适合简简单单写代码,我不是能来事的人,却需要我去干那么多不喜欢也不擅长的事。

从技术转产品不是简单换了一个工作内容,是整个人都要脱胎换骨。做技术的时候,是自己完成一件相对确定的事,大不了就是几个技术之间扯扯皮,这是前端干还是后端干,再挑战下产品,但总的来说是一件确定性很高、单兵作战的事。

而做产品经理,需要自己去找方向,去定义产品或需求,做什么不做什么,再和各方协同一起去把事情搞定。

显然,做技术时,做人做事都比较简单,一条直线,虽然也要背锅,但产品要背的锅更多。

渔歌:哈哈,你可以做产品经理的代言人,帮产品经理伸张正义,宣传下产品经理有多不容易。

哥们:从技术转产品要慎重,不是说不能转,得看自己是不是这块料,是不是志在产品经理,不然真是五内俱焚。我是幸运遇到了很好的搭档,能帮我兜事,出乱子都不怕,要不然现在想想也是后怕。

渔歌:咱们说回来,你觉得产品设计、规划上主要难的是什么?

哥们:我目前还只能说产品功能设计上的感受,产品规划还没碰过,我觉得自己暂时还没有能力做产品规划。以前做技术的时候,看产品经理们做的设计、规划,心里觉得也就那样,一堆毛病。自己做的时候,一开始觉得产品功能设计很简单,就像造个房子,反正能住人就行,无非好看难看而已。实际上不这么回事,这是件很专业的事,一不小心造出来的房子,业主就连小区大门都找不到,更不要说房屋承重这种专业问题。

渔歌:你很能融会贯通。

哥们:经历多了,就会有感受。我当时那2个功能怎么画都不对,哪怕前任产品经理已经帮忙把结构都画出来了,我出的产品方案,客户还是不认可。这其中最大的问题是我缺少系统化的思维。

在产品经理眼里,整体的业务流、信息流有结构、有主次。先解决主要问题,再解决局部问题,最后做微调。要根据用户视角下的业务去设计产品,先做什么,再做什么,而后做什么,哪些是重点,哪些要有但只是留个口子,哪些这期可以先不做,会有这样的主次、优先级。

我一开始做的时候是没有感觉的,感觉就是一堆柴火堆那,加加减减很容易。但对于产品来说“少即是多”,堆了一屋子,客户反而不知道该干嘛,总不能把自己埋进去大浪淘沙。客户首先需要的是解决问题,其次是高效的解决问题。

渔歌:领悟很到位,可以逐步打磨自己,变成全栈开发+产品。

哥们:这话说的容易,其实很难,每个环节都需要自己用心思考、积累,也需要有好的机遇,还得遇到好的指路人,不然我到现在依然是从技术视角去看产品。就目前而言,我只能说自己比很多技术更理解产品,但让我独当一面自己做产品,我还需要很多磨炼,对于一个做了八年开发的人来说,技术的惯性思维很难改变。

渔歌:你提到技术的惯性思维,是指什么?

哥们:比如说我总想以开发成本最小的方式去完成一个确定性的任务,所以我会引导用户,或者就把产品设计成按照技术视角最优的方案,这种惯性思维很强大,一时半会儿扭转不过来,这样会导致产品架构、功能先天就有缺陷,即使我知道对用户来说不是最优方案,我都没有动力去调整方案。

渔歌:能举个例子吗?

哥们:比如说我们给客户交付的一个功能,是在其他客户那已经交付过的功能,但客户已经有很多反馈,这个功能需要迭代、重构。在这个客户交付的时候,我们本应该用重构后的功能去交付,这样一方面原来的产品顺其自然迭代了,同时这个客户的体验会更好。但我从一开始就排斥这么做,直接给了用户老的方案。

渔歌:为什么?

哥们:一方面是因为我也不知道什么样的方案是更好的,虽然用户吐槽有很多,这个领域我认为自己也不专业,不知道重新弄个方案会不会更好,甚至可能变得更差。另外,重构功能就意味着要重新开发、部署,这个工作量也是我不愿意承担的,就想着多快好省把活干了。

渔歌:现在再回头看,如果重新来一次,你会怎么做?

哥们:我会继续向前任产品经理指教,让他帮忙出方案,技术评估资源投入量。如果性价比还不错,应该要重构。如果性价比很差,那就要选择性的做优化,不是直接把有问题的产品给客户。

渔歌:上线了后,客户那里有什么反馈吗?

哥们:我们整个项目中,有做的非常好的内容,也有些做的不好的内容,所以整体来说是符合客户期望的,所以客户不会跟我们细扣。但我自己心里清楚,有很多地方做的不好。

渔歌:所以这个方案也能跟客户交代,只是你对自己的要求比较高,希望能给客户更好的交付。

哥们:这么说也不对,因为我在一个纵深和复杂的领域,没有可以借鉴参考的,都是自己去尝试。这个过程本身有迭代的过程,如果是优秀的产品经理,会加快迭代速度。像我这样刚从技术转过来的产品经理,更多还在求稳,不犯错,最少资源把任务完成掉,并没有寻求最优的解决方案。我现在的做法,从短期的角度来说,资源投入是最少的,在相对长的时间里,很可能造上去的能力都要重构,实则是资源浪费。

渔歌:你是一个对自己有要求的人,加油!

哥们:我身边有很多非常优秀的产品经理,他们在解决问题上是一把好手。我更多的还是在学习。

渔歌:我们再说回到项目管理和个人心态上,你觉得从技术转产品后最大的挑战是什么?

哥们:是心态和思维。还是那句话,技术解决的是一个相对确定的问题,任务确定后,大多数时候自己单兵作战,而产品要在不确定环境中,找到确定的问题和解决方案,再和业务、技术,甚至法务、合规、财务一起去解决问题。产品经理面对的是多重不确定性,这可能也是产品经理很容易心累的原因。

渔歌:感谢对产品经理的理解。

哥们:我以前是服务产品经理的,经常会觉得产品经理不靠谱,也老挑战产品经理。其实现在回头看,很多是无厘头的挑战,因为我并不知道面临整体环境是什么,是不是拿其中一个小细节用放大镜放大了?虽然技术的挑战不是没有道理,但在自己做了一段时间的产品后,觉得之前的挑战有时候太吹毛求疵,缺少全局,技术无法提出全局性的更优解,只能拿一些很容易理解的点来掐。

还有就是产品设计中要考虑的因素太多,绝不止用户需求,还要考虑产品本身的定位和长远发展,有时候就是要让用户多走几步,有时候必须让用户少走几步,并不是用户想怎样就怎样。

渔歌:从技术转产品后,在项目管理上有什么感受?

哥们:以前做技术的时候,我们的产品经理对我们挺好的,去哪里玩都会带东西来给开发,还偶尔请我们吃个下午茶,或者吃个饭。那时候觉得是产品求技术,很多产品经理都这么干,所以也就开开心心一起耍。

当我做产品经理后,发现产品经理真是个苦逼的岗位,明明是工作,为什么要拿自己的钱请大家吃吃喝喝,还要各种花式哄。产品经理也是人,承担了比开发更大的压力。我转产品后,也偶尔请开发喝个奶茶,吃个周黑鸭,但确实没有以前的产品经理请的次数多,我不知道是我的思维还没扭转,还是怎么回事?

渔歌:但凡能用钱解决的问题都不是问题,何况是小钱。产品经理要操心的事太多,如果花点小钱,大家就能开开心心把活干好,那也挺好。何况工作已经很苦逼了,能找到快乐,也挺好的。

哥们:这个说法也对。但我现在依然觉得还要看情况,不会经常请,搞的产品请技术好像应该的。我更喜欢被请,哈哈。在我从技术转产品后,我曾经也心里不爽,毕竟对我来说这只是工作。

渔歌:除了这个之外,还有其他什么印象深刻的感受不?

哥们:就是前面提到的,一来事无巨细;二来我总想教开发写代码,开发不乐意了,就开始有矛盾。

渔歌:具体说说?

哥们:事无巨细这个很好理解,跟产品相关的,任何人任何事都随时会找到我,比如文案不合理,交互方案不合理,还要自己去做测试验收,还要操心上线后运营,有bug呀……事太多。如果不是擅长处理千头万绪的事情,同时并发多线程,或者对做的事情有发自内心的热爱,蛮难扛下来的。

渔歌:我也一直觉得产品经理需要有一种热爱,有了热爱,就会有自驱,就会想要做的更好。

哥们:这是一方面,还有就是可能技术的惯性太大。我认为自己的技术能力还不错,但当我转换角色后,变成是其他技术来开发,开发会跟我说这个很复杂,那个很复杂,要多少人天,我会条件反射的反驳技术,这不是很简单,那也很简单,最多只要几天就好了,我甚至会忍不住把开发赶走,自己去写代码。

但这里面有个平衡,一方面我现在是产品经理了,虽然说要防着技术忽悠我,但也不能干涉技术领域太多,让别人很挫败,而且技术一旦交给别人,对别人要有信任,也要注意处理方法。

我曾经遇到个开发,天天嚷着需求太多周末又要加班,我直接跟他说不用你干了,我自己写代码,我肯定半天就搞完。实际上我花了差不多一天的时间,一方面我低估了一些东西,另一方面开发从此以后都不太愿意接我的需求,动不动说谁谁不是全能的吗,让他自己写代码,真特么欲哭无泪。所以要管理好自己的心态,摆正位置,用对方法。

八、愉快收尾

渔歌:非常感谢你的分享,相信你的分享会对刚从技术转产品,或者准备从技术转产品的朋友有帮助。

我们总结下,你在从技术转产品的路上核心遇到的挑战是三个层面:
从技术思维转变到用户思维,这个又经历了4个阶段:一开始觉得用户视角可有可无,后来发现用户视角不可或缺;误以为用户视角是件很容易的事,后来发现其实很难;发现用户视角很重要后,不知道怎样培养这样的能力;知道用户视角很重要,但由于各种顾虑,不愿意用户视角。认识到产品需要体系化的思维,产品设计中需要有全局观,在全局视角下,做好功能设计的最优。项目管理需要消耗的精力很多,因为事无巨细。同时由于自带技术能力,导致总是想指导技术写代码,结果搞的技术不愿意支持项目。还有那个有信仰的产品经理,可能是很多人的精神灯塔。

哥们:这段经历对我来说,收获还是很大的,挑战很多,跟做开发是完全不一样的经历。但我目前还只是接触到了产品经理浅层的内容,更复杂的比如商务侧、业务侧、向上汇报侧、产品规划侧目前没太多了解,对于我这样的性格来说,这些领域的复杂度远比功能设计和需求验收难的多。

渔歌:经历这一年的项目和认知的迭代后,你后面有打算长期做产品吗?还是只是打算项目结束,就到此为止。

哥们: 我是个简单的写代码的人,把活给我,我保质保量的干好。但产品经理是一个要自己找活干的人,要找到正确的活,用性价比最高的方式把活交给技术,最重要的是还要游说各方的老板,汇报比干活还重要。技术和产品本身的能力要求有很大差别,我认为自己现在还不具备产品经理的能力。

渔歌:你进能做产品,退能做技术,这个也很厉害。

哥们:没这么厉害,是因为环境,我也是被逼的。对我来说,有一段这样的经历是好的,也是因为公司环境给了我这个窗口。

但从长远的角度来说,还是要想清楚自己的职业规划,产品和技术是完全不同的两条路,可以阶段性游离,就当给自己开阔视野,同时我的这个转型完全无风险,并且转型的阶段性结果对我未来的职业选择是加分项。所以归根结底,我还是挺幸运的。

渔歌:那就祝我们的幸运之星,不管未来是做产品,还是做技术,在能力成长的同时,继续有幸运加持。

哥们:必须的。

采访到此结束。不知道大家看完1.5万字的采访有什么感受?是更坚定了,还是犹豫了,或者不准备转型了。

期待大家的讨论,也感谢好友毫无保留的分享。

#专栏作家#


西湖渔歌,微信公众号:西湖渔歌,人人都是产品经理专栏作家,2019年度作者。11年经验的某大厂产品经理,专注产品和大数据。

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

题图来自Unsplash,基于 CC0 协议
页: [1]
查看完整版本: 技术8年转产品经理,这1年我的经历