反駁一下,我覺得產品并不需要懂技術
從覺得技術重要,是我自己的短板,我要補上這張板,我支付了差不多三年多的業余時間。充其量,大家所說的技術實現的原理,花個一下午付費請個大牛來給自己科普下,就可以了。把時間花在那些真正重要的事情上。
上周,一個朋友找到我,說他決定了要轉行產品經理,打算去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不止一個號,有時候就開小號帶。
因為打的好,在游戲里又很浪,大家都覺得他特別牛逼,都開始親切的叫他『大佬』。
『大佬開黑嗎?』 『大佬求帶』
就這樣他非??斓内A得了技術同事的好感,研發同事們都非常喜歡他,經常喊他一塊開,周六日也是。
實習沒幾個月,一些基本的技術原理他就都搞得門清了,在推動研發在做事情的時候,收效也非常棒。
七
正是因為Y同學的出現,以及今年我自己對于產品思維的深度理解,讓我開始重新思考這個問題:
產品經理,到底要不要懂技術?
在回答這個問題之前,我們先來看看產品經理的核心競爭力是什么?
產品經理職業發展的三條線
這是我梳理一份產品經理職業發展的三條線:
技能線
人群:1~2 年的產品經理
核心競爭力:掌握產品經理工作的完整流程,并對每個環節有一定的實操,能產出出色的成果;
業務線
人群:3~4年的產品經理
核心競爭力:對于公司所從事的業務有深刻的理解,對于供給雙方的需求和服務有深入的認識,能夠從業務的場景出發進行產品設計;
商業線
人群:5~6年的產品經理
核心競爭力:構建出自己的產品思維,具備出色的判斷力,形成自己的商業分析邏輯,能夠幫公司賺錢(或具備這個意識),有獲取新用戶的意識;
這是我對于產品經理在不同工作時間段核心競爭力的理解。
貫穿了一個產品經理從業的第0~6年。
八
正是基于這樣的判斷和Y同學的事件,我再來看這個問題的時候,我充分的覺得:
產品經理不要去學習寫代碼,不要試圖掌握技術。
充其量,大家所說的技術實現的原理,花個一下午付費請個大牛來給自己科普下,就可以了。把時間花在那些真正重要的事情上。
那什么才是重要的事情呢?
提升產品經理核心競爭力的事情
在入行不同的時間段,有不同的側重點,有針對性的進行練習和提高,PM的核心競爭力,才是一個產品經理的立命之本。
那為什么絕大多數人會認為產品經理需要懂技術呢?包括我自己也花了三年的時間去親自coding呢?這里頭其實有幾個大神坑!
戰術勤奮掩蓋戰略懶惰
對于產品經理的核心競爭力是什么,沒有想清楚,哪些事情才是最應該花時間去努力提升的,沒想明白。
我一直認為產品經理是一個專業性很高的職業工種,從前期的需求挖掘和調研,產出和推進,到最后的迭代,整個過程中都有科學的方法論,每個人在踐行和理解的過程中都會有不一樣的感悟,找到自己適用的正確方法論,本身就是一件很花時間和精力的事情,做好這些事情,才是一個產品經理的最應該投入的事情。
而這個事,很容易在短期做到60分,所以很多人就開始慌了:這么容易掌握,一定沒有啥競爭力,那么什么是競爭力呢?日常打交道最多的就是研發,他們是互聯網最不能缺少的角色,也是其他人最不能干涉的領域,繼而認為互聯網最重要的是:技術。
這樣的理解,是缺乏思考的,因為一個研發從上大學四年,研究生2年,如果他在工作個三四年,基本上在這個技術這個領域做了十年了,你憑什么跟人家競爭呢?只能越學差距越大。
產品經理是『萬精油』
市面上很多人都會說,產品經理啥都懂一點,市場、設計、研發、測試、商務等,啥都懂,啥都不精,整天就知道跟大家打好關系,整個就是一個『萬精油』。
作為產品經理,我覺得別人可以這么說我們,因為他們不懂,亦或是我們做的還不夠好,可以這么被看輕,但是產品經理自己千萬不要這么想,因為人的精力非常有限,你是沒法把每個事情做好,那么就應該找到最重要的一件事情,全力以赴來提升,在成長的第一個階段,努力做專才,而不是全才。
木桶原理大家都聽過吧,如果把每一項技能都比作一塊木板的話,你是想把自己打造成:6個10CM短板組成的小木桶來盛水呢?還是1個60CM長板,再遇見同樣60CM高的人一起組成深水桶來盛水?
信任缺失
在這個問題的答案下,很多人觀點出奇的一致:懂技術可以更好的和技術溝通,以及工期的把握,這樣不至于被研發忽悠。
在我剛開始做產品經理的時候,這個毛病尤為的突出,因為不懂,因為一些看似簡單的東西,卻要花那么長的時間,不可思議,覺得里頭可能有水分。
其實在這件事情上,體現出來的,其實是信任的缺失,連隊友都不信任,怎么會被信任?
研發評估出來工期是多少,就是多少,要充分的信任研發經理。這是他們專業的領域,工期長短研發經理自然會自己把握,沒必要這么較真。
而為了去解決這個問題,學習寫代碼,大概是我覺得做上產品經理最神的坑,沒有之一。
這個時候,你大概明白了開頭的這位同學,我會怎么給他說吧:發揮自己的優勢,他的業務線,對金融的理解,對于風控的理解是他核心競爭力,努力發揮長處,再補齊產品經理技能線即可,不要去報班學JAVA。
產品經理不要去學習寫代碼,不要去試圖掌握技術。
不要讓學習技術占用了你原本追求更重要事情的時間,也不要讓技術限制了你的想象力。
好了,就寫這么多吧,如果你能看到這里,真的很感謝。
也希望你能點幾下左下角的『贊』,讓更多想做產品經理和已經在產品路上的小伙伴看到。
能夠多幫一位產品經理少走彎路,也算是我們對這個行業做了一點小貢獻。
感謝你 ^_^
作者:李三科,優信資深產品經理;同名微信公眾號:李三科
本文由 @李三科 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash ,基于 CC0 協議
感覺作者寫了這么多代碼,還是沒有掌握到技術的本質。技術的本質是為需求而服務,產品經理如果對每一個需求每一步的細節流程都理解的非常清楚,那么去寫代碼也是輕而易舉的事情(C語言、OC只是種實現你邏輯的工具而已),本質上寫代碼也是對自己需求邏輯的具體體現(技術說法:代碼邏輯)。同樣的這也解釋了為什么很多技術出身的大牛,做產品都非常牛逼,因為他們的邏輯能力、思考能力都非常牛逼。
那是因為他做成了,做掛的人非常之多,其實最重要的是還是判斷力,選擇了一個可以做起來的產品
我還報考了計算機本科,年后就要報名了。真的很幸運能看到這篇文章,差一點點就入坑了,感謝!
你高三?
不是的,是自考
比較認同前輩的“方法論”觀點,我在實習后對此很有感觸。PM需要成為“T”字型的人才,知識體系要廣泛,但關鍵在于崗位深度即核心競爭力,顯然技術不是那一豎里面的。成長階段時間寶貴,廣度和深度的優先級排期也不容忽視。
對,先深挖,然后再商業,要不然就本末倒置了
真的特別感謝你這樣的分享
入職半年的產品小妹
有一顆成長為大牛的心
你的分享就是我成長過程的重要養分
感謝,能夠幫到你,我也很開心~~
懂技術和會技術,完全是兩個概念。
這個標題,也是是編輯后來加的,原標題是:產品經理到底要不要懂技術
作者說的這個要圈?。赫覀€技術大佬花費半天時間 知道下實現原理就行了。
前端:展示與輸入數據;
后端:處理數據;
數據庫:存儲數據。
用戶在前端查看展示的數據(展示的數據是從數據庫拉取過來的),在某些情況下去會輸入數據,后端接收到前端傳遞過來的數據之后,對其進行處理,處理之后存儲到數據庫,并且把數據返回給前端,展示給用戶查看。
很多人不理解數據庫是什么東西:數據庫其實就是一個抽屜,可以向里面存東西,也可以從里面取東西。
從我開發的角度出發,其實產品經理懂不懂技術也不是特別重要,但是千萬別搞“這個需求很簡單,怎么實現我不管——明天上線”這種找死的事就好
寫的挺不錯的,但是大廠的產品都是技術轉的,懂技術轉型產品的就是大于不懂的。這是事實。 應該是最好要懂 但是不需要去寫,
你說這都不是事,一個做了7年技術的產品經理飄過。
我現在就是處于這樣的茫然期,前段時間還特意去學前端,打代碼。后來發現自己真的沒有毅力,但是被研發們看著我像智障的表情,又讓我很不爽。
??
又懂技術,又懂業務,又懂產品。
專門注冊了個賬號來回復這篇。
樓主想說的是產品經理應該更多的把注意力集中在提高自己的核心競爭力上,但用的表述“產品并不需要懂技術”容易誤導新入行的同學。
如果做的不是技術導向的產品,一般說產品經理要懂技術,多是指產品經理要有一些技術常識,才能更好的做產品設計。打個比方:好的產品應該知道客戶端和服務端都是干什么的;客戶端是要發版本才能更新的;網絡請求是要耗時的而且可能會失敗的等等。這些東西會很大程度上影響到產品設計。
另外,如果真的感興趣想學點技術,樓主的學習方法確實有問題,各位不要效仿。
可能有誤解,我已修改,我的觀點是:產品經理不要去寫代碼,不應該試圖去掌握技術,具體內容已在在乎有更新了。
關鍵點應該在于 需要懂多少技術?
產品經理是做創造的,需要一定基礎去支持這個非常贊同,但是考慮補充自身知識體系中的優先級,技術應該向后放。
私以為,知道各種技術方案可以解決什么問題即可,這樣在產品設計時,有較多的可選項。
?? 受教了~特別是分析為什么會陷入想學技術的誤區里,原本計劃里是有學技術這一項的,現在可以重新考慮了
是??!千萬別入坑,還是想想怎么提升自己的核心競爭力!
寫的很好,真的是經驗心得,第一次為文章打賞,感謝作者。
感謝感謝??!
理論上當然沒問題。但是,實際上許多公司是很貪心的,他們希望自己雇傭的PM不僅是合用的PM,在某些時候甚至可以當半個碼農用,這就使得許多公司招聘PM時就會發生變形,優先考慮有敲代碼背景的PM。
黑盒測試做了八年了。最初得日子也努力學習過代碼知識,為的就是想弄明白bug是怎么產生的,哪些是程序員偷懶造成的,怎么更好的噴死他們。后來發現,再怎么惡補都是浪費時間。再后來,越來越多的參與用戶體驗和產品設計相關的工作內容。其實已經是半個產品經理了。我發現,你只要多花點時間去弄明白開發文檔是什么內容就夠了。剩下的時間,多去研究用戶需求,界面和交互設計更有價值。
還有更重要的事情,等著PM來做呢
產品經理是個門檻不是很高,但上限極高的工種,發展到什么高度,就看自己的努力,當然也包括一定的天分和運氣,所以專注于提升自己的專業能力,提煉核心競爭力,發揮出自己的不可替代性,這樣才會產生足夠的價值
很喜歡你的核心競爭力。的確,做自己最擅長的東西,但是也要了解最基本的理論,用發展的目光去看待產品,也看待自己。
找到自己的核心競爭力,非常關鍵
受教了,本來以為是標題黨,看著看著發現都講到了點子上,解答了長期以來的困惑。一個是對于技術的理解,之前也熱衷于學習技術一段時間,后來忙忙忙不了了之,現在想來基本的邏輯能夠想通,自己的設計沒有邏輯漏洞,對于技術同事來講就已經夠了;另一個是核心競爭力,一直覺得自己的知識庫非常匱乏,但是不知道要學習什么,沒有系統的體系概念,網上的教程大部分都是理論、方法論,文章也都是原型、PRD,方法論必然要有,但沒法直接產生收益,原型PRD也必會,但是會做就夠了,研究地再精也不能直接當做前端來用,所以學習的重點還是要在業務、商業上。
早醒悟,早出坑,把時間浪費在那些真正有意義的事情上
只能說不需要深入了解和親自寫代碼吧,但是基礎知識還是掌握一點的比較好,最起碼寫文檔畫原型的時候不會出各種搞笑的錯誤
你這屬于走火入魔了,其實懂寫基本原理就好
受教了
寫的真好!道出了很多2、3歲產品的迷茫和痛點。我個人觀點是:產品經理懂點技術,研發在講解的時候不會一頭霧水,但不要舍本逐末,將大部分時間放在技術學習上,學會了也不會讓你碼代碼,因為你是個產品經理!
對的!
全部看完,我最感興趣的地方在文章第四部分,您與一位投資人的談話,還想聽聽更多的
歡迎來我公眾號留言提問
公司不同需要的角色也不同,沒有絕對。
一年半產品仔細閱讀后,很受教。最后的水桶效應很形象