当过程序员的产品经理市面上还是不少的。产品经理和程序员首先在思考问题的方式上还是有些不同的。做过程序的产品经理，在设计或实现一些客户需求时，一般肯定都能落地，因为他也考虑了技术实现的思路等。

我做程序员有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，平时多学习一点东西，做事的时候谦虚一点。

我的建议是程序员可以转行做运营，但是最好不要转型做产品，原因如下；

首先束手束脚，产品经理要求的是敢想敢干，但是一个产品经理是程序员出身他的思考方式就会从程序员角度出发。想要做什么产品的时候首先想到的是技术上能不能实现，而不是我就要这个产品怎么做是你们的事。

其次产品重技术轻应用，程序员做产品会太过于强调技术而轻视市场的应用性，简单来说就是做出来的是一个技术领先但没有什么市场需求的产品。

第三不利于市场拓展，一个优秀的程序员是需要具有技术思维的，但是一个具备非常优秀技术思维的人基本上不可能或者说很少有能做到市场思维的。这就会导致技术思维盖过市场思维。

综上所述，程序员转型的最好岗位是运营。

没有啥稀奇的吧，我们公司的产品经理都当过程序员，只是角色变了，考虑问题的思路也变了。程序员只关注自己的任务，关系一个点，但是产品经理不同，你关注的事面，是产品的各个方面，包括供货，生产等。产品经理任务更重，责任更大，是产品的领航者。

说起程序员和产品经理的关系，用相爱相杀来形容最恰当不过，彼此嫌弃又不离不弃。其实，这也很正常，因为两者的知识体系和思维结构不一样，关注的重点也不一样，所以在协同工作过程中，难免会出现一些分歧和摩擦，出现互相埋怨和吐槽的情况。

如果是做过程序员的人来当产品经理的话，这种状况会不会得以改善呢？也许会，也许不会，这个不得而知，但是当过程序员的人，肯定知道什么样的产品经理是程序员会喜欢和接受的。

平等、尊重与理解是第一前提

首先，产品经理应该明确知晓项目/团队的目标，与程序员是同一利益共同体，所有的讨论、分歧、摩擦、思想碰撞都是对事不对人的，也不存在必然的领导和被领导、上级和下级的关系。

产品经理跟程序员之间是平等的协作关系，双方的命运与产品息息相关。有时候程序员对产品倾注的情感，付出的努力，并不比产品经理少；程序员对产品的期望和思考，也不比产品经理低，有时候甚至高于产品经理。

举个例子，大部分的产品经理在设计新房时可能考虑了电梯、逃生通道、水电、电器接入，但程序员想得会更多，他们会关注停电停水之后房间里需不需要备蜡烛、紧急照明灯以及储备用水。

程序员是产品/项目的实际实施者和创造者，产品经理是帮助产品创造的设计者和连接者，是团队中的一员，而不是突出的个人。放弃你改变世界的想法，以平等、尊重彼此的心态，和程序员们做朋友、做队友。

不打扰，多给程序员时间和空间

产品经理要学会在大多数时候，让程序员忘了你的存在，但在最需要你的时候你才挺身而出。

程序员非常讨厌的一点是当他思维在高度集中、效率奇高构建思维、飞快码字的时候，产品经理不断地跑过来说一些无关痛痒的“点”打断他的思维。断了的思维有时候会延续不上，甚至有时候会让产品实现逻辑上少掉一个关键的分支。不用在产品实现的时候频繁出现刷存在感，当他需要你的时候，他会自己找你。即便你自己发现了产品问题或者bug，如果不是核心的、致命的问题，请先记在一个列表里，集中给他。

友情提醒：下午3点开始到晚上，是程序员思维活跃、工作较为高效的时间段。

有担当，敢担当，不贪功

产品设计/实现出现问题时，担当而不推诿；需要资源支持时，巧取而不豪夺（这里的“豪夺”是指动不动搬上下级关系施压）；在产品有成绩和突破时，表达而不贪功。在协作、磨合过程中，有担当，敢担当，不贪功，善良比聪明更重要。

所有产品经理都绕不过去的一个坎是“老板需求”。什么是老板需求？说白了就是：老板需要一个这样的东西，老板想要这样做。但老板不接触程序员，他接触产品经理。如果你只是老板需求的转发者，而不是产品需求的过滤者、把关者，可能会被视为“无担当”。

老板需求跟用户需求、产品基础需求应该是平等的，也有合理、不合理之分，也有优先级。当产品经理发现老板需求不是太合理时，产品经理要冒着丢掉饭碗的风险与老板据理力争，动之以理，晓之以情。这叫敢担当。这也是对程序员劳动最基本的尊重。

产品经理不是光鲜亮丽的角色，他和程序员一样，也只是团队中的一员，跟大家荣辱与共，同享成败。这样的产品经理，才是一个合格的产品经理，也是程序员们喜欢的产品经理！希望以上的回答对你有所帮助！

记得之前参加团建活动，是真人 CS。

我们一共没几个产品经理，但有几十个程序员。

所以场面估计你也能想象出来了...并不是刺激的对战，而是惨绝人寰的群殴。

被 BB 弹打成狗（哎，原来不就是狗吗）的一个产品经理急中生智，大喊：『我以前也写过代码！我是自己人！』

其他正在施暴的程序员面面相觑，表示十分感动，但仍然拒绝了他的求情，继续按在地上打了半个小时。

...

我在哈工大读书，学的是计算机，写了六年代码，毕业后做的却是产品。

所谓对程序员和产品经理之间的调侃，主要原因无非就在两方经常有矛盾出现，而矛盾出现显然是因为双方一边是需求提供方，一边是需求实现方。

矛盾的类型也简单，就是大家提到的这么几种。

同时写过代码，又做过产品的我，实际上仍然没有很好的通用法则，能解决所有矛盾。

不过做过产品总监一职后，的确理解完全不同了。产品工作和研发工作都是我的管理范畴之内，看事情的角度就完全不一样。

过去做程序员，总觉得提供的需求更改很烦、给的需求不合理很烦、给的截止时间不合理很烦。

做产品经理的时候，也会觉得程序员总是推卸责任、完成得不及时或者不够好。

其实从整体的工作配合上来看，出现问题是难免的，关键是如何预防、如何解决。

...

这是一些切身体会得出的经验性建议：

对于研发人员：

1. 做好更改需求的准备

很多固执的程序员会把改需求当成错事。

改需求？你怎么不早想清楚？
改需求？你知道我工作量多大吗？
改需求？那我不干了。

实际上，在互联网产品这个领域内，改需求肯定会是家常便饭。

我没有做过统计，但我接触到的已经成立一年的公司，几乎都经历过大改版，也就是代码全部重写。这对研发团队来说自然很痛苦，但却是不可避免的。

互联网的需求更替是频繁的，一方面是大环境随时在发生变化，去年你还在刷微博，今年已经是朋友圈了。另一方面，需求获取的渠道也是多样的，产品经理可能会有新的发现和新的判断，未必都是之前没想清楚。

当然，如果需求都是老板从什么《易经》中得到感悟、从云卷云舒花开花落里得到启示，让你手忙脚乱给他改来改去，那也没意思了。

既然改需求是经常会出现的，那就要求还是得做好更改需求的准备。

有这么几种方法：

1.1 提高代码的可复用性、可扩展性等等

让一些产品中很可能会用得到的各种控件、功能模块做成可复用性很强的代码，在产品增加类似功能，或者修改原有类似功能时，将会大有裨益。

可扩展性则是各种接口、数据库以及底层结构不要写死，尽量用可扩展的方式写。比如现在有五个分类，不要写死就五个，要写成 n 个分类，目前是五个。嗯，这是常识了，但有的程序员还是会比较随意，写代码没有远见。

其他的代码特性，如果有利于降低产品的更改和优化成本，也要加深关注。

1.2 根据产品规划来做好充分准备

每个功能的实现方法都有很多，怎么选择并不是只看当下的成本如何，而是要关注未来产品的整体规划。

可能目前要完成功能 A，有 1、2、3 多种方案，方案 1 成本最小。但未来要完成 A、B、C、D 很多功能，方案 3 更有利于整体成本最小。那就要选方案 3 未雨绸缪。

多跟产品团队交流，了解未来产品要做成的样子、哪些功能会是必须的、哪些功能是可能会有的，多从长远来看。

1.3 合理预留出修整的时间

首先，不要把研发时间就当作完成时间。研发功能只是一部分，测试、改 BUG 以及处理意外情况的时间都要预留出来。

有两种情况要多预留出修整的时间。

一种是研发团队自己对功能没有把握，可能是全新的功能，可能是比较难做的功能，可能出现许多 BUG 和功能实现糟糕的情况，那就要多预留出时间。

另一种是产品团队表示对功能也有疑虑，比如在提供需求时表示这个功能很有可能要调整，或者对功能本身信心不足，那也要多留时间做调整。

2. 理解需求，防止返工

研发团队通常会缺少对需求的理解，尤其会出现这种情况的就是外包团队。

我听说过太多花了几十万请外包团队，最后开发的结果特别不满意，不能拿来用。合同又已经签好，还得给钱，就是赔了夫人又折兵。

有的技术团队和产品团队都坐在同一间办公室了，居然都经常缺乏沟通。技术团队不知道当前做的功能是给谁做的、是提供什么功能、满足用户什么价值的。

这些不是很高深的理论，也不需要深入学习，只需要通过产品经理做些了解，就能少挖一些坑，也就不会轻易返工。

比如，有的产品页面可以是提前加载缓存，也可以是每次都刷新，但要看用户平常是在 WiFi 环境下用还是在移动数据下用，这是产品经理清楚的。产品经理在功能细节上不会想到实现层面这么具体，所以就需要研发团队去理解刚才说的需求，做一些判断。

另外，如果是在开发之前就意识到做出来的功能会跟产品经理想象的不同，那就必须及时提出来，千万不要等开发完成，大家都觉得不靠谱，再重做，那样不管对谁来说成本都太大了。

3. 善于用数据、理论以及通俗的解释来进行沟通

程序员最应忌讳的就是说『这个做不了，说了你也不懂』、『这个太难，懒得跟你解释』。产品经理听完肯定会觉得是推卸责任。

正确的方式是：用通俗易懂的客观事实来解释。

嗯，这个弹窗做不了。

为什么现在做不了？是因为代码实现可能要花三个月。

为什么这么久？是因为需要调用底层驱动层面的东西。

为什么要调用底层驱动的东西？是因为安卓系统原本的框架和协议就是这么定的。

如果想看协议，我可以给你找出来。

这样一步一步往下解释，把所有理由说明白，别没有耐心，只要产品经理是讲理的，他会理解你。

他听懂了你的解释，也会有利于他找出另外可接受的一种解决方案。

哦，我懂了，这个用弹窗形式太复杂。

那我们换作跳转到普通页面吧。

这样问题就解决了。

对于产品：

产品经理要在不断的迭代和更改需求的风险中被程序员认可乃至尊重，我觉得最重要的还是『讲道理』。

切忌说出『我不管，反正得做完』或者『老板就这么定的，我也没办法』这样的操蛋话。

1. 对产品功能有规划，并提供给研发

对自己的产品都没有大致规划，是产品经理的大忌，也是出现问题的主要原因。

• 一年后产品成熟了要给用户解决怎样的问题？
• 未来半年内产品要做成什么样子？
• 三个月内产品应该主要提供哪些功能？
• 这一个月的产品具体方案是做哪些？

这些都要认真去考虑并且规划。

当然，长远的产品规划在很多情况下（市场变化、团队更替、产品转向）确实用途不大，但越短期的规划，对研发团队越有帮助。

正常来说，预估三个月内产品的功能还是完全可以的，除非老板和产品经理都没想明白产品到底该做成什么。

把这些规划想明白，并传达给研发团队，让他们在现在的代码里就给未来的功能留下空间，是最好的避免代码重写的方法。

2. 提供需求要足够具体

这要求产品经理做到两点：

第一，让产品需求文档特别特别具体。

具体并不是说，要按照大公司的 PRD 去完成。而是说，不要缺东西。

对于需求文档来说，页面逻辑、页面布局、功能逻辑和每个功能的使用细节，都要存在。并不只是画个交互图就叫需求文档了。

你给了研发 5 个页面，结果研发做着做着，来问你，好像缺了个页面。你补完一个，研发做了一会儿发现又缺了一个...最后七零八碎的 10 个页面拼凑出来，发现根本不好用，所以又推倒重来。

如果研发经常来问你某个地方该怎么做时，你就要反思是不是需求文档写得不够好了。

第二，要说明每个需求背后的原因。

这个在上面表达过，程序员明白了需求背后的原因，会选择更合理的方案去完成。

千万别提『你别管为什么了』，而是不管他问不问这个功能为什么要做成这样，都要告诉他为什么。

3. 熟悉基本的研发背景和研发能力

『产品经理到底需不需要懂技术』是我被问到的关于产品经理的问题中的 TOP 5。

这个问题我的回答是：要按照需求，了解基础知识，并不需要知道实现细节。

了解基础知识、不需要知道细节是指产品经理应当知道最基本的一些理论。

比如做安卓操作系统，要知道安卓原生提供了哪些控件，这样在设计方案时可以尽量使用它们。在代码实现时，调用一个控件可能只需要几行代码，但自己重写一个功能界面，可能就是成千上万的代码量了。

比如是在手机网页上的产品，要知道哪些交互是在 H5 上较容易实现的，而哪些交互是实现效果非常糟糕的。如果依照在 iOS 上的动画效果来要求 H5，开发成本可能会是指数级上升的。

按需，是说对于产品经理，千万不要买《iOS 入门指南》、《安卓开发手册》或者《H5 设计实例》来学习，除了装点下书架不会有别的意义。

因为本身开发的指南和手册，讲述的全是实现细节，对你清楚安卓的基本控件或者 H5 的常用交互完全没有帮助；同时，不同的产品有不同的特性，也有不同的代码特点，你只需要了解你负责产品的技术背景即可，有的同学居然决定从 C 语言先开始看，简直是让人扼腕。