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

╰+哭是因爲堅強的太久メ 2022-10-10 06:02 17阅读 0赞

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

渔歌有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呀……事太多。如果不是擅长处理千头万绪的事情，同时并发多线程，或者对做的事情有发自内心的热爱，蛮难扛下来的。

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

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

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

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