聊聊工程师和产品经理的角色异同

点此收听本文音频版

AI配音由出门问问「魔音工坊」提供技术支持。

本文音频没有经过任何编辑处理，为全自动生成，可能存在部分播报错误。

之前技艺丛谈公众号发过一篇文章《产品经理眼中凶猛的程序猿长什么样？》，谈及产品经理经理眼中比较优秀的程序员是怎么样的。那篇文章是一个朋友写的，今天我也就两个角色聊聊自己近年来的一些感悟。

先说说我自己。我实习到毕业，基本上角色都是工程师，不过有几段时间，其实一定程度承担了产品经理的角色。

第一次经历是，在我实习的时候，我带了一个小团队，开发类似QQ的一款聊天工具。为了开发大部分QQ的功能，我深入研究了QQ的各个主要功能，包括文本聊天，视频聊天，语音聊天，换皮肤，表情发送，文件传输等，基本上把QQ各个功能都摸了个遍，然后琢磨它的优点在哪里，我们怎么学习。这次基本停留在学习阶段（说难听点，就是抄袭），没什么创新。

第二次经历是，在上一家公司，我设计开发了一个视频搜索，当时迅雷和各种网盘的云播正方兴未艾，不过种子的搜索并不方便。从视频消费的角度，一来我们需要能够打破app时代的资源隔离，希望有一款视频搜索工具，能够快速找到版权视频，不管是腾讯视频，还是爱奇艺，还是优酷或者土豆，或者搜狐视频等有这个资源。另一方面，如果这几家都没有资源（比如一些美剧），那是否能够搜索到种子文件或者magnet链接，能够快速在云播平台直接播放，就有很强的需求了。这个产品做了一个来月，国家对视频网站和网盘的审核严格了，也就中途放弃了。不过视频搜索这个产品，基本上从产品创意，到实现的大部分工作，都是我在推进的。算是我第一次比较主动地琢磨用户需求、产品形态以及技术手段等。

来目前这家公司后，相对比较专注技术，很少主动去想产品创意。不过日常工作中，还是保持偶尔体验下喜欢的产品的习惯，比如微信、微信读书、豆瓣等。此外，语音助手的一些竞品，AI相关的产品，也有较高的关注度。最近一年到半年的时间，花了一些精力阅读产品相关的文章和书籍，算是对产品有了更深的理解。阅读了不少书籍，包括俞军的《产品方法论》，不过我对俞军的书评价一般。读过的书籍和文章里，《设计心理学》四卷，以及张小龙的几次演讲，让我比较受益。

最近半年来，花了一定的精力刻意练习产品思维，包括去思考AI讨论能做什么，能给哪些场景带来效率的提升，能解决哪些之前的工具无法解决的问题。也花了不少时间，和产品经理讨论需求，讨论产品设计细节，和设计师沟通某个细节的好坏。此外，也使用工程师的思维，去量化每个交互的时间代理，和心理惯性代价等。最近也比较深度地参与了一个AI配音平台的设计，虽然没有直接输出PRD，不过也实实在在输出了很多产品的想法，细节的改进建议等。在个人角色上，我自己已经打上了半个产品经理的标签了。

下面我想来聊一下，作为工程师，我喜欢什么样的产品经理。而站在产品经理视角，我又欣赏什么样的工程师。

作为工程师，我讨厌抄袭成性的产品经理。直接抄袭，工程师觉得没劲。作为工程师，也很烦自己从事的是复制粘贴的工作。往往工程师做一个方向久了，就会腻味，想转岗。可想而知，去抄袭一款产品，而没有任何创新，工程师会觉得很low。

作为工程师，我喜欢有创意的产品细节，很讨厌不讲究细节的产品经理。没有经理的产品经理，一问起来，这样也许，那样也可以，仿佛几个不同的实现都无关紧要，或者对用户而言都没什么差异一般。

作为工程师，我讨厌没有极致追求的产品经理。有一些产品经理，提了某个需求，本身挺亮眼的，但是工程师反馈说，这个做不了，平台有限制，开发难度大，时间赶不及，产品经理马上认怂了，改需求，做出各种让步。这样的产品经理挺糟糕的。我喜欢执拗的产品经理。当然，偏执的产品经理会让团队抓狂，但是好的产品，突破当前竞品产品体验的新产品，往往是逼出来的。产品审美上的提升，产品细节上的精益求精，是不断逼迫自己逼迫团队的结果，这个和作家写作类似，作家写作也经常逼迫自己，没有「两句三年得 一吟双泪流 」，「批阅十载，增删五次」，哪里来的「增之一分则太长，减之一分则太短」。

作为工程师，我讨厌对技术不懂装懂的产品经理。如果一个产品经理对技术不懂，往往会对产品需求的实现难度不易判断。这时候，如果团队里的技术能力一般，往往会收到负反馈，久而久之，他就会被训练成对技术越来越没追求的产品经理，也就是说，很多产品功能其实是可以做到的，但是在技术的「负反馈」下，产品经理收获了很多错误的知识，从而判断越来越失误。作为产品经理，一方面可以阅读一些技术文章，了解下技术的边界，另一方面，也应该找找竞品，看看竞品在细节上是否做到了很多自己的产品做不到的功能，如果是，琢磨下为什么自己的产品做不到？而不懂装懂的产品呢，看到一个产品做到了某个功能，就自然而然觉得，我们也可以很轻松做到类似的其他功能，但是技术深究下来，两个功能其实是似是而非。

作为技术，我经常被产品经理拉去讨论某个技术方案。有时候我在听到技术的解释后，会觉得确实技术说得有道理，实现有难度。在技术复杂度面前，产品需求又比较着急，我有时候会建议产品经理设计个折衷方案，从而在规定的时间内先上线某个改进版本。有时候一些产品经理会非常偏执，觉得实现应该不难，为什么一定要在产品细节上让步。有好几次，在产品经理的坚持下，我突然灵光一现，想到了其他的解决方案，能够得到产品经理的需求。这时候我会很感谢产品经理没有提前让步。很多时候，我作为技术总监，普通产品经理是非常容易接受「现实」的，早早让步，要不放弃该功能，要不按照技术的反馈，设计一个妥协的交互方案。

作为技术，比较喜欢懂技术的产品。对技术越懂，越容易和技术进行需求沟通。懂技术意味着知道技术的边界，更容易评估复杂度。对复杂度有足够的认知，往往也更知道产品需求的优先级，因为资源往往是非常有限的。不过好的产品经理应该保持和技术的沟通，否则往往很容易因为之前获得的「技术边界」而局限住自己的思维，尤其是限制了产品想象力。「贫穷限制了想象力」其实挺有道理的。如果你呆的团队，技术能力比较弱，产品往往多次受挫以后，会畏首畏尾，设计的方案不够先锋大胆，创新力缺乏。好的产品应该学乔布斯，追求每一个像素的完美，追求内外兼修。当然，创业和做产品都是有限资源下的博弈游戏，所以产品经理更应该不断提高对优先级的判断。

作为技术，讨厌没有自己见解的产品经理。老板让做什么需求，Leader让做什么需求，这些都是非常糟糕的需求理由。身边不少产品经理，其实做的是项目经理的活儿，或者是PRD工人的活儿。想法都是别人的，他只是负责转换为PRD，然后和工程师沟通，让别人的想法变成现实。

作为技术，厌烦只知道做加法的产品经理。好的技术，最怕的就是代码冗余。工程师习惯性地会去做代码重构，让自己负责的项目比较容易掌控，容易维护。而只做加法的产品，随着需求的增加，代码会越来越多，但是没人用的需求，对应的代码工程师却没有机会删除掉。没有价值的产品越来越多，需要维护的「垃圾」代码也会越来越多，产品可以不维护了，代码却不能删除掉，出了点事情，工程师就成了首席「铲屎官」了。

那么作为产品，希望和哪种技术共事呢？随便列举一些，大概有：

1，对技术精益求精的人。不断优化代码，性能越来越快，体验越来越顺畅。

2，保持对技术的产品价值思考的人。如果技术碰到一些新的技术突破，可以及时和产品经理沟通，一起讨论下新技术是否能够带来一些新的产品价值。

3，能够对产品需求提出质疑的人。产品经理往往单打独斗，相比工程师一般人数比较少，并且产品经理往往独立负责一个产品线，因此产品经理之间review对方的产品就很少见。这就会导致产品经理个人的盲点必然会存在，考虑不周的地方，如果技术在评审产品需求的时候，能够勇于发问，往往产品经理就会及时完善产品细节。否则，在测试环节，在未来的使用中才发现一些细节处理不够完善，一些需求考虑不周，往往会造成不必要的反攻，或者方案设计不够到位，反而迭代。工程师之间，往往会有code review的环节，但是产品经理之间，很少看到PRD review的环节。一方面产品经理可以借鉴工程师的code review文化，另一方面，产品经理和工程师之间，也可以加强产品技术沟通，让review发生在产品经理和工程师这两个角色之间。

4，能够提出对极端条件下的产品细节定义的人。产品经理往往关注的是高频需求，而产品功能设计的时候，往往也关注的是正常交互的产品体验流畅度，对极端情况的处理，往往工程师比较有经验。工程师们在刷题训练中（比如刷LeetCode），已经练就了多极端情况的处理，软件工程里，也有测试驱动开发的文化。因此这方面工程师往往比产品经理更为严谨，这时候和产品经理相互补足，对产品经理就有好处了。

5，遇到做不到的时候，能够问问其他人，或者是搜索下互联网，搞清楚到底能不能做到。产品经理不喜欢没做足够的调研，就轻易下结论「做不到」的工程师。

总体而言，工程师喜欢产品经理异想天开，灵感迸发，给自己的技术带来一个个好玩的用户体验。而产品经理喜欢工程师精益求精，不断突破技术限制，从而不断突破产品体验的天花板。

最后聊点自己最近几个月以技术视角怎么去练习产品能力。之前曾经发过一条朋友圈，总结了工程师做产品的一些切入视角，敝帚自珍，发在这里：

最近刻意练习产品能力，并和计算机性能优化做类比，比如

1，基础的硬件能力（体系结构，指令集）对应基础的交互能力（安卓，浏览器等系统和控件集）

2，必要的benchmark工具。类似性能优化的perf,google perftools，做必要的指标埋点和监控。

3，量化评估各个环节的心理代价和用户学习代价等（类似各函数的计算量），逐步优化。

4，注重架构，应对复杂。架构不好，不容易增删改查，牵一发动全身，也不方便diff（abtest）

5，学习事后看反馈信息从而迭代的能力，类似跑benchmark和profiling，重新评估改进方向。

6，学习事前模拟，预期各种方案的好坏，（类似Jeff Dean的信封背面性能评估法）在不发布影响用户的情况下，就根据基本指令和操作类型的时间代价，预估执行的总成本。

确实，作为工程师，如何不断改进计算机程序的性能，是有法可依的。比如，尽可能去熟悉计算机的基础能力，比如计算机体系架构，指令集，操作系统，编辑器和C++ 基础库等。再比如，掌控足够量化的当前性能指标，找到热点。接着，抓重点进行优化。优化的时候，准备好基本的benchmark工具，做好AB测试，某个改动对性能带来多少影响，最好能量化。找到热点后，按照受益和改进的难易程度，有序优化。优化的方法呢，除了充分发挥算法的威力（找到复杂度最低的算法），还应该充分利用计算机的提供的算力（找到该算法在该硬件平台上的最佳实现）。

那么，作为产品经理，也可以平行地找到一些类似的方法论。比如，尽可能去了解计算机（PC和移动设备都是计算机）提供的计算能力和交互元素，比如有哪些控件，他们提供了哪些属性和事件等。操作系统的改进，浏览器的改进，HTML语言的改进，开发框架的改进，给交互世界带来了什么新的玩法？新的计算平台，比如新的旗舰机型的计算能力，耳机芯片等，给产品交互带来了什么新的计算基础？不同的产品设计方案，给用户带来的体验价值，到底怎么量化？在没有发布产品，收集用户反馈的情况下，怎么去模拟可能的用户接受度？迭代产品功能的时候，如果找到量化的评估方法，来论证自己的产品判断？几种可能的产品路径或者决策，到底用户的喜爱程度怎么样？类似技术判断的直觉一样，产品直觉如何培养？

上面聊了很多话题，不过自己对产品的思考和体悟还不够多，难免浮于表面。后续再找时机展开聊聊。