为什么产品经理和技术总是吵架——产品思维和技术思维的真正分歧点

网上有很多诸如产品和技术是天敌，产品被技术打断腿的段子。外界对产品技术争执原因的猜想通常是产品不了解技术可实现范围，提出了不可实现的夸张设想却一意孤行。其实这个情况，至少在我的工作中，几乎是没有出现，甚至我一直在给程序员“减负”——我是个喜欢砍需求做减法的产品经理。那么产品和技术真正的分歧点是什么呢？工作这么多年和程序员打交道，我最近才逐渐理解产品思维和技术思维真正的差异。

1、每个人的想法不同是普遍存在的现象，不止存在于产品和技术之间

首先，这世界上每个人的成长环境、工作经历、教育背景，塑造了每个个体独特的思考风格，讨论一个问题有观点碰撞是普遍存在的事情，不止出现在产品经理和程序员之间。但正是这样的观点碰撞，让产品能够接受不同人的意见，把产品做得更加完善。希望所有人在讨论问题时牢记在心——对方提出相反意见，请不要马上评价，请先了解对方方案背后逻辑。方案只是表面，逻辑才是实质，在了解对方真正想要表达的东西之前，贸然反驳不是最佳沟通方式哟。

2、产品的起点是用户，而技术的起点是功能

产品的工作根基是围绕用户，工作中很大精力投入到用户调研上，所有需求都以用户为出发点，所有的功能设计都考虑用户场景，有时候会为了更好地满足用户需求，会做出设计创新，也就是——违背很多人第一直觉的设计。比如我最近参与的音乐人平台产品，我建议发布作品只做Web端不做APP端，而开发的第一反应是APP为什么缺这么重要的功能，为这件事我做了很多说服工作。其实我的考虑就是用户场景里，音乐作品都是电脑做完电脑储存，即使APP支持上传，也要先打开电脑，在一系列操作之后把文件存在手机文件夹（作为ios用户我甚至不会这个操作），然后再用APP操作，这样一个流程下来不知道比Web上传繁琐多少——反正都是要开电脑的，直接提示去电脑上传不香吗？

还有一点，我认为基于用户场景的方案设计，不一定是要开发一个什么功能，而是解决用户的某个需求，解决方式不一定是通过技术方案。有些技术人员还蛮有意思的，他们选择解决一个问题的方案，往往倾向于用写代码的方式，比如我用同样一个问题，我用excel公式解决，技术人员就会选择写脚本来解决。这是我发现的产品和技术思维上的一个差异点，产品经理是从用户需求出发，为用户需求寻找一个解决方案，不局限于技术手段的解决方案。程序员和用户直接接触少于产品经理，出发点直接从功能层面开始了，并且选择解决方案时更倾向技术手段。

其实双方都有各自的优劣势，产品的优势是走在比开发更前一部，不止看到功能，而是功能前面的用户；技术的优势是知道技术能做到什么，他们知道满足某个需求，不一定非得用户操作什么，而是可以用黑科技代替用户操作。

3、产品经理关注“用”，而技术还是关注功能

其实这一条跟上一条有些类似，上一条讲的是产品工作起点比技术更靠前，提前到了用户那儿。这一条其实就是另一面：产品工作收尾也比技术更靠后，推迟到了功能完成之后到产品运营阶段。当然这一条并不算是分歧点，只是我观察到的产品和技术思维差异的一个地方。

我有个观念就是——产品的成功远远不止是功能做得怎么样，所以我很多精力都不是在画原型，而是设计整体运营流程、协调运营资源。没有哪个产品是只靠功能好用，酒香不怕巷子深也不能把酒埋土里呀。其实这一条跟上一条本质也是一回事，其实不管是用户调研还是产品运营，归根结底就是——“用”。产品经理非常在乎，产品是拿来用的，这件事。画原型的草图根本不是产品经理产出的价值，只有产品被用了，才能体现产品的价值。但是对于开发工作来说，实现某个功能，就是技术的价值体现。
在很多招聘者眼中，懂技术的产品经理非常加分。但我认为不懂技术的产品在技术以外的领域有得天独厚的优势——可能正是因为不懂技术这样的“缺陷”，我们花更多时间涉猎非技术知识，我们思考解决方案的时候不局限于技术本身，思路更宽广、灵活。团队既需要技术背景的人，也需要非技术背景的人，这样才能避免一帮技术宅男们陷入他们熟悉的套路里——得有捣蛋鬼把他们拉出来看看外面的世界，哪怕他们会抱怨说“你拉我干嘛”。

4、技术人员往往并非用户，提议权重低于核心用户

我是个“看人下菜碟”产品经理，对技术的提议常常是抱以质疑，但是用户提出需求，我的接纳度会高很多。我之所以这么做当然不是存心找打（求生欲max），而是因为——程序大哥你不是目标用户呀！每个人想法都不同，希望的方案都不同，如何确定最终方案呢？我通常的做法是做用户访谈，因为用户是真正使用产品的人。产品最终目标不过两个：1、满足用户需求 2、实现公司kpi。这样看，提议权重价值最高的人就两个：1、用户 2、老板。产品经理不轻易采纳程序员的建议，主要是因为程序员往往不是真正的用户，除非我们做的是什么同性交友，哦不，我是说技术论坛这样的产品，技术人员自己就是用户，那你提的建议我会更容易采纳。

5、产品审美差异

决定产品最终设计结果的，我觉得有三点：首先对用户需求的理解，这是基础骨架。第二是对需求的逻辑思考，这是血肉。第三是产品审美，这是灵魂。前两者，在沟通上很容易达成共识。不懂用户？抓几个壮丁问问呗。熟悉需求之后的解决方案设计，讲逻辑的部分也很好解决，虽然每个人关注点不同，但是逻辑相对是比较容易产生最优解的。只要逻辑正确，听众理解力也在一个水平，逻辑上的沟通是很容易说服人的。最难靠沟通来达成共识的就是产品审美了。这里的审美，不是说UI、视觉设计得漂不漂亮，不是视觉上的审美，而是产品整体价值取向审美。比如苹果和微软两家公司，在产品设计上，给你的感受绝对不止是视觉上的差异，而是两家公司产品的精神内核就不同。产品审美不是能够通过沟通达成共识的事情，它需要公司上下共同认可某一种审美风格，这样最终的产出才能把风格发挥到极致。如果我心中理想的风格，在沟通过程中不断受阻，最后产品可能会在磨合和妥协中逐渐失去风格，变成千篇一律的妥协产物。而这就是国内大部分商业产品的归宿。

如果遇到想法冲突，如何应对？

我今天突然想到了一个比较好的应对方案。就是我们和其他人持有不同意见的时候，我之所以仍然倾向自己意见，是因为对方的方案有某些缺陷，或者我没有听出对方对这些缺陷的解决方案。所以，与其一个劲地推销自己方案，不如直接抛出问题：你的方案可能存在某某缺陷，你有没有考虑如何解决？说不定问着问着，你从对方口中听到他推导结果就是——你自己的方案。

总结下来，产品思维和技术思维的差异，在于产品工作内容比技术“宽”一点，在开发介入的功能设计之前，以及开发完工的功能上线之后，产品的工作全覆盖，而开发工作主要集中在开发过程中。因此对于开发未参与的一前一后两部分，容易出现信息不对称。从工作价值评估的角度讲，产品更关注产品如何被使用，而技术关注如何实现功能。除此之外的分歧，就是全人类都不可避免的——物种多样性及审美差异。

之所以写这篇文章，是希望团队更理解我的思考方式，今后合作，多一分互相理解。欢迎技术大哥们积极切磋意见，正是因为这样的碰撞才能共同创造出好产品。

就这么滴吧，祝看这篇文章的人，和你的好搭档合作愉快！