产品经理需要懂技术吗?懂到什么程度?

如果不需要,为什么?如果需要,能不能简单介绍一下对于没有技术背景的人怎样达到这个程度,有没有好的方法?或者好的资源可以推荐。
关注者
10,637
被浏览
1,247,554

382 个回答

收录于 编辑推荐知乎周刊 ·

最近七年,我都在做互联网产品,其中前五年分别在创业公司和上市公司里,做别人的产品;近两年在创业,做自己的产品。

我的体会是:产品经理需要懂技术,创业者尤其需要。但前提是你总觉得有股憋不住的想要做点儿什么的冲动,如果打算混安稳日子,特别是在大公司,你什么都不需要懂,反而要小心别“知道的太多了”,傻人一生平安。

做产品这几年,和开发工程师打交道最多,和他们交流通常有两大忌:

一. 忌不懂技术

更准确的说,是不能缺乏设计、开发一个互联网产品基本的技术常识,比如至少要清楚一个网站从不存在到能被用户访问,需要哪些必须的环节;也要明白一个App从你的脑海走到用户的手机里,需要经历怎样的过程。

有常识,当然不一定就能做出好产品,但没常识,就很象在村里呆了半辈子的人乍到城市,一举一动即使小心翼翼,也没法儿不透着突兀和不和谐。

很多公司都有完全不懂技术的产品人,大多年龄较长,也许是互联网出现的时候,他们已经过了充满好奇和渴望未知的年龄,不愿意放低身段去学习新东西,喜欢只凭着想象和自己的生活经验就开喷,间或以若干近期热门关键词作为点缀,以示自己尚蹲在潮流尖端。

这样的人也许能忽悠某些领导,但一定不招工程师待见,他们可能什么都不说,但心里已经开始等着看笑话,交给他们的开发需求,自然也是能拖则拖、能蒙则蒙。

二. 忌懂技术

我遇到不少工程师喜欢说:“只要产品需求明确,技术上一切都能实现。”

这句话听起来相当豪迈,也让产品经理大为放心,觉得技术真是产品的坚强后盾。但其实传递了一个特别糟糕的信号。

当工程师这么说的时候,潜台词是:“你弄好你自己的事儿就行了,别来管我!”而且这种说法隐含着一个乐观但显然并不现实的假设:技术是无所不能的,他(掌握技术的人)也象灯神一样,可以实现你的任何愿望,只要你能明确的描述它。

我不知道阿拉丁说完愿望之后,假如胆敢继续追问灯神将具体采用何种技术方案来实现的话,会不会被塞到灯里,但我知道很多工程师在发现你关注技术层面过深的时候,都会有种领地被侵犯的感觉。

这就是工程师维护自己专业槽的本能,与行业中其它角色相比,工程师地位不是最高,待遇也不是最好,还经常加班加的要死要活的,唯一得天独厚的优势,就是专业槽比任何角色都深。关于产品、关于UI、甚至关于商业模式每个从业人员都能喷上几句,要是说到用户体验,那更是连业外人士都敢大喷特喷而没有任何心理负担:反正我就是用户嘛,越傻越光荣。而一旦涉及到代码,大多数人就直接晕菜了。想想那些UI设计师的苦逼段子,工作时没有喷子们指手划脚的干扰,真是上帝赋予工程师独有的恩赐。

所以当他们认为有外人正试图跨越这条槽时,自然会有所警惕,甚至体现出抵制和敌意。当一个产品经理发现工程师开始比较密集的使用术语或拼命把简单问题往复杂了说,你应该知道,他们在槽边开始向你射箭了。

从整个产品乃至公司的角度来说,各个专业角色之间的专业槽都是应该被填平的,产品经理不该对工程师玩挟天子以令诸侯,不要总假装自己是用户的三个代表,动不动就拿想象中的“用户需求”当“奉天承运”来用;工程师也不必总装灯神,假装无所不能很累的,工程师之间必有能力高下之分,其实有时候功能做不了或做不好,纯粹只是因为工程师能力所限。如果彼此坦诚一些,大可以提前有效沟通,尽可能避开那些投入产出比过低的部分,有不少工程师不愿意拿出来讨论的技术实现上的细节,都是值得产品经理参与进来的,在这些细节上如何取舍与抉择,会对产品的开发进度、性能甚至功能带来极大的影响,如果沟通到位,往往可以让开发工程师少做大量无用功。在我开始自己动手写代码之后,对这一点有了越来越深的体会。

下面就说说我为什么开始学写代码,算是回答问题的后半部分吧。

在我做互联网产品的前五年里,我对技术的了解仅维持在常识范畴,能够手写的代码只有html和css,连js都不会,更别提任何适用于Web开发的编程语言了。我一直认为自己无法完全亲手写一个哪怕是最简单的动态网站,是作为互联网产品人员,很大的缺陷和耻辱。

工程师们一般倒不这么觉得,和他们聊天的时候,有时顺嘴喷一些对技术架构或某些技术问题的看法,立刻遭到赞扬:“你很懂技术嘛!”这时马上打着哈哈说:“懂个p啊,我连hello world都不会写,完全是纸上谈兵。”于是嬉笑声中,一群人把手里的箭收起来了。

但我压根儿就TM不想只能纸上谈兵,2009年,我不顾当时三十二岁的高龄,悍然决定要学Ruby,买了书、装好环境开始看书,敲代码,坚持了几天,然后失败了,考虑到也许Ruby对我来说太难,又尝试了Python,结果还是失败了。消沉几天后不死心,又买了一本iPhone开发的书,还趁机决定买了台27寸的iMac,但悲剧是只翻了翻书,连Xcode都没敢下就直接放弃了,这书上什么都不讲的啊!上来就是大段大段的代码啊!而且obj-c的代码都巨长,完全看不懂。

后来我想,这件事有两个收获:一. 发现了自己智商的边界。二. 我有了一台iMac。

转眼又过了一年多,想要自己动手做一个iPhone上的App的感觉越来越强烈,快压抑不住了。于是在某一天,我好了伤疤忘了疼似的把那本几乎没有折痕的iPhone开发基础教程又翻出来,等待Xcode下载的过程中,暗下决心:看不懂我也把它背下来。

后来发现笨办法至少对我来说,还挺管用的:照着书敲代码,能正常运行的话,就合上书,再敲一遍。一般重复四五次就能记得很牢了。合着书,劈里啪啦熟练的敲着自己还不知道是什么意思的代码,加上Xcode的自动补全很给力,几分钟就可以折腾出一大屏花花绿绿的代码,而且还能在iPhone上运行,这时会产生一种已经会写iPhone App的错觉,很奇妙。

人的大脑也很奇妙,你如果已经背下来了,本来不理解的就会慢慢自动理解,就这样背了一段又一段代码之后,突然发现:我明白是怎么回事儿了。之后就开始给自己提出各种小的不能再小的功能需求,尝试用这些代码去实现,每实现一个,都欣喜若狂:我能显示按钮了!我能弹出对话框了!我能写滚动列表了!我能发一条推送信息了!⋯⋯

这些事儿在熟练之后,也许就像喝口水一样平淡,但却能给初学者带来巨大的快乐,我一直觉得,能否始终保持如初学者般的热情、专注,决定了在做某件事时能走多远,能做多好。

由于书上所用的Xcode版本问题和我用的不同以及一些印刷错误,书上的代码不会总是百分之百能运行,有时会报错,只能上网用尽一切办法搜,搜索的过程中,就会慢慢看到一些专门的技术论坛、Blog,最终不可避免的会发现Stack Overflow这个神奇的网站,你遇到的大部分问题,都能在上面找到答案。

当实现书上的功能已经不能带来狂喜的时候,就会忍不住想把自己束缚了很久的各种idea放出来了,终于可以亲手去做它,而不是局限在画画原型图、写写需求说明最后还要虔诚的擦拭神灯,呼唤灯神们显灵这样隔靴搔痒的做产品。

开发的过程对我来说充满了乐趣,因为写代码的时候,世界变的简单而美好,某个做法对还是错,你不需要自己反复猜测,也不需要和任何人没完没了争辩,编译器就是神圣的裁判。你的每个操作都能得到及时、明确的反馈,而且拥有近乎奢侈的试错机会,从这个角度来看,编程的乐趣倒是有点儿象玩游戏。

当然也会遇到无数的问题,Stack Overflow、Github、Bitbucket、mailing list会慢慢成为你的朋友。

在能够独自写出一个iPhone App并把它放到App Store上之后,我又发现还需要再学一门语言,用来开发网站以及需要在App中调用的RESTful Web Service,于是不顾三十五岁的高龄,再一次悍然打起了Python的主意,有了学obj-c的经验,知道关键是要能狠得下心和静得下心来,看什么书,其实区别不是特别大,所以我就用了免费的Learn Python The Hard Way,用前面提到的方法,跟着做了一遍(前半部分比较简单,可以每天做上十几个exercise,后面速度可能会慢一点儿),了解了Python怎么写之后,马上开始看Django Book 2.0,只看到第九章,就等不及用同样的方法把Django Tutorial做了两遍,接着惊喜的发现已经可以写一个简单但完整的网站了。然后很快试着用Django写了一个特别小的针对某垂直领域的工具类网站,上线跑了一段时间,昨天晚上结束免费试用,开始收费,现在看到已有几个付费用户,我很欣慰。

至于技术需要懂到什么程度,我觉得要是花几个月学的东西就够用一辈子,这买卖也太划算了,尤其是在技术领域,一定会需要持续学习,但对于我来说,已经没有资格象十几二十岁的年轻人那样仅凭兴趣广泛的学,我目前对这件事的原则非常功利:马上要用到的,能显著提高效率或者公认是最佳实践的就学,否则就先不学,尽量不折腾、严格控制投入的时间和精力。

比如写好的代码放到Server上,虽然只要能跑就算是部署成功了,但公认的最佳实践是使用virtualenv隔离Python环境,这样可以减少以后很多的麻烦,那就值得多花时间去了解,去应用;使用Fabric配合Git进行自动化部署可以大大提高效率,那就也值得花时间去学怎么用。

我也知道可以用Memcached或Redis来做缓存,提高应用性能;或是用Rabbit Mq和Celery来做异步队列,可以改善同步执行耗时较久的任务给用户带来的不爽感;还有Node.js似乎比传统的Web开发语言更适合做RESTful API ⋯⋯ 不过这些都不是目前最紧迫的问题,所以虽然我还不会而且确定会有用,但先不去学。

一没留神,喷了几千字,还是打住吧,看来中年男人的啰嗦算是没救了。

最后还是总结一下,就一句啊:

产品经理懂技术 = 流氓会武术。你要是觉得帮派够大,自己脑子又好用到可以当师爷,那不会武术也凑合;要不巧是个和我一样没什么团队精神,又老喜欢独来独往的流氓,还想只凭着脑子就能连点儿防身术都不练,恐怕很容易被人打成爬行动物。

比较严肃的总结是:产品经理懂技术,在没资源的时候可以用最低成本把事儿办了,有资源的时候可以把资源用的更有效率。

---------- 广告

冷启动是我和几个朋友发起的产品经理培训项目,可能是你能找到的类似课程中,最务实的。

mp.weixin.qq.com/s? (二维码自动识别)

【pm懂技术,看这篇就够了!】

两年前我入门的时候看这个问题就很困扰,

这个问题下的答案也没啥干货,

我自己摸索了半年,

深感产品需要懂技术这点非常重要,

整理发出来和大家交流学习~

下面详细叙述下:


1.pm需要懂技术么?

要的,作为产品,懂技术可以和技术高效过需求,同时对自己产品/项目的把控度也更强。

举几个栗子:

1.不会因为不懂技术被嘲讽、被糊弄

我在做c端产品实习的时候,从来不管技术大哥如何实现,总是说:

-你怎么实现我不管,我就要这个~

-这个功能不就是xxx么,你直接说要多久把~

-这次的需求很简单,只要做xxx就行了,prd你看下哈~

搞得技术大哥很尴尬,而且在技术心中,这样的pm地位很低,你啥都不懂,还特么想给我提需求?我自己也很虚,经常是跪舔着求实现需求的状态,遇到case只能去找技术解决~

所以过需求的时候技术跟我说这个排期多久多久我就信了,导致有一次一个rd把我一个小需求拖了一个月,有时候直接跟我说这个需求做不了,我也就信了?

现在再也不会了,至少我会去追问“一个简单的分页为什么要做这么久?”

技术大哥会跟我解释:因为一页的数据来自不同的数据库的不同表,做分页就很麻烦~

那我觉得这样的解释ok啊,这时候说你排期吧才真的没毛病!


2.写需求更高效

你要知道你的产品的每一个块都要落数据库的,所以设计产品架构的时候模块化很重要,有哪些字段也很重要~

听过一句话,你的产品架构,其实也是技术架构!一定不能乱(乱耦合)!

所以在写需求的时候,一定要写清楚产品结构图,另一方面,知道别人怎么工作的,写需求才能按照他们的思路去写,比如:

前端要做哪些?字段、样式、交互(操作前、操作中、操作后)、边界条件(字数、图片尺寸等等)


3.过需求更高效

我来点评之后第一次过大需求,拉着前端、后端、qa开需求会,我从头到尾把需求说了一遍,自认说的很详细了,结果大家还是一头雾水,问题不断,于是我又按照自己的逻辑说了一遍,还是一堆问题。

这时候,我mentor打住我,让大家停一下,然后对着开发挨个说:

对前端说:我们这边新增了哪几个页面,ui设计稿什么样的,交互是什么样的...前端done!

对后段说:我们这次的产品大逻辑什么,新增了哪些字段,最重要和复杂的逻辑是哪些,可能要哪边的接口,那边的技术已经帮你找好了....后端done!

对qa说:这次的迭代和之前有什么不同,最重要的测试点是什么,有哪些风险要测下,回头上线的时候跟我说下我们一起看下...qa done!

最后强调了下项目的目标和重点,拉着大家过了下估时和排期,整个需求会done!

高效明了!!

所以啊,你要懂人家在做什么,才能跟人家进行有效沟通~


4.对自己产品/项目的把控度也更强

实习时候的一个项目的时候,从b端招商-录入系统-c端展示都是由不同的团队负责具体的某一块,只有我一个人知道整体的逻辑架构,当时出了一个case,目前的流程看似是无法走通的,但是其实如果了解底层是如何实现的,完全可以从技术角度去解决,这个case出现的时候我还请假在学校,打了几个电话就解决了,就很踏实很放心。

这个时候,我才意识到,作为产品owner意味着什么,意味着你特么是最了解整个产品所有细节的人!你要对整个产品负责!出了任何问题都会来找你!你是所有人的backup!你说你不懂技术不了解底层行么~



2.pm要懂哪些技术?


论技术,我只是个外行人,

自己结合工作中遇到的问题摸索了下,

了解到了一些皮毛,很多知识我都简单化了,

和大家分享下,给大家提供点学习的思路~

下面从按照:前端、后端、app端开发 三方面阐述


关于技术,你要先知道的是:

浏览器前呈现的内容基本是前端负责,浏览器后传过来的数据和逻辑大部分是后端负责

为了加深印象,你可以先看看这篇文章:你刚才在淘宝上买了一件东西 - dunnice - 博客园

看完了我们接着看~


2.1 前端

前端=html+css+js=>结构+字段+样式+交互

(我喜欢公式化拆解,这样是为了便于理解,并没有不尊重前端大哥们哈~)

对于前端的工作,了解以上问题,前端的大体工作基本就清楚了~


建议通过下面的渠道方法来进行学习:

a.w3school 在线教程

去看下html结构、标签和css的内容,看一点懂就好了,不要求会敲!

HTML 全局属性

HTML 事件属性

第二个链接中的表都快成为我交互checklist了~


b.chrome 开发者工具 :大杀器!直接让你看看人家前端的代码是怎么写的哈~

可以从这篇文章着手查看Chrome开发者工具不完全指南(一、基础功能篇) - 卖烧烤夫斯基 - 博客园

c.慕课网 你可能要去了解下 ajax、json这些东西

JavaScript教程-JavaScript入门视频教程-慕课网 先看这节课

Ajax全接触-慕课网 再看这节课

这两节课程非常短,一定要看完!!

看完之后,相信你对前端大哥的工作已经心中有数了~


d.其他

关于前后端如何进行数据传输:大部分是通过api接口的方式获取,所以你需要了解的有:利用「接口」做产品时我们该如何思考? | 人人都是产品经理

关于现在常用的h5:还请看下这篇答案:H5 是什么?


2.后端

其实后端大哥写代码,所用到的不同编程语言,函数,编码方式各有不同,我们完全不需要知道他们是如何实现的,业务层的逻辑我们只需要自己搞清楚就好了,只要你做到以下几点,基本和技术大哥没有隔阂:

1.需求目标想清楚,细节说清楚,原型画清楚,边界条件想清楚!

2.态度端庄,报以询问尊重的语气让技术大哥给你评估需求,并排期,千万不要说“不就是xxx么”

3.对需求负责,不要乱改需求,不要频繁改需求,改需求时态度好点并带上奶茶~


然后有空可以看看下面这个问题,不要提出一些傻逼嘻嘻的需求:

有哪些产品经理认为很简单,实则开发很难的技术?


a.从技术理解一个产品,大概可以分为5层:

  • 逻辑层——把产品需求翻译成逻辑
  • 实现层——具体的函数方法、写代码
  • 接口层——各模块交互的通道
  • 数据层——程序执行的结果
  • 架构层——技术的抽象、结构、调用关系、规范

此处参考@pm0238老哥的回答!

这里面,pm一定要负责的是逻辑层,你在设计需求的时候,要有【模块化】的概念,

说的简单点,就是每一个业务就是一个模块,那么底层的技术那边也是一个模块!

模块越清晰,每个模块之间不要耦合在一起,这样回头迭代起来就越方便,

不然就会出现,你觉得加一个小功能很简单,但对于底层但技术来说,完全就是两套技术架构~

此处借用网上的一张图,关于酒店业务的,每个业务都是一个模块,迭代起来非常方便


ok,那刚刚说的,如何如了解后端技术呢?其实也有个公式

程序=算法+数据结构

(我这样说只是帮助理解,rd大哥们真的不要打死我啊...)


b.算法

算法这边非常复杂,我的建议是,如果你不是专门的做算法方面的产品,

了解算法的逻辑就好,不要求知道怎么实现的,有些比较有趣的算法,比如

网易云音乐的歌单推荐算法是怎样的?

大家如何看《今日头条》的个性化推荐,如何实现的呢?

如何评价知乎的回答排序算法?

这些有趣的算法都可以了解下,对掌握技术都很有帮助的~


c.数据库

只需要会一种技能:sql

真的,从周边同行来看,感觉sql已经成为pm必备技能之一了,大家都在写sql

为什么呢?因为要关注数据!但是不可能一个小数据都要bi帮你写,所以只有自己写!

所以关键点在于 数据驱动产品的发展~


我曾经问过我的一个技术大哥,我怎样才能走进开发大哥的心

老哥抽着烟看了我一眼,说:你先把底层的数据库好好看看吧~

可谓是一语道破啊..


关于sql,只需要看一本书《sql必知必会》,链接见下

pan.baidu.com/share/lin


很多人看到group by 基本就放弃了,讲真,这本书不是让你单纯看的,平日里自己去写一写sql看看自己产品底层的表结构,神特么有意思好伐!而且写sql这种事情真的超有成就感!


3.app端开发

其实这块的只是我不是很熟悉,我自己因为做web端产品比较多,其他的产品也是在app上用h5页面做的,所以基本上很少接触,所这块大家有兴趣可以自己查看下哈,我能提供的就是说,注意下大家都会遇到的

1.不同系统的兼容性问题

2.不同版本的兼容性问题

3.不同屏幕尺寸的兼容性问题

4.android 和 ios 系统的规范(这个直接百度能查到很多~)

5.android 和 ios 打包发布流程


---------------------------------

最后说一些别的吧

1.产品懂技术,为了是提高沟通协作的效率,而不是为了流氓会武术,绝对不能报着学会了点技术皮毛,看你以后还敢不敢糊弄老子的心态,这样永远没法协作好~

2.提高效率最好方法是和rd大哥搞好关系,提需求改需求,认真负责,态度端庄,私下相处和睦~多技术都很有自己的想法,有时候一些老员工,他们对于业务的理解比我们还要深刻,多沟通,多交流,多学习,ok的~

3.关于技术知识,我提供的只是通用的很少很少的一部分,建议大家根据自己的产品或业务实际情况来学习,不要闷头去钻研如何写代码!技术大哥嘴里蹦出来不懂的技术名词还请百度去查看,一定要厚着脸皮把自己产品的底层逻辑问清楚了~

4.作为产品,需求靠不靠谱才是关键,懂点技术只是提升效率,如果你需求不靠谱,方向错了那么提高效率也只是加速了走向坟墓的时间罢了~所以大家不要钻到技术眼里去了,满奶子都是技术,有个leader曾跟我说:低头做事,抬头看天~共勉


以上,就是我这半年来摸索出来【产品经理懂技术】的一些感悟~

已同步到专栏,欢迎关注哈 猜花星の产品路

----------------------------------

胸弟,我写的有点辛苦,点个赞or关注下呗~

Ps : 收藏量是点赞的2倍,伤心了...

欢迎关注个人专栏,只写产品干货

zhuanlan.zhihu.com/caih