做一名当过程序员的产品经理是一种什么样的体验？
产品经理和程序员之间，还是有一些岗位上的不可调和原因，所以导致程序员觉得产品经理总是刁难，产品经理觉得程序员总是推诿。
如果想说清楚两者的冲突点，首先还是要了解两个岗位不同的工作内容。
对于产品经理来说，他的工作其实是面向市场的，客户有什么需求？运营有什么需求？市场的变化如何？产品的市场接受度如何？
至于这个功能的实现方式，其实很多时候并不会有太多的考量。
例如：我们公司的产品曾经做了一个需求，就是将两种不同类型的订单展示在同样的一个列表内，并且订单中会包含部分订单详情的信息。
原因其实很简单，因为用户在一定时间内并不会有太多的订单，所以有一个查看最近所有订单的列表，按照时间排序将订单列举出来，用户可以快捷的在这里进行操作。
这个需求设计做完以后，交到了研发，研发就暴动了，为什么？因为两种订单由于结构不同，所以是存储在不同的表中，订单的详情也是两张不同的表，现在如果我要对用户的订单汇总，再按照时间进行排序展示，就需要将用户的两种订单查询出来，然后在内存中重新组装，然后再排序，再序列化。
整个过程就十分麻烦，并且由于两种订单结构不同，所以这个合并后的实体也是非常的复杂。
研发表示，这个是一个不合理的需求，这样做是没有意义的，为什么不直接做两个列表呢？毕竟这个是两种不同的业务。
但是产品说，我需要的是让用户看到他所有的订单按照时间排序后的情况，不是某一类订单的情况，然后滑动下去才能看到另一类的情况。这两种订单没有优先级，所以不应该一个在上，一个在下。
好吧，这下子就搞不定了。
有这个例子我们可以看出，程序员是面向实现的，产品是面向用户的，所以，用户的需求可能和实现本来就是冲突的，自然产品经理和程序员就只有冲突了。
那如果这个产品经理以前是程序员，然后转岗做的产品，会不会好点呢？
会好点，但是也好不了多少，在一些简单的实现上，可能做过研发的产品经理会考虑一下实现，再是，由于自己的职责所在，所以，有些实现即使很别扭，产品该这么设计，就还是会这么设计。
而且，有时候，懂技术的产品经理还会和程序员的冲突点更多，为什么呢？
因为他懂技术，所以他会告诉程序员，可以这么实现，对于程序员来说，其实他知道这个是可以实现的，只是实现的方法很痛苦，效率很低，可能数据量大以后，影响性能。
如果这个时候，一个产品经理还在旁边指手画脚一番的话，程序员就会更加的不愿意听你的了。
说不定还会讥讽产品一下：“你能做，那你来。”
所以，如果想要产品和技术和睦相处，那更多的还是需要双方多一些理解，少一些脾气，能够凡事坐下来协商解决。
不然的话，就算是做过产品的程序员和做过程序员的产品经理，吵架的时候也不会少。
当过程序员的产品经理市面上还是不少的。产品经理和程序员首先在思考问题的方式上还是有些不同的。做过程序的产品经理，在设计或实现一些客户需求时，一般肯定都能落地，因为他也考虑了技术实现的思路等。
我做程序员有8年的经验了，虽然没有干过产品经理，但是对产品经理和程序员之间的“矛盾”也是了解一二。
产品经理和程序员核心的矛盾其实在于产品经理在产品设计及需求变更的时候并没有深入的了解过程序，可能他们感觉产品的变更很简单，但是对于程序员来说就是大量程序的重构，而程序员本来就对自己写的代码付出过心血，如果突然推翻，程序员必然会心存怨恨。程序员必然会对产品经理提出的调整方案作出回应，比如懈怠，争吵等。
核心的的矛盾在于：沟通
如果说产品经理在干产品的时候多了解程序的实现以及需求变更会对程序带来的调整及工作量的情况，我相信程序员也不会针对产品经理了。
程序员转产品经理
我个人认为这是个很好的事情，既能好好的干好产品，又深入聊好软件编程的情况，也有过相关的项目经验，这样对于产品本身来说是件好事。
程序员完成的产品
我是一个老程序员，也做了一个狗样的产品，望大家给进行指点指点。项目开源在gitee上，大家搜索：青锋后台管理系统，或者私下给我，我给你们预览地址。（项目源码已开源）
下面附带几张图片：
职业写代码只有 1 年，业余也写了一些，一个人参加黑客马拉松拿过奖，已经转产品经理 2 年多了，平时会关注技术方面的东西，说下自己的一点体会和总结。
优势：
- 数据方面
- SQL，大多数公司的数据的产品化其实都比较一般，很多数据都需要研发来跑脚本，这个时候会 SQL 就基本可以不去麻烦 RD，他们的时间是很宝贵的
- EXCEL，由于有编程的基础，写 EXCEL 的公式基本都是得心应手，查文档基本足够了，复杂点的需求还可以写点 VB 脚本来解决（个人用的是 Google Doc，支持 Javascript）
- Python
- 完成重复性劳动，比如每天要给别人数据周报，SQL 查出来的数据可能格式上不能满足，通过 Python 进行一些格式化，转置之类的操作可以一条命令生成数据周报
- 爬虫，做竞品分析的时候，花两三个小时就能把竞品所有的数据都爬下来（一些反爬虫的需要反编译，绕过验证码之类的估计麻烦一点），统计成图表
- 稍复杂一点的数据分析，近期在学习《精益数据分析》，无计算机背景估计会比较难看懂
- 工具的使用
- Google，任何事情问别人之前，请先尝试自己解决
- 选最好的工具，作为一个超级工具控，在做任何事情之前会为自己挑一件趁手的兵器
- 用好冷门的软件，你能想到的所有功能都已经有现成的软件了
- 尽量使用快捷键
- 复用，写代码的时候要把多处用到的代码写成函数，写文档之类的事情也是一样，做一份 PRD 的模板，自己定义好样式和规则，不要总是重复无规则的劳动
- Bug 定位，遇到 Bug用 Chrome 的开发者模式或者 Charles 之类的抓包工具，看懂自己业务的 API 基本没什么难度，可以很快定位是前端还是服务器或者是数据的的问题，就不用天天跑到研发面前说：这个页面加载不出来了。
- 技术调研，能知道功能大致是怎么实现的，要接入第三方服务时，可以看懂开发者文档，知道什么功能能实现，什么不能实现，不要瞎提需求（不过这里会有个坑，后面说）
- 同理心，能理解研发的辛苦，沟通起来也会顺畅一些
劣势：
- 思维容易局限，觉得用户能理解一切，不用说和用户交流，我经常和同事交流的时候都觉得：你怎么这都不知道
- 项目推动，虽然和研发沟通起来可能会有又是，但是作为产品是需要多方沟通的，要出面撕逼的时候容易怂；对排期没有其他产品那么敏感
雷区：（这其实是我最想说的东西）
- 千万不要觉得自己做过研发，就可以对 RD 指手画脚，需要尊重他人在自己领域的专业性
- 利用技术手段提升工作效率是好事，别陷进去，产品最终拿出来说话的还是有没有解决用户的问题，而不是解决你自己的问题
- 技术调研什么的，还是谨慎一点，判断失误是常有的事
说了这么多，还是乔老爷子的话比较牢靠：stay hungry，stay foolish，平时多学习一点东西，做事的时候谦虚一点。
我就是项目经理/程序员转做产品经理的，基本上产品设计出来之后，连部分通信协议的规格和实现方案都想好了，甚至完成工期也基本上跟研发人员的想得差不多，部分软硬件代码和图我都能给提供，程序员都挺舒服。领导也斜眼看我，不知何故
我的建议是程序员可以转行做运营，但是最好不要转型做产品，原因如下；
首先束手束脚，产品经理要求的是敢想敢干，但是一个产品经理是程序员出身他的思考方式就会从程序员角度出发。想要做什么产品的时候首先想到的是技术上能不能实现，而不是我就要这个产品怎么做是你们的事。
其次产品重技术轻应用，程序员做产品会太过于强调技术而轻视市场的应用性，简单来说就是做出来的是一个技术领先但没有什么市场需求的产品。
第三不利于市场拓展，一个优秀的程序员是需要具有技术思维的，但是一个具备非常优秀技术思维的人基本上不可能或者说很少有能做到市场思维的。这就会导致技术思维盖过市场思维。
综上所述，程序员转型的最好岗位是运营。