产品圈有个非常经典的日经问题：产品经理要不要懂技术。这个问题每个人都有自己的看法和意见，大家也很难说服别人。这篇文章，我们来看看作者对这个问题的看法，是否和你的一样。

本文的主题是产品经理要不要懂技术。这个问题在产品经理圈可以说是非常经典了。先给大家讲讲为什么会存在着这一问题。

产品经理在日常工作中，会经常和技术同学打交道，也就是所谓的程序员。这是因为产品经理要靠技术同学把自己负责的需求通过开发实现成一个个产品功能。众所周知，程序员的薪水相对于其他行业的其他岗位是有明显优势的，这是因为除了要付出比其他岗位更长的工作时间之外，这个工种是需要有一定的技术壁垒的，换句话说不是人人都能当程序员的。

产品经理和程序员聊需求，可与普通的聊天不同：

首先，大家都很忙。也许这位程序员同学，需要并行开发许多需求，甚至有些需求很紧急。作为产品经理的你，也可能同样很忙碌，毕竟产品经理是一名六边形战士，工作时间琐碎。所以产品经理和程序员之间的沟通过程一定要确保高效，即产品经理要能够快速的让程序员理解需求及背景，同时程序员也要在短时间内给到产品经理需要的反馈。

那么如何确保高效呢？

我们先来说说不高效的场景。产品经理和技术沟通，通常是围绕着需求的解决方案进行讨论，简单来说就是产品经理告诉程序员我想要什么，程序员带着批判性思维给产品经理反馈是否合理能否实现以及是否有更好的解决方案（就像产品经理与需求发起方进行对接需求的过程差不多）。很多时候程序员会给你反馈“这事儿做不了，无法实现”。我们暂且不说态度问题，毕竟大家工作都是对事不对人，我们先认为这个需求按照产品经理的要求在技术上确实无法实现。

如果你不懂技术，你只能得到一个结果的反馈。这时你可能试图去问程序员同学为什么做不了，出现了什么问题。但这是属于程序员同学专业领域的问题，很多时候并不是三言两语就能说清的。站在程序员同学的角度，如果我有时间且乐善好施，愿意用一些你能听懂的语言去给你科普一下，但事实上大家都很忙，先不说程序员同学是否愿意给你讲，如果程序员同学态度一般及以下，你可能都张不开口去问，这可能也是产品经理和程序员之间的微妙之处。

整个过程在程序员同学眼中，就是“产品经理的无理取闹”，所以你得到的答案就是“做不了”。对于这个反馈，如果你只是个初中级产品经理，你一定是要回去反馈的。这之后的过程就真的是“传话效应”了，后续消息链路基本上就是“你 -> 你老板 -> 他老板 -> 他”。这个链路展示出来，就不需要再多解释什么了。久而久之，你会发现推进工作真的是很难办，然后和其他人一样，在脉脉或者其他论坛匿名抨击程序员全体同仁啥也不是。

可如果你懂技术，或者略懂，你会发现这个过程相对来说会更轻松一些。

在与程序员交流之前，你脑海中大概有一个技术方案的流程图，大致了解解决需求的技术方案前后承接关系，数据流转。基于你对自身业务的认知，你大概对技术方案各部分能否实现有个初步判断。你甚至可以带着问题去向程序员提问。

这时你与程序员的沟通，可能已经从发号施令改为了技术交流或虚心求教。其实能让一个人感受到尊重的最好方式就是能在一个频道上交流和沟通，职场如此，感情中亦是如此。相信所有有一定技术壁垒的职业都是这样，毕竟科普这个过程是需要有时间成本的，这也就是对牛弹琴的通俗解释吧。

在沟通过程中，对于程序员的反馈，你能基本理解，或者引申出其他问题，甚至可能会提醒程序员，我们之前做过的某方案能不能复用？从业务角度哪些地方要注意什么？我们业务未来可能会如何发展，是否要从技术上做好可扩展性，毕竟业务的发展方向也会影响程序员同学设计技术方案。

当然，如果程序员同学并不是技术出身，可能也很难和程序员同学做到完全同频共振，在这个沟通的过程中，你一定也会有很多问题：“这个接口是干什么的？”、“这个专业名词是啥意思”……所以这其实是个积累的过程，如果你有心，在不断的与程序员沟通交流的过程中，你也会积累很多一些常见问题的答案，再不济人家不爱给你科普，就自己搜搜呗……

综上，产品经理懂技术，其实是对程序员同学最大的尊重，这一定会对产研之间沟通需求起到积极的作用。此外，产品经理懂技术，对理解自己业务甚至整个公司业务都有好处，毕竟可以从数据的流向来分析自己的业务：在整个公司的业务中处于什么样的位置，有哪些承接、上下游关系……这样如果之后面对跨部门的需求时，你大概也能对需求都需要哪几个部门支持有个大概认识，也能侧面反映出你的专业。

最后，你要真懂点儿，你也能知道这帮程序员是不是蒙你呢：这需求到底能不能做？这需求到底要不要做五个工作日？当然，这只是个玩笑，产品经理还是要单纯一些，可以用批判性思维考虑问题，但不要用批判性眼光去看待同仁。

这里笔者再谈一点建议，在找技术之前可以的话先去看看这位程序员同学在忙什么，毕竟你的紧急需求未必是人家的紧急需求。