共计 3377 个字符，预计需要花费 9 分钟才能阅读完成。
分享前，我先自我介绍一下，我从事 Java 开发的全栈工程师 5 年，也是一名连续创业者，之前做过科技媒体、做过智能音箱，做过很多事，踩过许多坑。今天想跟你分享的话题是“工程师转型产品经理可能会遇到的几个坑”。
之所以称之为“坑”，而不是“问题”，是因为我自己并没有真正做过工程师，而是接触过很多工程师，也有很多工程师转型产品经理的朋友，我将所有的问题与经验总结起来，并分享给你，希望对你有用。
工程思维与产品思维
首先以手机摄像头为例，来说说工程思维与产品思维的差异。假设我们要做一款手机摄像头，从工程思维的角度，我们可能会考虑，如何提高摄像头的分辨率；如何提高弱光下的快门速度；如何进行 ISO 调整；如何优化人像识别功能；如何使闪光灯更智能等等。
从产品思维的角度，我们可能会更多的考虑拍照场景、美颜效果，比如如何拍出来就显五官立体、肤色嫩白；如何做到自动美颜并可以立即分享朋友圈；如何从众多照片中自动选取最美的一张等等。
我与很多工程师朋友的理解是：工程思维更关注效率和如何实现，也就是“How”；而产品思维更关注“场景”以及用户的内心需求，也就是“Why”。
在具体的产品开发中，产品思维和工程思维都很重要，需要将两者结合起来，产品思维需要工程的配合与支撑，将“场景”落实到产品开发。比如，产品经理想做一款夜间拍摄效果更好的手机摄像头，那么就要做到既保证人像清晰，又保证背景明亮，这时就需要工程师们在技术上做相应的提升和优化，比如前景快门锁定、快门拉长等。
工程师转型产品经理可能遇到哪些坑？
在这次分享前，我跟几位从工程师转型做产品经理的朋友聊了聊，从中摘取了四条较为典型的吐槽。
视角变了，原先追求完美和逻辑性，现在是怎么快速实现目标怎么来；
很多时候，用户视角的简单性与工程思维的完美性有冲突；
转型这一年，踩过的坑无数，包括产品战略层面、沟通层面、团队管理层面、执行层面；
以前不用做这些，现在要做很多公司内部的东西，比如对上沟通，然而老板永远不懂我；对下沟通，光打鸡血远远不够；还有跟兄弟团队和部门之间因为资源不足产生的博弈等。
对此，我稍稍总结了一下，总结出了工程师转型产品经理时，可能会踩进去的 7 个坑。
除了这些，针对当前互联网公司的技术需求以及结合主流技术，我自己整理了一套系统的架构技术体系，当你技术过硬的时候，能够解决技术问题才会服众。不少公司都很重视高并发高可用的技术，特别是一线互联网公司，分布式、JVM、spring 源码分析、微服务等知识点已是面试的必考题，这些东西可能你们平时在工作中接触过，但是缺少的全面系统的学习，加入后端开发群：943918498，或是关注微信公众号：Java 资讯库，回复“架构”，免费领取架构资料。
1、认为用户傻
“我明明设计了一个很聪明的按钮，用户就是不用, 非要用那个复杂的方法来使用我的产品。”
举个例子，假设产品经理设计了一个开关，用户只需向上一推就可以把灯打开，比原来向下按的方式更省时省力，结果发现用户并不买账。可能 99% 的用户还是用向下按的方式去开灯，尽管这样会稍微费力一点，但用户已经习惯了这样的行为方式。
对于这类情况，很多产品经理容易陷入一个误区：既然有更加方便的产品使用方式，用户就该放弃原有的方式，去使用新方式。但是，他们忽略了用户习惯较难改变的事实。
2、觉得同事傻
“那帮运营和市场老给我提不靠谱的需求, 一点都不懂技术和产品，瞎指挥。”
这是我曾经陷入的误区之一，以前我在一家公司做客户端，很多时候，市场和销售的人在与客户聊天之后，就会找我提需求，比如在某个位置加个广告位。在当时的我看来，这完全是他们在瞎指挥。
后来，我反思当时的做法，认为应该从两方面思考这件事。第一个方面，当同事提需求时，这个需求可能已经变质，不再是客户的原始需求了。作为产品经理，应该去了解客户最原始的需求。
第二个方面，应该考虑同事提出这个需求想达成的目的，比如他的目的可能并不是为了加一个广告位，而是为了借此达成盈利目标，那我们其实可以通过其他方式帮助他实现目标。
因此，当同事提需求时，我们应该把他和普通用户放在同一层面，尽管提的是一些所谓的“傻”需求，我们也要花费时间与精力去认真分析这些“傻”需求背后的动因，以及如何才能帮助他们解决问题、实现需求。
3、觉得同事还是傻
“明明那么简单的道理和逻辑, 这帮同事怎么就不理解呢?”
这个问题其实出在沟通层面，然而，产品经理很重要的职责是沟通, 很多时候, 沟通是做成一件事的关键。
之前有个产品经理跟我分享，他做工程师时不擅长沟通，也不想沟通。在他看来，这些事情都很简单，为什么还要花时间给别人解释，这是他后来转型做产品经理时很难跨过的一道鸿沟。
在公司中，不同职位与不同资历的人，彼此的认知都不同，而作为产品经理，需要团结团队里的每一个人，让大家朝着同一个目标努力。那么，你就必须跟所有人解释，某件事的重要性，某个功能为什么存在，某件事为什么要那么做等等。而且，因为认知的差别，你与每个人的沟通方式也要有差别，找到合适的沟通方式才能获得对方支持。
可以说，提升沟通能力是工程师转型产品经理的必经之路。
4、容易在前端呈现过多技术
“我给用户做了一个特别炫酷的功能, 用户可以自定义各种参数，但似乎他们并不怎么用。”
其实，许多做产品的书籍、课程都会写到，不给用户选择，反而是最好的选择。举个例子，前段时间小程序黑咔相机特别火，日活量最高时可达千万。它的功能特别简单，就是给照片中天空提供各种动态效果，比如用户选择梵高星空，它就能将图片中的天空变幻为动态的梵高星空效果，然后一键保存、分享，操作非常简单，过程中没有任何需要技术的地方存在。
这个产品的用户平均年龄大概 50 岁，最早在某个摄影群中爆发，由于操作简单，效果有趣，迅速被群成员分享，一天时间内由日活 30 多万，迅速上涨至几百万，第二天再增长至一千万，是一个特别经典的例子。
5、过于追求完美，害怕返工
“用这个方法来实现产品方案太笨了，对服务器的开销太大，我们应该重写代码，用另一种方案。为了应对未来可能存在的需求改动，我要把能在后端定制的功能都写了 API，并且把功能拆成各种层级。”
许多创业公司在开发产品前会将计划思考周到，以防未来可能出现的需求改动，比如将各种 API 补全、把框架都搭好等等。但在实际开发过程中，我们还需考虑阶段性问题，如产品当前处在什么阶段，是否应该在当前寻求最完美的实现方案；如果处在 MVP 阶段，是否应该允许回炉重做等等。
我们应该允许一些不影响主功能的 Bug 存在，先让功能运行，再补全不完美的地方。有许多工程师害怕返工，觉得按照产品经理的需求去做时，会不断出现新的需求，就需要不断地返工进行完善。然而对产品经理来讲，他需要根据每个阶段的数据变动，去观察市场反馈，从而迅速做出调整。所以，我们应该放下害怕返工的心态，接受随时推翻重做的可能性。
6、认为功能大于场景
“我们有 A 功能、有 B 功能、有 C 功能……我们有非常多的功能，都是我们自己的技术实现的。”
产品经理经常犯一个错，就是总觉得应该再多开发一些功能给用户使用，让他们的体验更丰富。然而，我研究了许多小程序的方法论，发现小程序之所以火爆，除了自身裂变属性较强外，非常重要的一点是，它只满足用户一个功能的需求。你可以看到，很多拥有多合一功能的小程序，很难火起来，因为功能增多之后，会模糊用户对这个小程序的认知。
7、忽视运营
“酒香不怕巷子深, 好的产品, 用户自然回来, 首先要做好的是产品, 运营和营销并不重要。”
其实不然，产品与运营始终不可分割，产品经理一定要与运营人员密切沟通，甚至做到产品经理即运营本身。
最近几年，很多成功的产品，其成功的原因中运营占得比重甚至大过了产品本身。以小程序为例，很多小程序的功能比较容易实现，技术门槛并不高，别人也可以快速复制，关键点反而在于如何做用户增长。
对此，我们的做法是采用 AB 测试，反复测试，总结结果，在这个过程中，产品经理需要跟运营不断沟通，共同摸索出最优结果。
并且很多时候，产品经理还需要身兼多重角色，我有一位朋友是做电商产品经理，他每天除了做 AB 测试，测试各种按纽，优化各种流程之外，还会涉及对文案细节的改动，某次他改动了一句广告语，结果下单率提高了 9%。
可以看出，产品经理做测试、运营、文案等细节工作，看似与技术没有太大关系，却是产品获得成功必不可少的一部分。