Gevin 会把产品经理分为两类：

●A：改变世界的海贼

●B：自给自足的农夫

产品经理在开始做事之前，需要明确自己是 A 类还是 B 类，与程序猿沟通时，通过语言或者行动表明自己的定位。如果你是 A 类，优秀的程序猿会成为你强大的助手，如果你是 B 类，好的程序猿也会帮你衣钵满载。但如果你有 A 类的心，却做 B 类的事，不被骂白痴才怪;如果你按 B 类的要求与程序猿沟通，却心怀 A 类的雄心，高傲的程序猿会认为你在玩弄他。

A 类的产品经理，对技术的要求高，能力覆盖范围广，程序猿对 B 类产品经理的要求，只是 A 类的一个子集。下面提到的产品经理，如无特别说明，是指 A 类。

程序猿也知道产品经理是要与多种职责的人打交道的，要有较强的综合能力，不会在技术领域拿自己的强项和产品经理过不去，但他们同时认为一个优秀的产品经理要具备一些能力，能力不足的产品经理不会被程序猿尊敬。这些能力包括：

●对技术的理解

●美学的修养

●强大的学习能力

●无限热情

对技术的理解

产品经理不懂技术当然不行，但产品经理也没必要掌握技术细节。产品的技术实现是由程序猿完成的，产品经理只要做到理解程序猿，尽量和程序猿做“无损沟通”即可。

非技术出身的产品经理是比较辛苦的，因为你要在技术上下不少功夫。技术不简单，种类多，各有特色，发展日新月异，是产品经理和程序猿要时刻关注的主题。即便是对技术做整体的宏观的把握，也不是一个不懂技术的人一时半会就能融会贯通的。非技术出身的产品经理首先要迈过技术上的一道坎，让不懂技术的人看来，你是一个技术领域的内行。技术出身的产品经理，对技术的理解自然不是问题，但在和程序猿沟通时，会不自觉疏忽的是，容易过分纠结于细节，尤其是曾经在技术领域有不菲造诣的产品经理。产品经理不是对产品做技术实现的人，技术更新那么快，技术细节本身甚至技术实现的理念，会迅速更新迭代，产品经理和程序猿死磕技术细节得不偿失。

上文提到的“无损沟通”，是指产品经理和程序猿在沟通中彼此完全理解，不存在疏漏和误解。这是不可能的，但这必须是二者沟通的目标。

产品经理和程序猿沟通时，两个方面尤其重要：

●A：对需求的沟通

●B：对技术实现的沟通

对需求的沟通主要应用于产品经理向程序猿阐述需求的场景中。程序猿实现产品功能，是基于对需求的理解;在功能实现过程中和实现完成后，需求的变化又可能带来产品实现上的灾难。如果程序猿不能准确理解产品经理对需求的描述，很可能实现的功能与产品经理的想法大相径庭，浪费大家的时间;如果产品经理想法不够明确，导致需求变来变去，无疑是对程序猿的恶意攻击。需求上任意一个小小的变化，在代码实现中的都有可能产生巨大麻烦，甚至会动摇代码的整体架构。从程序猿的角度来说，虽然程序猿在技术实现时以构建稳定的系统为目标，尽量灵活应对需求的变化，让系统易于扩展和维护，但这也是要基于程序猿们对需求的理解，以及对潜在的需求变化的预测。如果在沟通过程中做不到让程序猿准确把握需求，那就不用考虑产品实现的满意度了。

对技术实现的沟通主要应用于程序猿向产品经理沟通的场景中。如果产品经理对技术理解不够，程序猿很难向产品经理讲明白自己的工作现状，当产品经理想要改变需求或者希望为产品添加新的特性时，也无法准确理解程序猿对此产生的各种反应。

只有依靠足够技术基础，产品经理才能理解程序猿对工作和任务的描述，把握技术实现的难度，制定更加合适的计划。至于多少技术才算“足够”，需要产品经理和程序猿慢慢中磨合了。

最后，请相信程序猿，请在技术上放手!

美学修养

为什么程序猿可能会关注这一点?虽然程序猿不会像设计师那样与产品经理讨论产品的设计和交互等问题，但也会关注下用户体验的，而且优秀的程序猿也是艺术家，没准还是个真实的画家，要想赢得程序猿的尊敬，美学修养低于程序猿说不过去吧?

学习能力

产品经理和程序猿，是互联网上最需要频繁接受并掌握新知识的人。新知识新概念接受的慢，谁放心把产品交给这样的产品经理?何况产品经理要与聪明的程序猿们交流沟通，学习能力差的产品经理在沟通过程中会遇到各种困难，各种无法理解，在工作过程中也无法应该程序猿的尊敬。

无限热情

这是产品经理最重要的素质，也是程序猿最需要从产品经理身上获取的元素。产品经理是最热爱自己产品的人，如果产品经理不能把自己的热情传递出去，程序猿也不会实心实意做产品的实现，实现一个没有激情的产品经理的想法，实在不是一件很 cool 的事情!

小结

产品经理若要和程序猿默契配合，最重要的是要赢得程序猿们的尊敬。产品经理并不是懂的技术越细越好，而是要在宏观上对技术有总体上的把握，在微观上懂得放手，相信程序猿，并锻炼好自己其他几项能力。

来源：UXDC