先说结论：程序员相对来讲是比较好转产品的
吖少作为一个多年的老产品，圈子中还是有很多程序员转产品的朋友的
A、程序员的现状
程序员每天都在开启上帝模式，他们的工作就是在创造。
只要需求明确，能够从上班到公司坐下的那一刻，戴上耳机，以每分钟200下的速度疯狂敲击键盘，直到一天结束。
程序员工作中最大的成就感来源于写出极其优质的代码然后上线运行，能用一行代码搞掂绝对不用三行，凡人怎么能够企及。随着工作年限的增长以及发际线的后移，这种成就感越来越单薄，随之而来的是无尽的焦虑。
慢慢的，程序员们来到职业生涯的分叉路口。
往左走是继续深造，成为更加牛的程序员，希望有一天能够当上CTO。如果有机会，再写一个改变世界的程序，把小扎按在地上摩x，手指抵着马斯克的鼻子说“你就是个xx”，渡过完美的程序员一生。相对的，他们需要冒着到了35岁还在跟毕业一年的大学生抢饭碗，被迫降薪，甚至被辞退然后去送外卖的风险。
往右走是转型，转型到一个不需要一天到晚出卖体力的岗位，依靠业务能力恰饭。如果有机会，再创办一个公司，融资ABCDEFG轮，在纳斯达克敲钟上市，走上人生巅峰。当然，他们要带着因长期开启上帝模式带来的社交恐惧后遗症去跟各色人物打交道。同时还要冒着“不适合”的风险，回到程序员的岗位，继续跟毕业一年的大学生抢饭碗。
以上使用了比较夸张的描述，只是想表达一下程序员的境遇与心理状态，并没有冒犯的意思。
其实不管转型与不转型，如果不想被淘汰，无论在哪个岗位都要努力上爬，不然只能死在沙滩上了。至于是在技术路上深耕，还是转型到其他赛道，只是个人选择。
从转型的方向来看，比较邻近程序员的赛道就是产品经理了，所以“转产品经理”成为了程序员这个群体常见的情况。
B、程序员的特征
很多事情都是一把双刃剑，有时候得天独厚的优势也会成为你的短板，优势与劣势是并存的，所以吖少更愿意称之为“特征”，而不是单纯的从优劣去描述
1. 邻近的赛道
俗话说“没吃过猪肉还没见过猪跑”
产品与程序员的工作关系是上下游关系，一个天天作为下游环节与产品经理对接的岗位，天然地比其他岗位对产品经理的工作有更多的了解，上手自然也会快很多。
作为一名程序员，能够作为“乙方”去审视产品经理的一切。“如果我是产品，我绝对不会xxx”，程序员转型的产品经理非常能够理解程序员需要的一切，产出的方案通常是极具执行性的。
正因为作为下游方，程序员也很容易对产品经理的工作产生误解。
这么说吧，如果你每天都收到快递员送来的快递，你很容易认为快递员的工作只有（注意是只有）“送快递”。快递员不送快递时，在快递点要干的活，你一件都不了解。
同样的，作为产品经理长期的下游环节，程序员很容易会认为产品经理的工作就是写文档，这是一个大大的误区。写文档是产品经理输出劳动成果的环节，并不是他的核心工作。在进行输出之前，还有大量的收集、分析、演算、设计等等工作。还是举例子来说，比如拍电影，“拍”只是进行结果输出，“如何拍”才是制作一部电影的核心工作。
作为双刃剑，这个特征带来的问题就是程序员出生的产品往往习惯将精力倾注在方案的技术性上，而忽略了业务性。产品经理是服务客户和业务的岗位，所有方案首先要考虑的是业务性。
很多初级产品经理或技术能力稍弱的产品喜欢说的一句话“怎么实现我不管，做出来能用就行了”，虽然任性得有点不负责任，但其实是具有一定合理性的。
2. 逻辑思维
程序员的逻辑思维很强，这是毋庸置疑的。但是这种强，很多时候只体现在单点上。
如果说程序员对逻辑的要求是“精密”的，那么产品经理对逻辑的要求是“全面+严密”的。
产品经理绝大部分时候都是“脑力”工作，产出物常常是很简单的。
“过程是曲折的，结论是简单的”，这句话在产品经理的工作中体现得淋漓尽致。
可能说得有点dry，吖少举个例子吧，比方说我们在app中常见的“注册”页面
从产出物的角度来说，可能只是两个输入框加一个按钮的原型，连一个普通学生都能画出来
但是，绝大部分人都不会知道，产品经理设计注册功能的时候要考虑到这么多的点：
注册的本质是用户创建，用户体系怎么设计？
有几个用户角色？初始角色怎么处理？
有几种场景？手机号注册、邮箱注册、第三方注册？
短信验证码和密码怎么处理？密码如何初始化？
手机号和邮箱哪个作为主ID？从属ID激活流程怎么处理？
手机和邮箱是否允许多对多的关系？
主ID是否允许变更？变更流程如何处理？
第三方注册接哪几家？有哪些字段信息？接口有啥要求？
平台型产品的话，有多少条业务线，不同业务线之间的用户信息的差异？如何做成服务化？
要校验哪些东西（格式、字符、长度、去重）？每一个异常流程如何处理？
... ...
这里就不一一展开了，罗列一些，只是想给大家体会一下。
很多时候，某些点没经过产品的梳理和输出，程序员很可能就会漏掉。
举个常见的例子，
一个图片位，如果产品经理不阐述图片的填充处理方式，有80%的可能性程序员不会针对其进行处理，做完之后你会发现缩略图里全是拉伸变形的图片。
1个完整的正常流程会引出N个分支流程，同时产生M个异常流程。
这些点，在交付到程序员写代码实现之前，产品经理就已经在脑海和草稿上演算了无数遍，然后设计出合理的版本路线，最终产出一个又一个“看似简单”的方案。
还是从双刃剑的角度来说，程序员精密的逻辑思维程能力的确是得天独厚的优势，是绝大部分岗位都无法企及的，然鹅其思维的单一性在转到产品经理之后，极其容易衍生出“马大哈”的毛病。
3. 沟通方式
听得最多的就是“程序员不善沟通”，其实吖少是不认同这句话的。
真正当过产品经理的都知道，程序员是最讲道理的一个群体。网络上流传的程序员恼怒的新闻，无一例外都是被不讲理的人惹怒的。
吖少觉得，跟程序员沟通真的是再愉快不过了。只要方案设计合理，业务价值说清楚，逻辑严谨，文档描述清晰，资源排期合理，程序员哥哥是非常非常好说话的。如果遇上更优秀一点的程序员，当我在沟通过程中把目标阐述清楚，程序员实现的功能可以超出产品经理的预期，这就是传说中的“130%交付”。
奈何现实中，大部分公司的技术岗位都不超过40%，而几乎全部非技术岗位的同学都是“不讲道理”的。这里不是贬低其他岗位的同学，只是想说说非技术岗同学的思维特征。他们一般专注在自己岗位负责的业务版块，效率和业绩就是他们的KPI，当他们遇到问题需要技术介入解决时，第一想到的就是“我想xxx”。
这种“我想”干嘛干嘛的思维是一种感性思维，一般不会过多考虑现状、可行性、资源，也不会主动表达业务价值，一心想着达成KPI，从自己的认知出发提出解决方案。就好像感冒生病的人去医院排号，着急的自己好像快要死了，跟医生说“医生快给我开几片阿司匹林”。开什么药不是你说了算的，同样怎么实现也不是你说了算的。
当这些同学带着这种“不讲理”的思维找到程序员时，就像烟花遇上了火花，瞬间爆炸，灿烂耀眼。
所以，并不是程序员不善沟通，程序员与非技术岗人员天然的存在思维上的差异，这是一道鸿沟，并不是谁对谁错，谁好谁不好。
产品经理大多数时候都是个“精分”群体。面向程序员的时候，需要逻辑严谨，简洁明了。面向业务或者客户的时候，需要深谙人性，挖掘其背后的真正问题。
也就是说，程序员如果转产品，跟下游沟通也是具备得天独厚的优势，但是面向上游环节就得学会新的沟通方式。
以上就是程序员三个最明显的特征，如果想转型产品经理，了解这些信息，发现自己的特长，补全自己的短板，将是你转型路上第一件要做的事情。
C、如何学习？
那么作为一名程序员，如何进行学习，转型成一名产品经理呢？
吖少一直跟同学们说的，老祖宗几千年的智慧早就总结出了如何做成一件事情，无非三个字：道、术、器
道：就是世界观和理论
术：就是方法
器：就是工具
1、学习产品经理的基础思维理论
学校里边没有“产品经理”这一门课，因为产品经理是个综合性很强的岗位，也是一个需要变通性极强的岗位。
这并不是你学会了一些操作流程和步骤就能胜任的岗位。如果没有搞明白底层逻辑，今天你做了一个A项目，明天换一个B项目，你就无从下手了。而产品经理，每天都需要面对大量的未知事物。未知的场景、未知的需求、未知的旧系统逻辑等等。
所以，在学些具体的方法和工具之前，先把思维理论基础打好，方能在后续的学习中举一反三，灵活应用。
还要明确一点，所谓的产品经理基础思维理论，是没有体系边界的。并不是说我了解了哪几个理论就可以了。学无止境，思维层面的东西真的是越丰富越好。
简要列举一些，不在这里展开
常见的理论模型（马斯洛金字塔、AARRR模型、MVP理论、KANO模型、5Y1H模型、5W1H模型等）
流量思维
社会化思维
平台思维
用户思维
极致思维
简约思维
迭代思维
... ...
2、产品经理的基础方法论
还是简要列举
竞品分析
需求分析
用户调研
产品设计
项目管理
数据分析
... ...
3、产品经理常用工具
原型工具（Axure、墨刀、mockplus、sketch等）
流程图（visio）
思维导图（XMind、Mindmanager）
MS微软全家桶（不用说了吧）
外部数据分析（百度指数、谷歌趋势）
内部数据分析（入职后公司用哪个就看哪个，常见百度统计、谷歌分析）
图像处理（photoshop、CorelDRAW）
科学上网（跨境类需要，自行查找）
... ...
------------------------------------------------------------
如果你觉得以上的内容对你有帮助，请点个赞~
文章也是最近才开始写，喜欢的朋友欢迎 关注
我将持续不断的用自身真实经历告诉你如何当一个接地气的产品经理
我是吖少，一个工作十年
亿级营收产品从0到100的产品经理
有任何问题想了解的
欢迎添加我私人微信
littlemanjolly
长按识别二维码添加我