解惑 | 产品经理究竟要懂多少技术?
每一个产品小白都会被这样一个问题所困扰:产品经理是否要懂技术?有的人说:PM一定要懂技术!同时又有人说,PM不懂技术也能变得很优秀!那么,在实际工作中,一个PM在面对众多类似于”PM是否要懂技术“的问题时,到底要怎么选择呢?
PM为什么要懂技术?
首先,懂技术的PM能赢得RD更多的尊重。
PM 虽然并不是凌驾于 RD 之上的角色,但不得不说,按照公司的业务流程,RD的工作确实是遵照着 PM 的设计来进行实现,这多少会让 RD 生出低人一等的感觉,同时也不乏有一些PM 本身也是这么认为的。这可能是让骄傲的RD们不爽的地方:自己了解产品实现的每一个细节,却要听一个技术门外汉的话。很多不懂技术的PM无法用专业而准确的语言向RD们描述产品,让RD们不知所云,这样的PM在RD们看来确实有一些白痴。所以如果 PM 懂技术的话,是会在一定程度上赢得 RD 的尊重的。说白了就是,如果我是RD,我会更尊重懂技术的PM。
其次,懂技术会让PM和RD之间的沟通更加顺畅。
技术解决的不仅仅是心理层面的问题,事实上,这会让 PM 和 RD 之间更快地对一件事达成共识。
我们常常觉得 RD出于对技术的自负甩术语、甩原理,让PM和RD似乎永远都有一道难以逾越的沟通鸿沟。其实 RD 们在这样交流的时候,并不是在企图彰显技术的 NB,这似乎更多的是一种习惯,是技术流长期和技术流交流所养成的习惯,这样的习惯是为了减少RD之间的沟通成本,在最短的时间里达成对工作的共识。所以,PM 懂技术,可以更好地去理解和适应这种习惯,让双方对产品的理解的一致性最大化,从而减少后期返工的可能性。
懂一些技术还能在一个方面帮助到PM们,就是可以让自己不被 RD 们忽悠。不懂技术的PM如果被 RD 绕得云里雾里,无法反驳、无力判断,那也是一件很可怕的事情,因为可能会让产品的实现大幅度延期,浪费了时间也浪费了资源。
最后,懂些技术可以把 PM从天马行空拉回到脚踏实地。
很多时候,RD 会消极配合 PM,很有可能是 PM 的设计在技术可行性上出现了问题或制造了麻烦。于是在 RD 看来,PM的天马行空是不负责任的,但最后却把各种不靠谱问题都抛给了他们。就好像一个对土木工程毫无了解的建筑设计师,花了大把力气设计出的建筑稿最后却被证明是无法实现的。PM 有时候也需要在技术层面上了解一砖一瓦是如何落实的,才能让设计变得踏实。
PM需要懂什么技术?
成功的产品经理必须是被RD尊敬的。虽然实际情况是,RD的水平和素质也良莠不齐,但要做一个成功的产品经理,必须假设面对的是一帮最优秀的RD,这样才不至于被当作白痴来骂。因此RD应该是这样一帮人,他们是聪明的,坚毅的,勇于克服困难的;中间也不乏文艺类的,或懂艺术,或注重体验,或关心人文。产品经理也不必为了能和各种RD沟通,使自己面面俱到,但至少对自己要有一个明确的定位,并把自己的定位展现在RD面前。
RD也知道产品经理是要与多种职责的人打交道的,要有较强的综合能力,不会在技术领域拿自己的强项和产品经理过不去,但他们同时认为一个优秀的产品经理要具备一些能力,能力不足的产品经理不会被RD尊敬。这些能力包括:
●对技术的理解
●美学的修养
●强大的学习能力
●无限热情
本文只谈产品经理对技术的掌握,另外三点先不做讨论。
产品经理应该懂一些技术,但产品经理也没必要掌握技术细节。产品的技术实现是由RD完成的。在大多数情况下,产品经理只要做到理解RD,尽量和RD做“无损沟通”即可。
非技术出身的产品经理是比较辛苦的,因为你或多或少都要在技术上下不少功夫。技术不简单,种类多,各有特色,发展日新月异,是产品经理和RD要时刻关注的主题。即便是对技术做整体的宏观的把握,也不是一个不懂技术的人一时半会就能融会贯通的。非技术出身的产品经理首先要迈过技术上的一道坎,让不懂技术的人看来,你是一个技术领域的内行。技术出身的产品经理,对技术的理解自然不是问题,但在和RD沟通时,会不自觉疏忽的是,容易过分纠结于细节,尤其是曾经在技术领域有不菲造诣的产品经理。产品经理不是对产品做技术实现的人,技术更新那么快,技术细节本身甚至技术实现的理念,会迅速更新迭代,产品经理和RD死磕技术细节得不偿失。
上文提到的“无损沟通”,是指产品经理和RD在沟通中彼此完全理解,不存在疏漏和误解。这是不可能的,但这必须是二者沟通的目标。
产品经理和RD沟通时,两个方面尤其重要:
●A:对需求的沟通
●B:对技术实现的沟通
首先,对需求的沟通主要应用于产品经理向RD阐述需求的场景中。RD实现产品功能,是基于对需求的理解;在功能实现过程中和实现完成后,需求的变化又可能带来产品实现上的灾难。如果RD不能准确理解产品经理对需求的描述,很可能实现的功能与产品经理的想法大相径庭,浪费大家的时间;如果产品经理想法不够明确,导致需求变来变去,无疑是对RD的恶意攻击。需求上任意一个小小的变化,在代码实现中的都有可能产生巨烦,甚至会动摇代码的整体架构。从RD的角度来说,虽然RD在技术实现时以构建稳定的系统为目标,尽量灵活应对需求的变化,让系统易于扩展和维护,但这也是要基于RD们对需求的理解,以及对潜在的需求变化的预测。如果在沟通过程中做不到让RD准确把握需求,那就不用考虑产品实现的满意度了。
然后,对技术实现的沟通主要应用于RD向产品经理沟通的场景中。如果产品经理对技术理解不够,RD很难向产品经理讲明白自己的工作现状,当产品经理想要改变需求或者希望为产品添加新的特性时,也无法准确理解RD对此产生的各种反应。
只有依靠足够技术基础,产品经理才能理解RD对工作和任务的描述,把握技术实现的难度,制定更加合适的计划。至于多少技术才算“足够”,需要产品经理和RD慢慢中磨合了。
最后,请相信RD,请在技术上放手!
现在我们知道了:产品经理若要和RD默契配合,最重要的是要赢得RD们的尊敬。产品经理并不是懂的技术越细越好,而是要在宏观上对技术有总体上的把握,在微观上懂得放手,相信RD。
PM能不能不懂技术?
其实 PM 懂技术,也未必是必须的。当然这么说也需要一些前提,而满足这些前提的往往是一些不世出的产品天才,不懂技术也照样成为了高段位的产品经理。具体说来,有以下三种情况:
1.这位 PM 有着非常成功的产品经验
技术流虽然骄傲,但也有着崇尚权威的谦卑。如果你有着非常辉煌的历史,即使你对技术一窍不通,但凭借着“PM 将再一次带领大家走向产品成功”的信念也足以令 RD 们信服。不过能够做到这种程度的 PM,不懂技术的应该是凤毛麟角吧。
2.这位 PM 有着非常敏锐的产品直觉
如位 PM 有着非常敏锐的产品直觉,尤其对新技术可能带来的产品革新有着灵敏的感知的话也是被排除在外的。好的 sense 是能令其他人都跟着拍手叫好的,RD再顽固,也是能够嗅到方向的,所以也会愿意跟着你的直觉走。不过,sense 这种东西,有时候跟天赋一样可遇而不可求。
3. 这位 PM 有着很强大的逻辑思维能力
技术流都是逻辑控,如果你的设计出现了逻辑上漏洞或者问题,将会让RD们无比鄙夷,如果已经令RD们做了很多无用功,那更可能招致怨念。正是因为RD们对逻辑的执着与看重,PM的逻辑思维能力就更加成为了一个巨大的考验。另外学习技术其实可以锻炼人的逻辑能力。当然,懂技术到逻辑强大,这不是充要条件。
经过以上的讨论,相信对自身了解的产品小白们都有了比较全面的判断。对于一个新人来说,在一开始就有如上的三个优势的可能性是非常低的。所以,对于大多数初学者来说,想做产品经理,还是懂一些技术为好。当然也不反对对自己充满信心的产品新人们勇敢尝试。
最后,应该说明的是:技术有时候反而会给设计思维带来限制。例如,PM 看产品可能首先考虑的是产品定位,而 RD 看产品首先想到的是功能。个人以前就很喜欢拿功能攒产品,做出来的东西基本不能称之为产品。这也许就是前面所说的思维模式上的差别。PM 的思维模式其实是很宝贵的,所以学习技术,还需慎重。
总而言之,PM 应该是懂些技术的,或许不需要懂到技术的细枝末节,但至少要有常识,再次也要对技术表现出尊重和热情。只有这样才有可能成为一个优秀的产品经理。