B 端软件：开发转产品经理可能遇到的坑

有一类产品经理是由开发工程师转岗而来。就拿我来说，自从管理产品团队后，经常会和团队的产品经理进行新功能的讨论、会考虑产品未来的发展方向和路径，慢慢的我的工作重心也更多的偏向产品设计。

本文就聊聊从开发工程师转变为产品经理可能会遇到的问题。

思维转变

开发工程师大多是工程思维。

产品经理需要的是产品思维。

前些天，在团队内部的一个需求讨论会上，产品经理和开发工程师都有参与，我提出一个需求的 UI 交互思路，开发工程师马上指出：“如果这样做的话，实现上某某地方会调整比较大；某某地方新增的部分实现比较复杂。”

这就是典型的思考方式没有在一个维度上，从产品的角度，需要考虑的是功能交互的合理性、怎样才能真正解决用户的痛点。在这个前提之下，再考虑应该怎么实现，该怎样去做取舍。

工程思维更关注效率、如何实现，也就是「How」；而产品思维更关注场景、用户的真实需求，也就是「Why」。在具体的产品开发中，产品思维和工程思维都很重要，需要将两者结合起来。

产品思维需要工程的配合与支撑，但如果只有工程思维，最后可能会做出一堆无用的功能。

不要以为自己的开发经验就是优势，而忽视了产品经理所需要的其他知识和技能。应该将你具备的开发技能变成加分项，而不要变成束缚。

除了我们熟悉的开发技能，还需要补齐产品经理的基础知识，如市场分析、需求分析、用户研究、产品设计、项目管理等，并且不断学习和实践。

对开发工程师来说，沟通能力也很重要，只不过平时的工作只需要按照要求高质量编写代码就行，不会刻意在这个方面去做提升。

产品经理就不一样，对内要和开发团队进行沟通，对外要和需求方进行沟通，沟通能力是一个必备技能。

在公司中，不同职位与不同资历的人，彼此的认知都不同，作为产品经理，需要团结团队里的每一个人，让大家朝着同一个目标努力。

产品经理需要跟所有人解释，某件事的重要性，某个功能为什么存在，某件事为什么要那么做等等。而且，因为认知的差别，你与每个人的沟通方式也要有差别，找到合适的沟通方式才能获得对方支持。

客户往往在提需求的时候还会赠送一个解决方案，会告诉你怎么做，而没有说为什么要这么做。开发工程师擅长的就是按照一个实现方案将功能实现。

当转为产品经理后，就不能被客户牵着鼻子走，需要去挖掘客户背后的真实需求，之前看《有效需求分析》时有个例子现在还记忆深刻：

晚上小孩吵着说要吃饼干，最后给了点面包，小孩吃完就乖乖睡着了，在这里吃饼干是方案，需求是小孩的肚子饿了，当没有饼干时，可以使用第二种方案，给他吃面包也可以解决这个需求问题。

搞懂了小孩的真实需求是肚子饿，而不是吃饼干或面包，事情就好办多。所以，只有了解了真实背景，挖掘了客户背后的诉求，才能设计出能够解决客户痛点的产品功能。

程序员就是一个需要持续学习的职业，不过当工作需要的技能非常熟练后，往往就疏于学习了。当转产品经理后更是需要有持续学习的能力。

如果做的是平台型产品，功能不断迭代，需要将不同类型的客户需求收集、分析、转化为平台功能，客户的类型在变化、客户的使用习惯也可能变化，不学习难以应对这种变化。

如果做的是业务型产品，你需要快速熟悉和了解一个行业，才能和客户、业务专家平等对话，在《麦肯锡方法》中介绍快速了解一个行业可以按下面三个步骤：

1、总结行业的 100 个关键词；

2、找三五个专家访谈，了解各种行业问题；

3、找三五本行业专业书籍，仔细阅读并找出共性。

上面的三个步骤就是学习的过程。

很多时候，开发工程师把一个功能的代码写完，提交测试了，可能还不清楚这个功能具体是做什么用的。这是因为看到的是点而不是面。

当转为产品经理后，就需要有全局的思维，从宏观上来思考问题，以满足实际业务场景为目的，然后再逐步分解到具体的功能点。如果还是像做开发时那样，产品会变成一堆零碎功能的堆砌，看似很强大，实则是四不像。

从开发工程师到产品经理，是一个比较大的跨越，首先需要提高认知维度，知道产品经理和开发工程师的不同，然后再转变思维模式，思维模式变了，最终做事的方式方法自然就会发生变化。