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