深度思考 | 产品经理要不要懂技术的底层逻辑

14 评论 9744 浏览 90 收藏 25 分钟

编辑导语:众所周知,产品经理是一个综合能力要求很强的岗位,需要了解很多方面的知识。那在技术方面呢?产品经理要不要懂技术的底层逻辑?本文就此问题,从六个方面来展开论述,逻辑清晰。推荐对产品经理感兴趣的盆友来阅读。

有产品的同学问我,他的领导让他懂一点技术以方便工作,但领导说的不明确,自己又不好意思继续追问,因此现在很困惑,问我作为产品经理要懂技术吗?

要回答这个问题,我们要把它拆开来回答,它包含了以下6个方面:

  1. 遇到哪些问题
  2. 懂技术的目的
  3. 懂到什么程度
  4. 要懂哪些内容
  5. 如何有效学习
  6. 懂技术的好处

一、常见问题

案例一:

  • 开发:这个做不了。
  • 产品:……

案例二:

  • 开发:这个功能至少要开发2周。
  • 产品:啊,这么简单的功能要这么久啊?等上线了热度都过了。
  • 开发:是的…因为…算了,跟你说也不明白。
  • 产品:……

在日常工作中,产品经理可能有以下类似的烦恼:

  • 提出的需求被开发觉得异想天开,需求被拒,经常返工;
  • 觉得开发评估时间过长,自己很无力;
  • 需求评审会被开发批的体无完肤、一无是处;
  • 听不懂开发说的内容,开会时云里雾里,安排任务效率低;
  • 不知道技术的优劣,做决策拖后腿;
  • 出了问题不知道找谁,开发相互推诿,用户的问题无法得到快速解决;
  • 对项目进度无法掌控,版本经常延期;
  • 上线跟打战一样,问题还特别多;
  • 开发的领导好难打交道,感觉很凶;
  • ……

网上讨论最多的就是案例中所描述两个的场景,很多人为之苦恼,感觉自己经常被开发忽悠,事情推进不了就算了,开发说的话还阴阳怪气,说话夹杂着嫌弃,眼神充满了鄙夷,非常的没面子。

二、找到问题本质

很多人认为之所以出现上面的情况,就是因为自己不懂技术,当产品经理懂技术之后,开发也就无法再忽悠,没有了鄙视和嫌弃,以上问题也能迎刃而解;即便没有解决,自己的技能树上又多了一个技能,总比只懂产品要强。

这种想法对吗?不一定。

这种想法实际上是在用战术上的勤奋来掩饰战略上的懒惰,开发是一个很看重实战的岗位,我们利用业余时间学习的一些皮毛,就想和在实战中厮杀多年的开发掰手腕,那就把开发岗位看太轻了,在他们眼里,我们和刚入行的开发没区别。

退一步说,哪怕你天赋不错,学到了一些技术,开发想忽悠你还是一样,因为你不了解实际的代码情况。

即使同样能力的开发,面对陌生的项目、不熟悉的框架和代码,在做评估的时候,都会选择保守,你也不能代替他们去开发,这种情况尤其以跨部门沟通时更加明显,因为你根本指挥不了他们。

开发说“做不了”,你说“可以做”,开发说“你来?”。

开发说“这个功能最少要3天”;你说“少唬我,我可是练过的,最多1天半就够了”;开发说“我就要3天”,接下来你有两个选择:

  1. 当场揭穿他,可能会上演全武行;
  2. 向他领导告状,领导可能和颜悦色的告诉你,要相信专业的;也许领导这次帮你解决了,下次呢?

因此,懂技术不一定能解决“做不做“和“忽悠”的问题,或者说要解决以上的两个问题和懂技术不能划等号,那可以给以后找工作加分吗?

绝大多数情况不行,除非你在一个项目里即是产品,又是开发,而且项目完整跟完并上线运营,并且这个项目和这家公司类似(需要运气),这样的懂技术才可能成为加分项,否则很难。

因为我们面试的不是技术岗位,级别越高价值也越低;产研负责人岗可能有价值,但这时就不是加分项,而是必要条件。

有人不服气说,怎么就不是加分项,懂技术可以很好的和开发沟通,是的,可能,但这里的重点是沟通能力,技术只是其中的一小部分,也不能划等号,你是不是听过很多程序员都不擅长沟通的例子。

当然,以上的分析不是说懂技术没有价值,而是不希望将懂技术当成唯一的阻碍,产品做不好是因为开发不配合,开发不配合是因为我不懂技术,我很苦恼,我没有办法。

将问题推给环境,推给外在因素,没有思考对问题的本质,但是,产品经理恰恰是需要去思考问题本质的岗位。

懂技术可以辅助你把工作做的更好,但不懂也不是阻碍你推进产品进度的关键因素,绝大多数人面临推进难的问题,究其本质,在我看来就三块:

  1. 甲方的优越感;
  2. 能力的不自知;
  3. 和开发之间的信任缺失。

1. 甲方的优越感

说出来你可能不信,开发在公司里面其实是弱势群体,作为最下游的执行方,很多时候是很被动没有话语权的,甚至经常要背黑锅。

而产品经理作为甲方,习惯把开发当成纯执行者,听话就好别瞎BB。

优越感带来的第一个问题,是无法接受对方提出的修改意见和建议,觉得在挑战自己的专业,你一个开发懂什么?(这句话开发也经常对产品说,你啥也不懂),有时实在无法说服对方,就耍赖说“我不管,我就要,实现不了是你的能力问题,怎么实现是你们的事”。

优越感带来的第二个问题,是在需求被拒时挫败感很强,内心觉得被开发鄙视了,其实真的想多了,开发一般都比较单纯,不会因为某个人不懂技术而看不起他,绝大多数问题是因为某个人的态度导致。

所以解决问题第一步,端正态度,实现和开发平等对话,不是甲方乙方的关系,而是战友关系,将双方拉到统一战线。

2. 能力的不自知

需求来自来自用户的诉求、老板的想法,产品经理很容易成为传声筒,没有去思考逻辑和细节是否合理,绝大多数开发与产品间的争吵,都是因为产品需求逻辑的问题。

在需求评审会中,面对开发的疑问,无法在逻辑上讲通,产品经理很委屈,觉得这不是自己的错,明明是用户的需求,老板都答应了,开发怎么还这样呢?这不是刁难人吗?

面对开发的不配合,没有去思考自己的问题,而是怀疑开发在针对自己,给自己的错误找很多借口。

人与人之间的合作,不会因为对方不懂己方的专业而嘲笑,而是因为对方不自知、不虚心、不学习,才会让人看不起。

学会调整自己的心态,认识自己的不足和知识盲点,不明白的地方虚心请教,承认自己不足有时比去学习一项新技能更难,主动避险是人的天性,我们习惯为问题找外部原因,而忽略了对自己内心的建设。

3. 和研发之间的信任缺失

我们习惯用“怼”和“甩锅”来构建产品和开发之间的爱恨情仇,从内心就已经将产品和开发摆在了对立面,在双方划了一条信任鸿沟,需求评审会就变成了博弈游戏,认为对方是欺负自己不懂(当然也有可能是真的,但不常见)。

你觉得开发在偷奸耍滑,开发效率这么低,每天不知道在做什么,开发觉得你在异想天开,啥也不懂,脑子瓦特了。

懂技术似乎是一个构建信任关系的桥梁,但其实重点是如何和开发建立信任关系,而不是一定要去学习技术,其他方法可以尝试,如共同兴趣爱好,日常的交流关怀,都是不错的方法。

在自己领域足够强也能增加信任度,需求够专业,逻辑性够强,思考有深度,上线有结果等等,人性是对强者会有天然的崇拜感,做出成绩就是最好的信任背书,开发也不会因为你不懂技术而轻视你,因为相信你肯定能做好。

因此,合作的基础是信任你同部门的队友,双方不是你死我活的拉锯战,而是为了实现共同目标的攻坚战,通过统一目标也可以成为自己人,信任每个人在自己擅长的领域能做出最好的判断。

如果你做不到对每个人的信任,那可以招一个你信任的资深开发,让他来帮助你做判断也是一个有效的方法,没有了信任,你再懂技术也没有用。

倘若是跨部门,在对方的阵营中找到一个可信任的战友是有必要的,这个战友最好是团队中比较资深的那种,亦或者是有想法、责任感比较高,可以帮助你解决很多问题,时不时的请教,也能让你做事情事半功倍。

排除了以上三点问题,先认清自己,认清环境,找到关键因素,看看懂技术是不是真的是你遇到问题的解法。

三、懂技术的正确姿势

1. 懂技术的目的

要不要懂技术,先要想清楚自己的目的,以终为始才能做到有的放矢,不同的目的,所需要学习的内容和程度会有所区别,但不管是什么目的,有一点可以肯定的是:

绝对不是去代替开发写代码!除非你是纯粹个人兴趣,除非你是创业者要控制成本,否则,千万不要本末倒置,将自己陷入开发的自嗨中不能自拔。

甚至有些人还说要懂技术架构、懂计算机底层,这是要飞天吗?

一个开发经过多年的打拼,多个项目线上实操,没日没夜的解决各种性能瓶颈,才能成为一个合格的架构师,才敢说自己懂技术架构。

一个工作5年以上的老码农,如果没看过一些技术的源码,只敢谦虚的说自己知道原理和怎么用,底层如何实现还需要研究。

咱就看了几个名词解释,安装了环境输出了Hello World,开发了一些简单的增删改查就大言不惭的说我懂技术架构,懂技术底层,只能是班门弄斧。

技术是一个需要持续学习的领域,每隔几个月就会有新的技术诞生,永远也学不完。

只有清楚自己的目的,才能清楚学习边界,才能在有限的时间内快速掌握所需要的知识,并在实际工作中使用产生价值,任何不能对你的目的产生帮助的都是鸡肋,要及时止损。

  • 你是想减少原型的返工次数?出需求时考虑的更加全面?
  • 还是想更好的和开发打成一片?推进工作时更加高效?
  • 还是想对产品迭代掌控力更强?更快的出结果?
  • 还是想有没有更优的解决方案?提高用户体验?
  • 还是想在产品的商业决策更自如?决策效率更高?

2. 懂到什么程度

列出自己的目的,才能知道自己要学习到什么程度,以及学习哪些内容,并不是要所有的都要学,所有的都要懂。

想要和开发交流时跟上节奏,那就要懂一些行业内的专业名词或技术专业名词。

因为技术讨论方案时基本上的内容是“关键词+逻辑”,逻辑我相信大家能听懂,只是夹杂着关键词会出现断层的情况。

因此理解了关键词的含义,就能明白开发所表达的意思,才能切入解决方案讨论,接下来他们各自的分工和估时,能有效提出个人见解。

想要减少需求的返工几率,推进需求开发效率,要了解现行技术边界,公司研发能力边界,清楚哪些能做哪些不能做。

清楚岗位的分工、职责,和完整的产品开发流程,大概知道什么样的问题应该去找谁解决。

了解一些不同岗位用到的软件、工具、技术名词、专业术语等,时不时能请教下开发,这种好学的求知欲能让开发认为你是自己人,也乐于去做一回老师。

既能和开发打成一片,也能在提出需求时考虑到实现难度,自己能提前进行规避。

想要对产品迭代掌控力更强,那就要掌握一定的项目管理知识,包括流程和管理工具,清楚团队中每个人的开发能力和效率,学会拆解开发任务,掌握正确的估时方法,对常见功能估时心里有底,掌握日常跟进内容,具备风控能力,并在出现延期时进行有效决策。

想要了解更优的产品解决方案,提高用户体验,那要熟悉产品所在的技术生态,看生态内开放了哪些接口和能力(如公众号和小程序生态,可以看开放平台),关注行业技术升级动态,找到能提高产品体验的结合点。

清楚行业内的技术栈能解决什么问题,优缺点是什么。

想要找到产品突破点,提高决策效率,要对数据埋点技术有所了解,清楚不同的数据收集方式的应用场景,掌握数据库的基础知识,比如表、字段、视图等,学会使用sql查询语句,或者一些BI工具,这样可以根据自己的想法去拉取想要的数据,不需要每次求助开发,让决策更高效。

产品经理对于技术的懂,只要做到知道是什么,有什么用即可,至于怎么用,好不好用,可以让技术来把握。

如果你是一个创业者,觉得研发总是拖后腿,产品节奏跟不上,自己从头学技术肯定不是最好的方案,要不就找一个技术合伙人,要不找一个信任的外包团队长期合作,还可以使用低代码开发平台,也能满足80%的标准化需求,把自己不擅长的剥离出去,创业更要聚焦。

如果你负责工具类的产品,尤其像给技术人员使用的,比如数据中台、无代码开发平台、可视化平台、云平台等,是必须要精通这个行业的技术的,请无视上面的内容。

3. 要懂哪些内容

根据上面所描述的程度,列出了以下相关技术内容。

大家根据自己的目的,选择有帮助的内容去了解,一些关键词自己去查,可以采用联想词学习法扩充知识点,按照自己的理解做笔记,印象会更加深刻。

  • 技术人员的思维方式,知道如何和他们沟通。
  • 技术边界,包括公司内部人力和技术能力边界,知晓哪些能做哪些不能做。
  • 开发岗位分工和责任:产品、UI设计、前端、后端、测试、DBA、运维。
  • 完整的产品开发流程。
  • 开发人员的一般工作流程。
  • 开发说的“做不了”到底包含哪些信息,以及如何去推进。
  • 任务估时的常用步骤方法、任务估时参考。
  • WEB技术:URL、TCP/IP、HTTP/HTTPS、SSL。
  • 前端技术:SDK、POST/GET、AJAX,COOKIE/SESSION、TOKEN、原生开发、混合开发、小程序。
  • 后端技术:长连接、短连接、同步、异步、回调、队列、栈。
  • 技术工具:Postman、Firebug、IDE。
  • 技术术语:搭环境、建表、写死、技术栈、架构、框架。
  • API接口是什么,包含哪些内容。
  • 服务器、服务器系统、数据库、缓存、定时任务。
  • 沟通和提问的技巧。

4. 如何有效学习

快速掌握一个行业内所需要懂的知识,我觉得冯唐老师的《冯唐成事心法》中的方法非常值得借鉴:

  1. 先找到100个行业内的关键词,然后去查关键词的定义,我们只要知道是什么,以及有什么用即可,做完了这一步,基本上你就能和开发有共同话题了。
  2. 总结出你不明白的点,找几个资深点的人深聊,看他们关注什么,看重什么,这是和公司的人建立关系的过程,不要怕问一些傻问题,对于一些有求知欲的人,很多人还是愿意当一回老师的。
  3. 找几本行业内的专著,认真阅读做笔记,这步可选择性的做。

如果你还想对开发了解更深刻一些,掌握一些开发的基础能力,增加自己的逻辑思维能力,可以先学一些入门较为简单的语言,从HTML/CSS/SQL开始,能够自己做几个静态页,能够自己拉想要的数据。

之后可以尝试学习JavaScript/TypeScript,能做一些简单的交互或者小程序,这样对开发的工作和流程体会更深,前端语言所见即所得,有效的反馈能够快速获得成就感,不至于装个环境就让你从入门到放弃。

这个时候如果你觉得还挺有意思的,可以深入了解前端的框架如vue,或者选择一门服务端语言如PHP/GO/PYTHON/JAVA/C++,找一个实战的案例视频,实实在在的开发一个项目,基本上就算技术入门了。

想学更多的技术,可以去 W3cschool 技术学习社区菜鸟编程平台,里面已经涵盖了目前所有的流行技术,内容丰富,且大部分是免费的。

随着时间的推移,产品经理对某个领域的技术也会越来越熟悉,除非个人拒绝学习,否则在工作的压力之下,能学到很多技术方面的知识。

四、懂技术的好处

除了解决自己面临的一些问题,懂技术还有其他的好处。

可以和开发讨价还价,而对方不会认为你过界,不是外行指导内行,通过沟通中挖掘出最优的方案,你还可以勇敢的和开发一起做任务拆解,直到将每个人的每天做什么,安排的明明白白,并得到开发的认可。

其次,编写需求文档逻辑性更强,能考虑到一些产品的边际情况,产品的体验也更严谨,同时适当的考虑技术的实现难度,对产品逻辑进行优化,选择开发更高效的方法去实现同样的价值。

然后,能考虑到产品远期的发展对技术的影响,并认真和开发探讨,做好提前规划,不至于后期对技术架构进行大调整,开发也会认为你很懂他们,更愿意和你合作,相互信任和支持能够给产品经理带来强烈的自信。

最后,当你想去验证一个想法,能够想到快速实验的解决方案,并能和开发一起讨论得出最省成本的实现方法,没资源时,你能找到一定的方法把事办好,有资源时,能挖掘出资源的更大价值。

五、最后的话

俞军在《俞军产品方法论》中提到,产品经理的职责是要对产品的市场结果负责,要关注产品的“需求、生产、销售”三个环节,并“协调”公司不同分工下的不同职能,让大家共同完成目标。

这显然是从更高的角度去定义了产品经理的工作内容,产品经理是一个综合能力要求很强的岗位,你可能需要了解很多方面的知识,你可能会遇到很多困难。

但唯一不变的是产品价值目标的坚持,为了实现目标你会去寻找一切可能的解决方案,懂技术只是其中的一个解决方案,要与不要,就看能不能解决问题,能不能帮助到你。

很多认为自己做的事情很杂,似乎没有重点,那是我们对自己负责的产品理解还不深刻,还没有形成那份“感情”,做产品,就像谈恋爱,要有敬畏之心!

 

作者:周武,曾就职于腾讯、边锋,现在一家上市公司产品负责人;公众号:周武说

本文由@周武 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 pexels,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 产品学会开发的底层逻辑是有极大帮助的。因为开发的底层逻辑是经过千锤百炼的方法论,这绝对不是酷炫新颖的产品方法论可以相提并论的。

    回复
  2. 产品应该懂一些前后端的基本开发逻辑,如果要做的久。也可以学一下前端这个起步比较低。直接学服务器的话最好。其实产品后续打交道比较多都是服务器。比如策略产品经理,明年就是服务器算法层,实话这个服务器程序都不一定弄得懂。

    回复
  3. 很好的文章,适合产品小白来看。尤其在做解决方案时,经常会画一些时序图之类的,理解技术原理才能不被开发挑战,效率也会提高。但若关注具体技术实现,那就是比较明显的“越界”行为了

    回复
  4. 产品经理当然要懂技术的底层逻辑!作者写的很不错!推荐各位小白来看看~

    回复
  5. 适合小白看的文章,确实了解多点技术,跟人员沟通起来也会更好。但可没有想象中这么容易。

    回复
    1. 知识要转换成经验在于多运用,然后我们把事情想难一些,在解决时可能心里落差就不会很大了

      回复
  6. 好文章,看来老兄也是技术出身的吧,对于和研发的协作分析的很到位。我也是做研发的,当然也做产品,产品人员不论在如何懂技术,也不能拿这个去挑战技术的专业性,如果这样,产品经理懂技术就有点目的不纯了。懂技术,懂底层逻辑是产品经理的加分项,是有优势的,这个其实是自己管理自己的技能,做的产品要靠谱,不要天天去天上够星星,要落地。但有时候太考虑实现可行性,这也会约束自己,陷入自己的能力认知陷阱,限制了自己做产品的思路。另外懂点技术,要用它更好的和研发去沟通,同理心的沟通,获取对方的支持。

    回复
    1. 哈哈,是的,我是技术出身,开发出身的人对于同理心的理解会更加深刻一些😂

      回复
  7. 底层逻辑哪那么容易懂,我开发转产品的到别的项目里不还是白纸一张,上面哪些开发的词汇的概念基本没用。

    回复
    1. 这里说的底层逻辑其实不是说技术方面,而是确定问题的根本点,然后有针对性的去寻找解决方案;
      很多人说开发转产品在沟通时会有优势,在某些时候也是不一定的,但具备开发的逻辑性,解决问题时可能效率会高一些

      回复
  8. 要确定你懂得技术的目的,毕竟现在的在职人员他们的时间还是挺紧张的,要想明白懂了之后能发挥什么作用,有针对性的去学习了解,效率更高。

    回复
    1. 是的,每个人都有自己的工作,都不愿意被打扰,沟通时简单明了,能够快速抓住关键点,能极大的提升好感度

      回复
  9. 懂得底层逻辑才能找到问题的本质,找到问题的本质才能对症下药。

    回复
    1. ღ( ´・ᴗ・` )比心

      回复