互聯網產品經理需要懂得哪些技術?
雖然平常工作中不涉及產品開發,但是很多工作都是和技術進行對接! 如果是移動APP和WEB網站的產品經理分別需要學習和了解哪些技術?要掌握到什麼程度?
有些人真是我跟你講歷史你跟我講意義,我跟你講意義你跟我講發展,我跟你講發展你跟我講歷史。什麼都是你有理。
移動 APP:
iOS:
1. 了解 Objective-C 是一種什麼性質的語言(動態靜態語言的區別)。2. 了解什麼叫 SDK、封裝。3. 了解什麼是 MVC 結構模型。4. 了解在純技術上前端和後端如何區分。5. 了解什麼是 API。6. 了解後端常用的語言及其優缺點(Java、NodeJS、PHP等)7. 了解常用的資料庫類型及其優缺點(MySQL、MongoDB、SQLite 等)8. 看得懂每年的 WWDC。9. 知道如何通過翻閱 iOS Developer Guides 來確定自己想實現的功能在 iOS 上是否有基礎技術支持。10. 會用英語關鍵詞通過 Google、Github、StackOverflow 來查找遇到 bug 或想實現功能的可行性,甚至直接找到對應庫。
11. 與開發合作兩個版本後可以根據他的開發效率預估工程量和排期。Android:
與 iOS 類似。網站:
1. 了解 HTML、CSS、JS 都是幹啥的。2. 了解基本的 Box 模型概念。3. 了解 DOM 概念。4. 了解同步/非同步的概念。5. 了解前端常用的框架和庫,比如 Bootstrap、Angular、Backbone、jQuery、Vue.js,並知道它們各自的優缺點和適用環境。
6. 了解移動環境和 PC 環境的區別對前端開發的影響。7. 了解 HTML5 相對於 HTML4.01 多出來的特性分別是什麼,並試圖想像應用場景。項目:
1. 了解什麼叫「構建」、「集成」。2. 知道 SVN 和 Git 的使用是為了解決什麼問題。3. 試著通過實踐學會使用 git,甚至了解 git-flow。4. 了解常見的持續集成工具。5. 了解發布流程。差不多先這些。
這麼說吧,上面這些內容我平時跟程序員聊天時候經常討論,但他們不相信我(畢業後)沒寫過代碼。
@四海飄渺 的評論讓我看到電腦前一個淚流滿面的程序員哈哈哈哈哈哈哈,正好藉機會說一下吧:
程序員都是很實誠、很講邏輯的人,所以你的邏輯思維能力一定要夠強,這樣你就完全沒必要了解技術細節了。所謂邏輯思維能力夠強舉幾個例子:
1. 不光做產品,你一定要自己畫交互圖,我是指流程性的交互圖,這樣可以驗證你自己畫的頁面和流程是不是走得通、有缺失。這是結構上的邏輯思維能力。2. 涉及到每一個「數據」和「操作」,一定要想清楚各種邊界條件。比如一個購物車界面,畫完一個一堆商品的購物車界面就完了?你得想全面沒有商品的時候什麼模樣?購物車有沒有商品數量上限?沒網路拉不出來數據怎麼提示?等等等這些都要想全面,這是細節上的邏輯思維能力。其他的先不說了。干過3年研發,比如懂些java、php、css、js之類的開發。干過3年業務,比如銷售、客服、運營之類的。
然後做產品,基本上是合格的獨立人格的產品經理。
技術總是在變,想跟上技術的變化,對一位產品經理來說,很難。
產品種類繁多,不同產品,甚至是產品的不同細節都可能有數十種解決方案,產品經理難以深入到每一個細節。我見過兩類比較極端的產品經理,一類是技術轉型過來的,一類是百分百技術小白。
1、
技術轉型過來的產品經理,很多時候,開發人員會特別無語,因為很多技術方案莫名其妙地就被產品經理給拍好了,你需要花費大量的時間跟他解釋,他給出的技術方案,怎麼怎麼不合理,現有的技術條件不能支持,或者有更好的技術方案云云。這類「特別懂」技術的產品經理,學會沉默,對開發人員來講是一種解脫。2、
也有剛入行的技術小白產品經理,他們很痴迷於自己的產品,對產品細節可能不是特別挑剔,十分注重長期規劃,對技術人員也充滿了敬畏之心,每個技術細節都跟開發確認,並且時常用懇求的目光凝視著開發。這種產品經理經常被「欺負」。如果你之前對技術一無所知,並且對技術本身沒太多興趣,我相信即便是走進去了解也學不到多少。這個時候,掌握技術並不是重點,而應該:
- 與你的技術同學保持溝通,及時反饋問題,不要隨便確定技術方案
- 讓技術同學了解到你的產品核心價值,盡量不要讓開發砍你這部分的需求
- 交流中,讓技術同學避免使用技術專業辭彙,而是讓他們使用流程圖、演示圖等方式表達他們的思路(技術方案)
- 每次技術評審,仔細聆聽,了解技術做不了什麼,做得了什麼
產品經理懂得相應技術會帶來適當的好處。1、懂得基本的技術術語,會讓溝通無障礙。在研發大大們甩專業名詞的時候,你也可以輕鬆get到其中的點。如api介面,如何獲取數據是推過去還是你去查詢,例如數據表的基本布局。這些東西不需要你專業系統的學習,平時遇到的時候,一定要了解清楚,作為基本的技術儲備即可。2、了解技術難點,可以避免後續的坑,在研發同學之前建立你的信用。基本點例如每秒可能涉及到的查詢次數,對應的伺服器壓力。例如產品後續可能擴展的需求,需要前期預先安排。
這樣的話,可避免研發的重複工作,提前布局,合理而高效。
雖然目前市面上很多公司希望招聘到有研發背景的pm,但是就產品思維於研發思維差異很大。從業多年的研發如需轉產品可能需要一年的時間來轉化思維。行文至此,也該中庸一下,其實 PM 懂技術,也未必是必須的,比如我個人內心的技術小人就會把這三種情況排除在外。
1. 這位 PM 有著非常成功的產品經驗
技術流雖然驕傲,但也有著崇尚權威的謙卑。如果你有著非常輝煌的歷史,即使你對技術一竅不通,但憑藉著「PM 將再一次帶領大家走向產品成功」的信念也足以令 RD 們信服。不過能夠做到這種程度的 PM,不懂技術的應該是鳳毛麟角吧。
2. 這位 PM 有著非常敏銳的產品直覺
如位 PM 有著非常敏銳的產品直覺,尤其對新技術可能帶來的產品革新有著靈敏的感知的話也是被排除在外的。好的 sense 是能令其他人都跟著拍手叫好的,RD 再頑固,也是能夠嗅到方向的,所以也會願意跟著你的直覺走。不過,sense 這種東西,有時候跟天賦一樣可遇而不可求。
3. 這位 PM 有著很強大的邏輯思維能力。
技術流都是邏輯控,如果你的設計出現了邏輯上漏洞或者問題,將會讓 RD 們無比鄙夷,如果已經令 RD 們做了很多無用功,那更可能招致怨念。正是因為 RD 們對邏輯的執著與看重,PM 的邏輯思維能力就更加成為了一個巨大的考驗。另外學習技術其實可以鍛煉人的邏輯能力。當然,懂技術到邏輯強大,這不是充要條件。
說了這麼多,倒也不是要標榜懂技術的種種好處,其實技術有時候反而會給設計思維帶來限制。例如,PM 看產品可能首先考慮的是產品定位,而 RD 看產品首先想到的是功能。個人以前就很喜歡拿功能攢產品,做出來的東西基本不能稱之為產品。這也許就是前面所說的思維模式上的差別。PM 的思維模式其實是很寶貴的,所以學習技術,還需慎重。
總而言之,PM 應該是懂些技術的,或許不需要懂到技術的細枝末節,但至少要有常識,再次也要對技術表現出尊重和熱情。只有這樣才有可能成為一個優秀的產品經理。
推拿按摩術頸椎病調養術情緒調控術
心裡健康輔助術
謝邀!如果純論技術的話,每家公司每個產品都不同,但是思維是一定得懂的,即:
1、要知道你所運營產品的優勢(可能是一方面,也可能是幾方面的結合);
2、要找到你這些運營的產品的功能怎麼組合,才能形成你自己的差異化競爭優勢;(很
有可能你都不知道你的競爭對手是誰,吸引「用戶注意力」是關鍵)
3、你的用戶是哪些人,你準備給他們提供什麼樣的服務;
4、你的用戶在哪,你如何讓他們相信和信任你;(現在碎片化這麼厲害)
5、如何讓你的用戶為你買單,你的盈利模式是什麼?
產品調研、需求分析評估、產品設計、開發測試跟進以及缺陷跟蹤,產品經理在日常工作當中,的確需要花很大一部分時間和程序猿密切深入互動(撕逼)。
然而開發環節只是產品生命周期內的一部分而已。PM並不需要明白具體技術的實現過程,只需要懂背後的原理,能夠同開發順暢溝通即可。如果真的細緻到同開發通論具體技術實現的方法,你確定開發大哥不會角色你指手畫腳亂BB嗎?
畢竟PM還要留著精力,和運營撕、和市場撕、和UI撕,得雨露均沾啊!
更重要的是把握產品發展的方向!
更重要的是把握產品發展的方向!更重要的是把握產品發展的方向!重要的話說三遍!需要懂得自己可以不懂得什麼
需要懂得自己必須要懂得什麼不建議太懂技術,一般來說懂的技術越多,做產品的時候就越容易放過那些本來可以爭取到的事情,越是明白技術的優缺點的局限性,就越容易陷入細節。
一來容易和程序員較真撕起來,二來其實產品經理更應該對產品大方向負責,你更應該考慮的是這個功能做不做、什麼時候做、做到什麼程度、對目前產品和公司戰略的好壞,而不是這個交互那個提醒怎麼出現。
細節的問題,建議讓交互設計師去和開發對,如果沒有交互,那就和開發建立起信任關係,對常規問題一筆帶過,對於業務特性的功能做一下滲透,靈活把握吧。感覺應該要基本了解下開發技術,不求精,只求了解,不然規划出的需求都是實現不了或者實現了沒什麼太大效果得不償失的那種,即延誤工期也造成損失,還折磨開發人員....另外腦袋裡大概有個產品1/2/3/4代的大概演變趨勢,以及出現問題及時調整產品走向的保險策略...總的來說就是不要瞎提無理需求就好...瞎嗶嗶的,不喜輕噴~
不必要懂!
1、先把產品的真正想清楚!!!!!!!
2、懂點技術無非指點江山有優越感,反而容易瞎指揮。
3、不懂技術一樣可以和開發很好溝通,前提是做好1,且多溝通。
4、開發能做什麼不能做什麼,其實還是你要做好1。
本人產品我是一顆小白菜,小丫小白菜。某個月黑風高的晚上一道靈光划過我的天靈蓋。對!我的目標是做一個專業的產品經理。然而我並非科班出身。那我可以先從助理開始學吧(學習能力自認為不錯),然而,這個行業怎麼就這麼難呢?怎麼就這麼難呢?咋就這麼難哪就是想吐槽一下
我個人覺得產品經理最重要的是邏輯能力和溝通能力。
邏輯能力,你能整清楚這個功能是如何實現的,實現了以後有什麼價值,用戶吐槽的原因是什麼,如何能將這些變成優化產品的產品功能。沒有優秀的邏輯能力,這些內容一團糟,無從做起。
而理順了這些事情,最重要的就是有人幫你實現了,因為產品經理既不能寫代碼,也不能畫視覺稿,還不能快速的搞定渠道,也無法承擔品牌的專業工作,等等,其他的就不說了。那這個時候溝通能力就顯得十分重要了。首先,你要能把事情說清楚,圖文視頻等其他手段都可以,當然也能包括肢體語言,只要能把事情說清楚,你就成了一般了。其次,你能讓剛說到的其他工種按照你的預設幫你完成你的計劃,可是,這些小夥伴都是有獨立思想的,有個人情感的,有自己喜好的寶寶啊,寶寶高興了才能幫你完美做呀,沒有好的溝通能力,你會發現自己寸步難行,根本完成不了呢。
以上就是我覺得產品經理最重要的兩個軟實力指標。
所謂的技術,我認為假以時日都可以學會。但是基本的軟體要會的,我一般都用百度腦圖畫思維導圖,用exture畫交互圖,用word寫需求,用excel整數據,哈哈,還要會PPT,樓主你應該都會吧?
不要假裝或者以為自己懂技術就行了
產品經理作為CEO接班人,是很多程序員在規劃自己未來的職業路徑時會考慮的一個方向。不過,如果你喜歡穩定的生活,產品經理可能不適合你。產品經理雖然叫做」經理」, 但你做的大部分事都是為了幫助實現他人的功能。成功了,是團隊的成功。失敗了,是你的判斷不準。
聽起來這麼苦逼,為什麼要做?
曾有3年程序員經驗,後在Salesforce內部成功轉型產品經理的Annabelle說:「比起和電腦打交道,我更喜歡和人打交道。我希望創造自己的東西,解決『what problem to solve』。想要更加貼近產品與用戶,而不是天天對著電腦,聽別人要求我實現什麼。」
如果你也有這種想法,那麼一定不能錯過這篇文章。
產品經理整天都在幹嘛?
簡明扼要地說,基本是以下內容:
給用戶打電話。
開會。
寫文檔,記錄。
發郵件。
救火!
這裡還要理解兩個概念:Outbound PM和Inbound PM。
我們通常理解的產品經理,更偏向Inbound PM,負責團隊內部做出一個好產品。Outbound PM更多的面向用戶,將產品推向市場。
程序員轉型產品經理的挑戰
如果你希望找一個work-life balance的工作,那麼產品經理並不適合你。也許「經理」聽起來非常洋氣,但是這個職位絕不輕鬆。
產品經理承擔著重大的責任,你對產品方向的判斷會決定這個產品的成功與否。你應該去考慮該解決什麼問題,而不是如何解決問題。
與此同時,你的隊友們並不直接向你彙報,甚至他們的職位還要比你高。這就對產品經理的軟實力有著很高的要求。你要如何建立自己的信用度,能夠說服大家朝著一個方向努力?怎麼激勵工程師和設計師,交付這個產品?
B2B領域裡的產品經理還要面臨一些特殊的挑戰。
- B2B的產品比較複雜。作為產品經理,不僅要了解產品本身,更要了解常見的客戶需求,行業標準,技術協議,使用場景等等。所以成為B2B產品經理的門檻更高,學習曲線更長更深。
- B2B跟客戶的接觸,不論是文字上,還是語言上,都需要十分專業。要知道什麼能講,什麼不能講。在不能滿足用戶需求,或者產品有問題的時候,要知道怎樣說不。
程序員型產品經理的優劣勢
作為程序員,代碼的能力肯定已經夠了,不會被程序員一句「無法實現」就忽悠了。而且從程序員轉型的產品經理在和程序員溝通時,可以更好地表達自己的需要,對於實現代碼的時間線也有更好地預估,更好地把握產品整體的時間安排。
然而程序員轉型產品經理也有自己的劣勢。商業方面,包括商業模式,運營,市場等各方面,都是程序員的弱項,以及對用戶的不了解,會讓程序員在轉型初期經歷一段艱難期。這就需要自己多多學習和積累,多聽多問,和公司的各個部門多多溝通。
Annabelle轉型產品經理的經歷
我一進入Salesforce就和所有人說,我是要轉型到產品經理的。當然確實也可能會有一些阻礙,比如經理可能會覺得你無法安心完成本職工作,或是做產品經理的能力不足。
針對前一點,這就要考察你的嘴上功夫了!和經理表達出你的轉型是公司的需要,同時符合你的個人興趣,而且自己寫代碼的能力可以在這個職位上發揮更大的作用。
在將自己的本職工作完成後,你也要找一些項目來證明實力,我當時就去上了產品經理的培訓班。或是你也可以找一些工作中的side projects,從產品角度思考,證明你有產品經理的思維與能力。
雖然是內部轉型,但是也並不比外部轉型容易。Salesforce內部轉型一共進行過7輪面試,包括technical,behavior,等等。
產品經理需要哪些逆天「裝備」?
每天都要和不同的人打交道,產品經理首先要配備的「裝備」當然是溝通能力!
以下「裝備」還可以讓你更加酷炫狂霸拽,比如,行業知識,專業背景,UX,銷售/市場,以及數據分析。這幾種「裝備」不需要每種都有,有2-3種就已經具備了成為產品經理的基本素質了。
而想要獲取逆天「裝備」,你需要大量的學習和積累。同時不要忘了向公司證明你的實力喲!
溝通能力
- 如何學習
o 爭當主持人,鍛煉自己做演講與展示的能力。
o 學習即興表演,許多出色的產品經理都去學過表演課,可以更加到位地表達自己並且感染他人。
o 參加寫作課,培養準確的用詞,表達精確的需求。
o 多聽其他產品經理的表述,除了聽他們說出來的,更重要的聽他們沒有說出來的。
- 如何證明自己
o 去行業媒體投稿,或者把資料可以放到自己的LinkedIn、知乎、微博上。
o 寫自己的博客、公眾號文章、頭條號文章,可以分享自己作為產品經理的思考。去面試的時候,拿出對他們產品的分析,對方可能會覺得你對他們產品的了解比他自己還多。
行業知識
- 如何學習
o 研究行業經典產品。
o 參加行業大會,或者小型分享會也是不錯的選擇。
o 主動尋找機會和業內專家溝通交流,他們有著多年的行業經驗,和他們講話會收穫很多書本上學不到的東西。
- 如何證明自己
o 加入LinkedIn、豆瓣相關的小組,微博、知乎相關的話題,在上面參與討論,發表有思考,有建設性的見解。
o 在Twitter、微博上成為大V的粉絲,關注他們的動態,同時也是不錯的談資。
技術背景
- 如何學習
o 購買相關專業書籍。
o 報名在線課程或線下培訓班。
- 如何證明自己
o 做side project。
o 將代碼發到git repo上,建立自己專業的GitHub profile。
噴運營,踹技術,拍糊老闆,甩鍋。
需要有商業意識(賺錢)需要有畫餅意識(激勵)需要懂人心(用戶)有這些我覺得就夠了~技術、工具都僅僅是輔助,思想才是自己的
業務,業務,業務,用戶,用戶,用戶!
PM(產品經理)VS RD(研發工程師)
常聽業內人士說起,產品經理(PM) 和 研發工程師(RD) 之間是很喜歡互相掐架的(知乎上的討論),對個人而言感同身受,因為自己內心的技術小人和產品小人也是常常互相掐架的,感覺更像是一種是思維模式上的互掐。當然這並不代表這兩種思維模式是相互對立的,好的產品顯然不是掐出來的。PM 和 RD 之間需要的是一種建立在尊重和理解上的有效溝通。不過鋪磚壘石的樸實研發工程師們還是比較傾向於被動的,所以我的建議是,產品經理主動去了解技術。
為何 PM 要懂技術?
不得不說,技術人員是很傲嬌的。PM 雖然並不是凌駕於 RD 之上的角色,但遵照著 PM 的設計來進行實現多多少少會讓 RD 生出低人一等的感覺(不乏 PM 本身也是這麼認為的),這可能是讓驕傲的技術流不爽的地方。所以 RD 不待見 PM 可以說是自然而然,如果 PM 還不懂技術,那麼 RD 就更加可以在自己的長處上放心大膽地鄙視 PM 了。這倒也不是 RD 的小人得志,幾年的技術經驗會讓他們覺得這更像是一種自我保護,保護自己引以為豪的知識領域不被非專業人員指手畫腳。所以如果 PM 懂技術的話,是會在一定程度上贏得 RD 的尊重的。這麼說似乎有點繞,說白了就是,如果我是 RD,我會更尊重懂技術的 PM。
與被「指點」的設計師不同的是研發很難被「指點」
懂技術解決的不僅僅是心理層面的問題,事實上,這會讓 PM 和 RD 之間更容易交流。我們常常覺得 RD 出於對技術的自負而難以溝通,如果 RD 開始甩術語、甩原理,那麼多耗費一些時間和耐心也還是能夠理解的,有時候,更可怕的就是 PM 會覺得自己和 RD 的對話完全發生在兩個次元里。其實 RD 們在這樣交流的時候,並不是在企圖彰顯技術的 NB,這似乎更多的是一種習慣,是技術流長期和技術流交流所養成的習慣。所以,PM 懂技術,可以更好地去理解和適應這種習慣,至少也可以讓自己不被 RD 們忽悠了,PM 如果被 RD 繞得雲里霧裡,無法反駁、無力判斷,那也是一件很可怕的事情。
另外懂些技術可以把 PM 從高屋建瓴拉到腳踏實地。很多時候 RD 會消極配合 PM,很有可能是 PM 的設計在技術可行性上出現了問題或製造了麻煩。於是在 RD 看來,PM 就是天馬行空不負責任的 YY,卻把落實的各種不靠譜問題都拋給了他們。就好像建築師不可能對土木工程毫無了解,PM 有時候也需要在技術層面上了解一磚一瓦是如何落實的,才能讓設計變得踏實。
PM 也許可以不懂技術?
行文至此,也該中庸一下,其實 PM 懂技術,也未必是必須的,比如我個人內心的技術小人就會把這三種情況排除在外。
1. 這位 PM 有著非常成功的產品經驗
技術流雖然驕傲,但也有著崇尚權威的謙卑。如果你有著非常輝煌的歷史,即使你對技術一竅不通,但憑藉著「PM 將再一次帶領大家走向產品成功」的信念也足以令 RD 們信服。不過能夠做到這種程度的 PM,不懂技術的應該是鳳毛麟角吧。
2. 這位 PM 有著非常敏銳的產品直覺
如位 PM 有著非常敏銳的產品直覺,尤其對新技術可能帶來的產品革新有著靈敏的感知的話也是被排除在外的。好的 sense 是能令其他人都跟著拍手叫好的,RD 再頑固,也是能夠嗅到方向的,所以也會願意跟著你的直覺走。不過,sense 這種東西,有時候跟天賦一樣可遇而不可求。
3. 這位 PM 有著很強大的邏輯思維能力。
技術流都是邏輯控,如果你的設計出現了邏輯上漏洞或者問題,將會讓 RD 們無比鄙夷,如果已經令 RD 們做了很多無用功,那更可能招致怨念。正是因為 RD 們對邏輯的執著與看重,PM 的邏輯思維能力就更加成為了一個巨大的考驗。另外學習技術其實可以鍛煉人的邏輯能力。當然,懂技術到邏輯強大,這不是充要條件。
小結
說了這麼多,倒也不是要標榜懂技術的種種好處,其實技術有時候反而會給設計思維帶來限制。例如,PM 看產品可能首先考慮的是產品定位,而 RD 看產品首先想到的是功能。個人以前就很喜歡拿功能攢產品,做出來的東西基本不能稱之為產品。這也許就是前面所說的思維模式上的差別。PM 的思維模式其實是很寶貴的,所以學習技術,還需慎重。
總而言之,PM 應該是懂些技術的,或許不需要懂到技術的細枝末節,但至少要有常識,再次也要對技術表現出尊重和熱情。只有這樣才有可能成為一個優秀的產品經理。
作為一個產品經理 專業知識我們就不在這裡研究了 這樣的大咖很多我想在這裡聊聊 磁場的問題一個產品經理 需要一個與公司決策層同樣的磁場空間 一個與市場部門同樣的磁場空間一個與用戶同樣的磁場空間古人云 一日三省吾身 不妨模仿一下 每天晚上放空自己 感覺一下自己的空間感提醒一些重點產品經理千萬別把自己認為的客戶需求而看作需求產品經理得實際的讓公司活著
推薦閱讀:
※為什麼 iOS 和原生 Android 沒有文件管理的概念?
※GitHub 上都有哪些值得關注學習的 Android項目?
※如何看待「谷歌醞釀將蘋果 Swift 作為安卓 APP 主要開發語言」?
※如何評價不久之前發布的xposed for Android N?
※自學Android未找到工作,現在的就業形勢下該如何選擇?