反驳一下,我觉得产品并不需要懂技术

李三科
57 评论 27196 浏览 122 收藏 27 分钟
B端产品经理要负责对目标行业和市场进行深入的分析和调研,了解客户的需求、痛点、期望和行为,找到产品的价值主张 🔗

从觉得技术重要,是我自己的短板,我要补上这张板,我支付了差不多三年多的业余时间。充其量,大家所说的技术实现的原理,花个一下午付费请个大牛来给自己科普下,就可以了。把时间花在那些真正重要的事情上。

上周,一个朋友找到我,说他决定了要转行产品经理,打算去XX机构报个Java培训班,我问他为什么?他说大家都说:做产品经理要懂技术,自己对于这块是零基础,只有去报个班学下,先把这板补齐,再去找工作的话,会好一些。

在结束跟他的聊天后,我陷入了深深的思考:产品经理到底要不要懂技术?

我决定来回答下这个问题:

翻了下自己2013年5月4日,在新浪博客写的一篇文章 :

今天把家里书桌上所有跟技术相关的书收起来了,持续了近半年多的技术学习告一段落,下一个阶段,重点放在产品&运营。

和很多北漂的IT年轻人一样,处在这个急速发展的行业,使你不得不努力朝前走。要补的东西很多,我一直觉得人一个阶段,最好全力去做一件事。就这样,除了必要的业余时间占用外,所有的业余时间全部交给了C语言,Objective-C,就这样一遍看不懂,看两遍。一遍一遍的照着书上码。不懂就问,好在身边做技术的哥们人很多,翻看下C语言文件夹,自己写的草稿累计竟有快一百个,算算快有一万行代码了。

所有的这些,都是因为,我想做一名优秀的产品经理,而技术是我的短板。

虽然大二我就开始买了人生的第一个域名,自己独立搭建了第一个独立的discuz社区,那个时候就开始接触空间,FTP之类的,但却依旧没有考过计算机二级,计算机公共课因为补考才考过。只因为那个时候,自己确实没想明白,学好C有啥用处。而在没开始学习写代码之前,虽然经常跟技术一起吃饭,做产品需要的技术知识不成问题,在范而广和专而深的十字路口,我选择专而深,在对我来说,做产品最后的一块处女地,我一路摸爬滚打的闯进来。

最开心的事情,莫过于:看着自己写好的非常弱智的小游戏,被朋友们玩着,还有几个小的APP。这些让我惊喜不已。

诚然,我还只是一个技术菜鸟,但是这段写码的日子,确实受益很大,写代码真的很痛苦,枯燥,异常的枯燥,最早用基于windows的tubor C 2.0,写的想死的心都有了,后来朋友介绍说用visual,再后来才找到基于Mac的Xcode上也可以写C,不同的编辑器,写的速度真心不一样,但依旧很枯燥。这让我对于做技术,写代码的哥们更加的尊敬。

现在有时候写文档,做原型的时候,脑子里都会想着这个需要怎么实现,这个逻辑是怎么样的,用if.else.还是用do.等如何实现,深刻体会到全局变量,局部变量的逻辑框架。相信这样要为技术省很多工。

经常会看到很多人争论产品经理要不要懂技术,我的观点是:我喜欢那些出身不是技术背景,但是做了产品之后,开始补充技术知识的产品经理。

倒不是说我是这样的履历,之所以这么说,是因为,产品经理最重要的几个决定要素,其中沟通能力,能够把各个方面的人搞定,让事情Run起来,这个是我最看重的一点。什么工具啊之类的,我觉得这是最不重要的能力。而一个技术背景的人,恰恰在沟通能力上会有很大的不足。

OK,东扯西扯,扯了很多,就是想说,做产品的同行朋友们,有时间多写写代码吧。

这几个月里,看到了很多有趣的产品,有意思的事情,一直因为要写代码,忍着没有跟大家分享,接下来,欢迎大家光顾,一起多多商讨!

2012年初,我从运营转成产品经理,在一家做招聘相关的互联网公司,做一款客单价99块钱的PC自助在线招聘产品。好在对接的研发工程师是工作了五年多,每次我写完文档后,都会提前发给他,找他聊聊看哪些地方还需要修改,他都会给出一些建议,很多建议都很中肯,都集中在逻辑,极值有没有考虑到等,根据他的建议,我一般修改完之后,才会再跟大家进行评审。

忘了是在讨论什么事情,那天他对我说:算了,不跟你说了,反正说了你也不懂,有给你解释的时间,我都快把这个做完了,你到时候看效果就行了。

一直以来,我都觉得他是一位非常Nice的工程师,但这件事情,让以往由于不懂技术,在合作中被Diss的糟糕经历被放大,作为这个项目的产品经理,我不喜欢这种无法掌控整件事情的感觉。

也正是由于这件事情,让『技术很重要,我要掌握它』的这个萌生了好久的想法被付诸实践。

在决定要学习技术之后,我询问了好几个同事,他们建议我不要学习JAVA、PHP之类的,建议我先从C语言开始,因为C语言是最基础的,很多语言都是基于C做的扩展。

而他们一致的建议是:最好的学习,就是敲代码。

就这样,我花了很多时间在网络上找答案,搞定编译器,找到练习的教材。

写程序使用的编辑器

没错,就是在这样的蓝屏上,一个字母一个字母的照着书本来敲代码。然后运行下,看效果。

当打出第一句『 Hello world 』时,我的喜悦至今还记得:这是我写的代码耶!

后来还陆陆续续的写过一些更大的小功能。

学习写代码实在是枯燥的不行,好在我的英语还可以,经常出现卡壳,运行不下去,不能出现书里说的结果的时候,就很尴尬,在网上找不到答案的时候,就会问一些做技术的朋友。

也是在那个时候,知道到了一些程序员经常去的网站,有国内还有国外的。

下载很多技术类的视频课程和讲义,也知道了程序员界的大牛都有哪些人,还有兴线下单约了两次最著名的程序员,酷壳博客的博主陈浩老师;

在那往后的很长一段时间里,我所有的业余时间都交给了写代码。

后来移动互联网越来越火,我自己很沉迷iPhone 4,我意识到可能是一个非常大的机会,就很想转去做移动端的产品经理,也是在网络上看了很多人说,做移动互联网产品经理,需要懂技术,需要懂开发苹果App的开发语言。

后来了解到是在苹果自带的编辑器Xcode上用Objective-C来写的,那个时候,我还没有苹果电脑,据说可以在window电脑上装个镜像,但需要电脑配置比较高才可以。折腾了好久,发现我自己3000块的Acer笔记本,完全没法搞。

下决心去买个苹果电脑,去了两次苹果三里屯的线下店,找了三个朋友,借到了一万多块钱,买了个Mac Pro,还买了一本当时很畅销的书《iOS 5应用开发入门经典》,图中左下这本:

还有几本技术书送人了…

这本书,其实好难,上来就讲怎么去做一个简单的App,一些语法啥的,都还不太清楚。

有一个技术大牛,建议我还是先把C语言学会了,再去学Objective-C,这样会简单很多,要不然会非常吃力的。遂给我推荐了《21天学通C语言》,说这是他见过最简单,最有效果的入门书籍。

我一想21天就能搞定,这个投入性价比超高啊,再有大牛加持,立刻就下单了。

嗯,你可能很好奇,为啥是两本呢,又为啥都拆开了呢?

这本书太厚了,加上Mac笔记本好沉,北京的地铁你懂的,一本放家里,一本在路上或公司看。

工具书太难懂了,又厚,学起来特别有压力,拆了之后,看起来薄一些,很轻也方便携带,这样很快就能学完,压力自然也会没有那么大。

就这样,我开始了《21天学通C语言》的学习,在Mac上的Xcode(Mac上自带的一种编辑器)里头写C语言,感觉流畅了好多,一边看书一边对着电脑敲代码。

对照着抄完一遍,运行没问题后,就再来一遍又一遍,直至合上书,也能自己敲完,运行无误。

认真的做笔记

这本书一天就是一章,课程的设计也是循序渐进的,前面几章节都还挺简单,后面难度逐步增加,要做的练习也越来越难,直到我看到第九章『指针』,实在有些太难了,去网上找了很多解释,搞了两个多星期,还是没搞明白。

可能我自己的学习方法不对,或者之前的练习还不够彻底;索性,我就又从第一章开始学习,认真学习理论知识,一遍又一遍的演练课程中的代码,到了第九章,还是不行,理解不了。又搞了一个多星期,还是不行。

中间我休息了一周多,我跟自己说,再试一次吧,再认真点,作者写的这本书应足够简单了,可能是自己努力的方法不太对。

就这样,我重新开始第三次尝试,这一次,我基本上可以盲打每个章节预留的代码练习题,很少出错,一些逻辑语法之类的,基本上不会有啥明显错误。

可还是不行,卡在了『指针』这章。

刚好那段时间,公司业务有调整,得花更多时间和精力在工作上,在公司研发工程师的帮助下,我写的两款猜数字的小游戏,装在我的iPhone手机上了,时不时拿出来自己玩一玩,还是蛮有成就感的。我觉得技术的学习之路,可以放一放了。

也就有了你在开头看到的那篇文章。

但『自己的技术能力,还比较差,还需要继续提升』这样的念头,还一直在。

后来有幸跟一位非常牛逼的投资人,他所在的机构你经常会在一些科技媒体上看到,而他就是这个机构的管理合伙人。

那次聊天,对我启发非常大,我也做了一些记录,这篇写于2013年5月18日:

这一周过的很有意义。有几件很有意义的事情:

1 自己负责的产品IOSV1.3版本通过审核,可以下载了!

当然安卓用户是我们的主流用户,安卓开发也增配了一员新兵,又可以加快上线的步伐了!让自己周末的加班显得更有价值。

2 时隔半年多,再一次跟这位牛逼的行业前辈吃饭,席间一席话给了我很多启发:

问:你现在业余时间都在干嘛?

我:看技术相关的书籍。之前iOS平台搞明白了一些,现在看Java,学习安卓相关的内容。

问:你五年后打算写代码?

我:不会写。

问:那你的这些积累算什么?

我:为了更好的做产品。想做的优秀,技术目前是我的短板。

问:你五年后还在做产品?

我:….

(沉思中)应该会吧,但那个时候应该不会还在一线做产品吧?…..

(其实这个时候有些茫然了…)

问:那你其实应该想想,你现在所做的这些能够为未来的你服务多少?积累多少?十年后在做什么呢?

我:…..(是啊,心里嘀咕着….)

问:有一个思维叫资产累积,也就是说一个人的资产分为有形资产和无形资产。当然所指各不形同,人和人的差别就在于无形资产的积累:

1-而有些人的无形资产是可以累积的,会逐年增加,深挖可沉淀;

2-有些人是刻意去经营,这和没有这样意识的人一两年差别不大,但是假以时日,三五年之后,差异就会很大,而那个时候意识到就已经晚了;

3-没有利益(商业价值-或者可商业化的)驱使的兴趣爱好不长久。

所以你要好好想想,不要东啄西啄一下,不断倒腾新的东西,可能会对你有帮助,比较泛,但是相比哪些三五年专注一个事情上的人来说,你其实是两手空空。不是吗?大凡可以累加持续去做,纵向深入专注最后的无形资产会非常巨大。

而你要想想,你目前业余时间所得事情,是不是对你来说回报最大的?同样的时间投入,是产出比最大的么?

后来他据此还跟我讲了十年前他的一些例子,以及举了一些他身边发生的真实案例。

其实这几天,我一直在思考跟他的这一席语重心长的话:

1. 诚然,我以后不会去写代码,不可能在写代码上跟人拼谁写的好。

2. 我该怎么样去积累自己的无形资产呢?

3. 我的业余时间,我是想做点自己兴趣爱好的事情,那么怎么才能高效的积累起来呢?做点什么呢?

虽然后面没有像之前那么拼的学技术了,但是只要有时间,我还是会打开编辑器,练习下写代码。

终于我从Mac Pro换到了Air,轻多了;编辑器也终于不用在笨重的Xcode上写了,换成了简洁的Sublime;也不用看书了,w3school 在线教程,简单极了。

从觉得技术重要,是我自己的短板,我要补上这张板,我支付了差不多三年多的业余时间。

在这期间,我也一直坚持的认为:做产品经理,是要懂技术的。

2017年3月份,我招了一位应届实习生(以下简称“Y”),学的是化工类的专业,Y跟我说他们班毕业的同学都去了中石油、中石化,他就是不喜欢这样的工作,想试试互联网。

当时我跟他说,我比较担心你不懂技术,这个可能会影响你的工作,有时间多看看技术相关的入门书籍。

在Y开始做产品的时候,我挺担心他因为没有技术方面的知识,写的文档逻辑容易出问题,以及被研发怼,所以每次他写完的文档,我都会仔细的过一遍,把有问题的部分一一进行标注。

他有一个习惯特别好,就是不动就直接问我:比如什么是API,什么是埋点,原理是啥,什么是后端,什么是字符串……

后来随着时间的推移,公司的研发同事经常中午或晚上空了,就过来找他,干嘛呢:

打王者荣耀!

没错,就是打王者荣耀,因为Y同学早早的就是王者了,他们就想让Y带他们升级,Y不止一个号,有时候就开小号带。

因为打的好,在游戏里又很浪,大家都觉得他特别牛逼,都开始亲切的叫他『大佬』。

『大佬开黑吗?』 『大佬求带』

就这样他非常快的赢得了技术同事的好感,研发同事们都非常喜欢他,经常喊他一块开,周六日也是。

实习没几个月,一些基本的技术原理他就都搞得门清了,在推动研发在做事情的时候,收效也非常棒。

正是因为Y同学的出现,以及今年我自己对于产品思维的深度理解,让我开始重新思考这个问题:

产品经理,到底要不要懂技术?

在回答这个问题之前,我们先来看看产品经理的核心竞争力是什么?

产品经理职业发展的三条线

这是我梳理一份产品经理职业发展的三条线:

技能线

人群:1~2 年的产品经理

核心竞争力:掌握产品经理工作的完整流程,并对每个环节有一定的实操,能产出出色的成果;

业务线

人群:3~4年的产品经理

核心竞争力:对于公司所从事的业务有深刻的理解,对于供给双方的需求和服务有深入的认识,能够从业务的场景出发进行产品设计;

商业线

人群:5~6年的产品经理

核心竞争力:构建出自己的产品思维,具备出色的判断力,形成自己的商业分析逻辑,能够帮公司赚钱(或具备这个意识),有获取新用户的意识;

这是我对于产品经理在不同工作时间段核心竞争力的理解。

贯穿了一个产品经理从业的第0~6年。

正是基于这样的判断和Y同学的事件,我再来看这个问题的时候,我充分的觉得:

产品经理不要去学习写代码,不要试图掌握技术。

充其量,大家所说的技术实现的原理,花个一下午付费请个大牛来给自己科普下,就可以了。把时间花在那些真正重要的事情上。

那什么才是重要的事情呢?

提升产品经理核心竞争力的事情

在入行不同的时间段,有不同的侧重点,有针对性的进行练习和提高,PM的核心竞争力,才是一个产品经理的立命之本。

那为什么绝大多数人会认为产品经理需要懂技术呢?包括我自己也花了三年的时间去亲自coding呢?这里头其实有几个大神坑!

战术勤奋掩盖战略懒惰

对于产品经理的核心竞争力是什么,没有想清楚,哪些事情才是最应该花时间去努力提升的,没想明白。

我一直认为产品经理是一个专业性很高的职业工种,从前期的需求挖掘和调研,产出和推进,到最后的迭代,整个过程中都有科学的方法论,每个人在践行和理解的过程中都会有不一样的感悟,找到自己适用的正确方法论,本身就是一件很花时间和精力的事情,做好这些事情,才是一个产品经理的最应该投入的事情。

而这个事,很容易在短期做到60分,所以很多人就开始慌了:这么容易掌握,一定没有啥竞争力,那么什么是竞争力呢?日常打交道最多的就是研发,他们是互联网最不能缺少的角色,也是其他人最不能干涉的领域,继而认为互联网最重要的是:技术。

这样的理解,是缺乏思考的,因为一个研发从上大学四年,研究生2年,如果他在工作个三四年,基本上在这个技术这个领域做了十年了,你凭什么跟人家竞争呢?只能越学差距越大。

产品经理是『万精油』

市面上很多人都会说,产品经理啥都懂一点,市场、设计、研发、测试、商务等,啥都懂,啥都不精,整天就知道跟大家打好关系,整个就是一个『万精油』。

作为产品经理,我觉得别人可以这么说我们,因为他们不懂,亦或是我们做的还不够好,可以这么被看轻,但是产品经理自己千万不要这么想,因为人的精力非常有限,你是没法把每个事情做好,那么就应该找到最重要的一件事情,全力以赴来提升,在成长的第一个阶段,努力做专才,而不是全才。

木桶原理大家都听过吧,如果把每一项技能都比作一块木板的话,你是想把自己打造成:6个10CM短板组成的小木桶来盛水呢?还是1个60CM长板,再遇见同样60CM高的人一起组成深水桶来盛水?

信任缺失

在这个问题的答案下,很多人观点出奇的一致:懂技术可以更好的和技术沟通,以及工期的把握,这样不至于被研发忽悠。

在我刚开始做产品经理的时候,这个毛病尤为的突出,因为不懂,因为一些看似简单的东西,却要花那么长的时间,不可思议,觉得里头可能有水分。

其实在这件事情上,体现出来的,其实是信任的缺失,连队友都不信任,怎么会被信任?

研发评估出来工期是多少,就是多少,要充分的信任研发经理。这是他们专业的领域,工期长短研发经理自然会自己把握,没必要这么较真。

而为了去解决这个问题,学习写代码,大概是我觉得做上产品经理最神的坑,没有之一。

这个时候,你大概明白了开头的这位同学,我会怎么给他说吧:发挥自己的优势,他的业务线,对金融的理解,对于风控的理解是他核心竞争力,努力发挥长处,再补齐产品经理技能线即可,不要去报班学JAVA。

产品经理不要去学习写代码,不要去试图掌握技术。
不要让学习技术占用了你原本追求更重要事情的时间,也不要让技术限制了你的想象力。

好了,就写这么多吧,如果你能看到这里,真的很感谢。

也希望你能点几下左下角的『赞』,让更多想做产品经理和已经在产品路上的小伙伴看到。

能够多帮一位产品经理少走弯路,也算是我们对这个行业做了一点小贡献。

感谢你 ^_^

 

作者:李三科,优信资深产品经理;同名微信公众号:李三科

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

题图来自 Unsplash ,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 感觉作者写了这么多代码,还是没有掌握到技术的本质。技术的本质是为需求而服务,产品经理如果对每一个需求每一步的细节流程都理解的非常清楚,那么去写代码也是轻而易举的事情(C语言、OC只是种实现你逻辑的工具而已),本质上写代码也是对自己需求逻辑的具体体现(技术说法:代码逻辑)。同样的这也解释了为什么很多技术出身的大牛,做产品都非常牛逼,因为他们的逻辑能力、思考能力都非常牛逼。

    来自广东 回复
    1. 那是因为他做成了,做挂的人非常之多,其实最重要的是还是判断力,选择了一个可以做起来的产品

      来自四川 回复
  2. 我还报考了计算机本科,年后就要报名了。真的很幸运能看到这篇文章,差一点点就入坑了,感谢!

    回复
    1. 你高三?

      来自四川 回复
    2. 不是的,是自考

      回复
  3. 比较认同前辈的“方法论”观点,我在实习后对此很有感触。PM需要成为“T”字型的人才,知识体系要广泛,但关键在于岗位深度即核心竞争力,显然技术不是那一竖里面的。成长阶段时间宝贵,广度和深度的优先级排期也不容忽视。

    来自河南 回复
    1. 对,先深挖,然后再商业,要不然就本末倒置了

      来自四川 回复
  4. 真的特别感谢你这样的分享
    入职半年的产品小妹
    有一颗成长为大牛的心
    你的分享就是我成长过程的重要养分

    回复
    1. 感谢,能够帮到你,我也很开心~~

      来自四川 回复
  5. 懂技术和会技术,完全是两个概念。

    来自山东 回复
  6. 这个标题,也是是编辑后来加的,原标题是:产品经理到底要不要懂技术

    回复
  7. 作者说的这个要圈住:找个技术大佬花费半天时间 知道下实现原理就行了。

    前端:展示与输入数据;
    后端:处理数据;
    数据库:存储数据。
    用户在前端查看展示的数据(展示的数据是从数据库拉取过来的),在某些情况下去会输入数据,后端接收到前端传递过来的数据之后,对其进行处理,处理之后存储到数据库,并且把数据返回给前端,展示给用户查看。
    很多人不理解数据库是什么东西:数据库其实就是一个抽屉,可以向里面存东西,也可以从里面取东西。

    来自河南 回复
  8. 从我开发的角度出发,其实产品经理懂不懂技术也不是特别重要,但是千万别搞“这个需求很简单,怎么实现我不管——明天上线”这种找死的事就好

    来自广东 回复
  9. 写的挺不错的,但是大厂的产品都是技术转的,懂技术转型产品的就是大于不懂的。这是事实。 应该是最好要懂 但是不需要去写,

    来自广东 回复
  10. 你说这都不是事,一个做了7年技术的产品经理飘过。

    来自广东 回复
  11. 我现在就是处于这样的茫然期,前段时间还特意去学前端,打代码。后来发现自己真的没有毅力,但是被研发们看着我像智障的表情,又让我很不爽。

    来自福建 回复
  12. 😉

    来自广东 回复
  13. 又懂技术,又懂业务,又懂产品。

    回复
  14. 专门注册了个账号来回复这篇。

    楼主想说的是产品经理应该更多的把注意力集中在提高自己的核心竞争力上,但用的表述“产品并不需要懂技术”容易误导新入行的同学。

    如果做的不是技术导向的产品,一般说产品经理要懂技术,多是指产品经理要有一些技术常识,才能更好的做产品设计。打个比方:好的产品应该知道客户端和服务端都是干什么的;客户端是要发版本才能更新的;网络请求是要耗时的而且可能会失败的等等。这些东西会很大程度上影响到产品设计。

    另外,如果真的感兴趣想学点技术,楼主的学习方法确实有问题,各位不要效仿。

    回复
    1. 可能有误解,我已修改,我的观点是:产品经理不要去写代码,不应该试图去掌握技术,具体内容已在在乎有更新了。

      回复
  15. 关键点应该在于 需要懂多少技术?
    产品经理是做创造的,需要一定基础去支持这个非常赞同,但是考虑补充自身知识体系中的优先级,技术应该向后放。

    回复
  16. 私以为,知道各种技术方案可以解决什么问题即可,这样在产品设计时,有较多的可选项。

    来自广东 回复
  17. 😳 受教了~特别是分析为什么会陷入想学技术的误区里,原本计划里是有学技术这一项的,现在可以重新考虑了

    来自广东 回复
    1. 是啊!千万别入坑,还是想想怎么提升自己的核心竞争力!

      来自北京 回复
  18. 写的很好,真的是经验心得,第一次为文章打赏,感谢作者。

    来自山东 回复
    1. 感谢感谢!!

      来自北京 回复
  19. 理论上当然没问题。但是,实际上许多公司是很贪心的,他们希望自己雇佣的PM不仅是合用的PM,在某些时候甚至可以当半个码农用,这就使得许多公司招聘PM时就会发生变形,优先考虑有敲代码背景的PM。

    来自北京 回复
  20. 黑盒测试做了八年了。最初得日子也努力学习过代码知识,为的就是想弄明白bug是怎么产生的,哪些是程序员偷懒造成的,怎么更好的喷死他们。后来发现,再怎么恶补都是浪费时间。再后来,越来越多的参与用户体验和产品设计相关的工作内容。其实已经是半个产品经理了。我发现,你只要多花点时间去弄明白开发文档是什么内容就够了。剩下的时间,多去研究用户需求,界面和交互设计更有价值。

    来自上海 回复
    1. 还有更重要的事情,等着PM来做呢

      来自北京 回复
  21. 产品经理是个门槛不是很高,但上限极高的工种,发展到什么高度,就看自己的努力,当然也包括一定的天分和运气,所以专注于提升自己的专业能力,提炼核心竞争力,发挥出自己的不可替代性,这样才会产生足够的价值

    来自北京 回复
  22. 很喜欢你的核心竞争力。的确,做自己最擅长的东西,但是也要了解最基本的理论,用发展的目光去看待产品,也看待自己。

    来自广东 回复
    1. 找到自己的核心竞争力,非常关键

      来自北京 回复
  23. 受教了,本来以为是标题党,看着看着发现都讲到了点子上,解答了长期以来的困惑。一个是对于技术的理解,之前也热衷于学习技术一段时间,后来忙忙忙不了了之,现在想来基本的逻辑能够想通,自己的设计没有逻辑漏洞,对于技术同事来讲就已经够了;另一个是核心竞争力,一直觉得自己的知识库非常匮乏,但是不知道要学习什么,没有系统的体系概念,网上的教程大部分都是理论、方法论,文章也都是原型、PRD,方法论必然要有,但没法直接产生收益,原型PRD也必会,但是会做就够了,研究地再精也不能直接当做前端来用,所以学习的重点还是要在业务、商业上。

    来自浙江 回复
    1. 早醒悟,早出坑,把时间浪费在那些真正有意义的事情上

      来自北京 回复
  24. 只能说不需要深入了解和亲自写代码吧,但是基础知识还是掌握一点的比较好,最起码写文档画原型的时候不会出各种搞笑的错误

    来自广东 回复
  25. 你这属于走火入魔了,其实懂写基本原理就好

    来自江苏 回复
  26. 受教了

    来自广西 回复
  27. 写的真好!道出了很多2、3岁产品的迷茫和痛点。我个人观点是:产品经理懂点技术,研发在讲解的时候不会一头雾水,但不要舍本逐末,将大部分时间放在技术学习上,学会了也不会让你码代码,因为你是个产品经理!

    来自福建 回复
    1. 对的!

      来自北京 回复
  28. 全部看完,我最感兴趣的地方在文章第四部分,您与一位投资人的谈话,还想听听更多的

    来自陕西 回复
    1. 欢迎来我公众号留言提问

      来自四川 回复
  29. 公司不同需要的角色也不同,没有绝对。

    来自浙江 回复
  30. 一年半产品仔细阅读后,很受教。最后的水桶效应很形象

    来自上海 回复
专题
17124人已学习12篇文章
如何搞懂财务和业务之间的关系,并推进业务系统财务模块的建设呢?本专题的文章分享了财务系统的设计指南。
专题
37190人已学习27篇文章
作为AIGC的代表性应用之一,ChatGPT仅仅只用了2个月的时间就已经突破了1亿用户。
专题
13915人已学习13篇文章
本专题的文章分享了关于教育+AI的思考。
专题
13787人已学习11篇文章
生活中,难免会接到企业的一些外呼电话,无论是人工外呼还是AI外呼,其背后的外呼业务场景是什么?外呼系统包含哪些内容?本专题的文章分享了外呼系统的设计指南。
专题
19143人已学习13篇文章
本专题的文章分享了社区运营的正确姿势。
专题
13426人已学习14篇文章
好的产品是对人性的窥视,无论是做产品,做运营,懂点心理学还是很有帮助的。本专题的文章分享了消费者心理学。