背景
我个人的工作背景
作为一个研发部门的tl，近几年先后两家公司都有主导某个业务线的业务架构和技术架构设计、迭代演进的经历。
长期在互联网保险、SaaS、ToB行业，在这方面积累了一定的经验。
过程中和产品经理打交道很多，甚至在很多时候要帮着产品经理不断调整产品方案，使其功能完善，业务闭环。
上家公司有一个业务线特别熟悉，基本跟随0-1建设起来的，基于此甚至带着产品，做过产品方案。
目前公司的情况
现在所任职的公司也是一家ToB类，做产品交付的公司。公司的产品基于低码平台，除了portal外，更多的核心能力体现在server端的流程引擎上。
以上这些，是我不务正业的一小段时间产品经理工作经历的背景和潜在引发的因素。
基于公司目前的一些情况吧，领导找到我，让我兼任一段时间产品岗的工作，会有一个产品助理协助我的工作。理由呢，就是有业务思维，能够形成业务闭环，且公司现有的产品，有技术背景能够更好的进行产品方案设计。
就这么开始了这段PM工作
有这么个机会，在这之前我也想过探索下职业上的一些可能性，加上以前和产品同学打交道很多，也熟悉产品的工作流程，就接了这个工作任务。
没有真正做过产品工作之前的想法
之所以答应接这份工作任务，首先是自己觉得有能做好的可能性：
工作中和产品打交道比较多，和产品吵架基本没输过，甚至和产品协作，带着产品来编写、优化需求方案。
这让我一直以来产生了些迷之自信，觉得我也是可以做、甚至是做好的。
当我真正开始以产品的角色工作时
这段时间的工作主要围绕着以下几个方面在开展：
- 既有一个产品线的工作，主要是承接项目部门提交过来的业务需求，进行分析，出产品方案，提交研发。
text
这部分我主要是负责挖掘原始需求，去除伪需求.
产品助理完成产品方案后，我负责review，确保质量和产品方案的完整性，闭环性。
除此之外，需求进度管理，交付跟进等其余工作的开展。这部分的工作，因为是既有产品的迭代，更新，优化，总体下来工作完成的都比较顺利。
- 新的市场机会下，协助售前完成方案，新产品的需求挖掘、产出产品设计。
这部分的工作真正让我认识到了，技术和产品两个岗位的不同，我之前的想法有点过于单纯和天真了。
这段工作经历让我遇到了前所未有的挑战，痛苦，甚至有时候会自我怀疑：
情况一:
text
说来也巧，中间有一个比较大的行业市场机会，老板亲自带着跑市场。
整体的工作是需要商务、售前、产品紧密又紧张的合作。
往往拿到了一个标，就要立马响应，在从行业政策和行业通用方案基础上，按照具体公司标书的要求，快速响应，
产出方案，供售前进行整体方案的完成。
有2-3周不论是工作日还是周末，不论是上班还是下班，基本处于随时响应状态。
而我作为一个产品，需要解读政策、标书、挖掘需求、形成产品方案。
在整个过程中，老板和领导们还会提出很多自己的想法，有时候会天马星空的。
过程中还好多时候会出现没有get老板想法的情况，方案辛辛苦苦做完了，却被老板不断地批评，指出问题，然后方案反反复复修改。情况二：
text
老板给我讲了一个新产品的想法，让我去完成一个产品的需求分析及产出一个方案。
我把老板的话详细的拆分为了1、2、3、4、5
结果做完之后，需求分析的过程老板不满意，当然最终的方案也不合格。
整个过程中，我主要是聚焦在了1、2、3、4、5上面，以此来形成了产品的闭环，
自己没有需求分析的经验，完整的方法，老板想象中想看到的产品方案，可能是1、2、3、4、5、6、7、8、9甚至还要包含a、b、c、d......情况三：
text
在客户新项目立项的时候，要跟客户聊具体需求，客户表达了自己的需求、痛点和想法，
我就基本围绕着这些一直在客户聊，
产品本身还有很多其他能力，可以帮助客户实现更大范围的需求，
而我自己想当然的认为客户既然不提，是不感兴趣，我也没有去主动引导客户的意识。这一小段经历的思考
这段经历，让我感受到，研发和产品两个岗位比我想象的区别还要大，完全是两个形式的工作。
以前作为研发，我们的工作是从1开始，产品的工作是从0开始。做好一个产品经理，确实不是说随便什么人都能做，所要求的综合能力一点也不少。
与客户的需求沟通方法，如何深入挖掘客户的需求，去除客户的伪需求
科学的方法来产出符合用户需求的产品方案
这段时间的工作是成功的还是失败的？
事情你去做了，就会有收获；面对新的挑战，不要因为一些小的失败和别人的质疑就退缩，怀疑自己。
在面对领导们不停地意见反馈，甚至产生的不耐烦情绪时，我就一个目标，一定要改到领导、客户满意为止，只要老板没说我别做了。
回头从这个角度去看，是成功的，我按时交付了客户需要的产品方案。
但是作为一个产品经理的角色，我应该更积极主动的去完成产品方案的交付，能够引导客户的需求，帮助客户解决更多问题。
从这个角度去看，我又是失败的。
对于正在考虑转型产品的同学，希望我的这小段经历能给你点启发
产品的工作没有各大论坛里说的那样："如果你不知道做什么，那就去做产品经理吧"；
同时，绝大多数人面对的也没有想象中那样美好和高大上，我主导去创造一个产品，生它，养它。
成为一个产品，可能很多时候你面临的，是领悟老板的意图，实现老板的想法；不是完美的方案，而是要满足客户的需要。
研发转产品的优势
- 作为技术出身，能够较为准确的把握技术边界
- 一般来说，程序员的架构能力普遍要强于产品经理，优秀的程序员写出来的代码架构性非常强。除了实现之外，程序员还会思考整体的组织和架构，通常要考虑代码的可扩展性和模块的可复用性。这种思维在产品中同样很重要。
- 从我个人的角度来说，研发的逻辑思维要比产品强。在实际开发中研发经常可以指出一些产品经理没有考虑到的边界情况以及逻辑漏洞。
- 熟悉产品的工作流程 这一点我是相比较那些其他岗位，甚至是非互联网行业的人来说的。前几年，大家觉得互联网行业赚钱，产品岗位的门槛又觉得相对低一些，所以有来自多种岗位的同学转战产品岗位。
研发转产品的劣势
- 需求分析能力弱。
作为研发在工作中，更多的是一个"执行者"的角色，即更多的是思考如何把产品经理的需求实现出来，但是极少会思考产品经理为什么要做这个功能以及为什么这么设计这个功能。
- 用户调研、竞品分析、产品设计、项目管理、数据分析等产品技能弱
在优势分析中，我讲过熟悉产品经理的工作流程是研发的一大优势。但是看过猪跑，跟吃过猪肉其实是有本质区别的。
所以研发虽然知道产品的工作流程及产出物，但是如何做用户调研、竞品分析、产品设计、项目管理、数据分析等等产品技能其实是不具备的。
而这些都是一个标准的产品经理必备的，所以如果要转行这些一定要学。
3.沟通能力弱
这里还要说明大家的一个误区，能说不等于沟通能力强。 能说的人不一定沟通能力就好。沟通的目的在于达成自己的目标。所以沟通能力分为倾听（了解别人的诉求）与表达（传达自己的诉求）。
总结
从上面的分析可以看出，从产品能力（执行力、逻辑思维、学习能力等）上来说，研发还是很有优势的。但是比较欠缺产品技能（需求分析、用户调研、竞品分析、产品设计、项目管理、数据分析等）。
我们程序员一般沟通能力、和人打交道的能力偏弱。 过程中，要直面客户、要直面老板（如果你的老板是技术出身相对好一些，如果是非技术出身，比如商务、市场），这个软技能很重要，了解清楚客户的想法，充分了解清楚老板的意图，才能使得自己的产品方案真正能够着眼实际，能够有落地路径。