一個人不是說你能夠有產品構思，能夠畫點原型，能夠做團隊和專案管理就是產品經理。

蘇傑原來有本書叫《人人都是產品經理》，看了後大家可能會覺得做一個產品經理是挺容易的一件事情，但是自網際網路提供和設定了大量的產品經理崗位後，產品經理這個詞基本就爛大街了。

我們如何來界定一個產品經理，如果簡單點來講可以理解為根據自己長期的專案和運營實踐，透過自己的敏捷洞悉能力和分析能力，能夠將當前的市場需求或潛在的市場需求轉化為具體的產品需求，並能夠核心的定義產品功能模型和價值輸出，同時能夠透過專案和 團隊管理的能力，凝聚一個小組形成一個真正的團隊，將自己的產品構思付諸於最終產品實現的人。

在這裡我們還沒有講到運營，如果再講到運營的話可以理解為透過他人或運營團隊的運營，能夠進一步的收集和分析使用者需求和行為特徵，同時對產品進行持續改進，這個要求可能就更高，但是最基本的是你首先要做到第一點。

一個產品經理如果最終不能主導團隊完成一個產品的交付不能算產品經理，其次如果一個產品經理最終交付的產品沒有得到市場的認可或實現最終的價值也不能算一 個產品經理。

產品經理的核心價值就在於搞清楚市場究竟需要什麼？根據市場的需求如果構建一個產品並完成價值交付？產品經理我們一直強調要做正確的事，這個 就是正確的事。如果產品經理和專案經理有獨立的職位的話，那麼產品經理要保證的是最終的產品能夠實現客戶價值，專案經理要保證的是按照專案或版本計劃完成 專案目標。

如果從這個層面來說的話，產品經理需要具備兩方面的核心能力。

其一就是根據市場規劃出有價值和意義的產品的能力，產品本身的功能架構究竟如何，產品能夠完 成哪些客戶需求和價值交付，產品如何分版本迭代的推出和上線。

其二就是能夠真正指導和跟蹤管控產品孵化和落地的能力，產品如何研發，產品本身的技術架構或 非功能性需求如何滿足，這些雖然可以藉助核心架構師的能力，但是產品經理必須有相應的技術背景和管控和指導產品落地而不是中途夭折。

很可惜的是，網際網路產品經理逐漸成為一個偽命題，不管是做需求，做UI或是說做架構，做專案管理的都可以稱為產品經理。導致我們對產品經理這個概念的認知 越來越模糊，但是哪裡清楚一個真正合格的產品經理需要包括技術背景，實踐經驗積累，市場和運營，專案管理，軟技能，軟體工程等多方面的知識融合。

雖然類似 原來像中興和華為的產品經理本身有更多和跟嚴格的崗位職責定義，我們也會感覺這些過程相對來說很重，不符合網際網路團隊的敏捷和快速迭代文化。但是為學日 益，為道日損，沒有真正經歷過繁重過程的磨練，我們是很難真正清楚如何去繁從簡。

你有一個產品構思或者說別人給了你一個產品構思，但是如果你能夠將產品構思真正細化，理清楚產品核心模型和價值交付點，最終全程主導和跟蹤將產品做出來並 推向市場實現價值，那麼你可以算一個合格的產品經理。有創意和想法的人太多，但是能夠真正將想法喜歡為產品需求的人少，同時又能夠將產品需求最終實現為產 品的人更少。網上說的就差程式設計師了為何經常被黑，很簡單，這些人除了忽悠到的投資人的錢和一些燒錢的想法外啥都沒有，他們根本就不清楚一個產品構思到真正 落地之間所需經理的複雜和歷練。

產品經理是能夠真正賦予產品靈魂的人，是能夠真正將一群人構建為一個核心產品團隊的人，是一個能夠真正實現產品價值的人。 只有他的高度領袖能力和全身心的投入才可能真正將產品從0到1孵化出來，他可能沒有做太多具體事務性的工作，但是卻會出現在產品打造全過程中的任何關鍵 點。他們會參加需求調研和分析，總體產品設計，架構方案，產品測試和驗證，市場推廣和運營等任何關鍵點和關鍵環節。他們做的所有活動和跟蹤唯一目標就是讓 產品能夠真正根據自己的構思和想法孵化出來，而不是在這個過程中不斷的偏離軌道而沒有修正。

產品經理是光彩奪目的，他們得到團隊的擁護，客戶的認可和產品帶來的價值回報，能夠透過自己和整個團隊的努力打造一款真正創造價值的產品所帶來的成就感和 自我實現無任何其它可以替代。

但是產品經理本身又是孤獨的，產品經理是真正負責產品成敗的唯一責任人，你的任何一個不夠慎重的決策都可能將產品引入歧途或 最終夭折，資源的投入，產品的延期，客戶的不買賬，大量的深夜對產品的思索和煎熬，對工作和家庭的無法平衡，這些都需要你一個人去默默承受，偉大是熬出來 的，你的每一點心血都最終融入到產品氣質中。

本文致所有在產品經理路上和那些正在為成為一個合格產品經理努力和奮鬥的人。

可以做的，

目前很多崗位有自己的職責要求，所以細分領域很多。這一塊建議你去各大招聘網站上找一些主流的企業招聘內容看一下。

程式設計師做產品經理的優勢是更懂技術，雖然一直都說產品經理不用懂技術，但是懂的話更利於自身發展和團隊溝通，這點見仁見智。

資料產品經理是個年輕的職業，是伴隨大資料技術的成熟而誕生的。

資料產品經理的職責是圍繞資料構建解決方案，從獲取資料的埋點到資料治理，從資料提取到資料視覺化，從數字營銷到廣告，從搜尋到千人千面的推薦，從風控到規劃，從預測到AI。

對於上述每一個數據領域，資料產品經理都需要花費一定的時間深耕才能掌握，再結合對相關業務的深刻理解，才能讓資料發揮最大的價值。

我認為資料產品經理應該具備兩大常常被忽略但非常重要的技能：時間管理能力和專案管理能力，並且介紹一款幫助資料產品工作的神器-維格表。

維格表可以應用在專案管理、團隊資料協作、電商管理、內容管理、門店統籌、產品研發管理等數千個場景，也可以把它充當支援API的輕量級資料庫，一鍵匯入各種Excel，使用API連線其它系統。你可以把它理解成是一種Access資料庫和Excel表格的結合體。

下面介紹下維格表怎樣幫助資料產品經理建立時間管理意識和專案管理意識

時間管理能力

大多數時候，其實資料產品經理的日常就是上述各種事情混在一起，而且還要再加上許多突發事件，如果沒有好好管理自己的時間和優先順序，不只很容易忘東忘西，也很容易給周遭的夥伴帶來困擾。

所以推薦各位資料產品經理使用維格表對工作優先順序做劃分，用彩虹標籤對每項工作分組“緊急重要”“緊急不重要”“不緊急不重要”“不緊急但重要”

每次收到資料、開完會、想到事情資料產品經理都可以建一張維格表放在團隊的空間站，這有助於資料產品經理重新審視每件小事的優先順序，才不會下意識就優先處理最簡單的。

專案管理能力

資料產品經理的一個重要角色是專案經理，需要對整個專案的結果負責，包括按時交付，合格交付，成本控制等，但它又不需要像傳統軟體行業的專案經理那樣，做到熟練專案的5大過程組和10大工作領域。

使用維格表做專案管理不必擔心上面的問題，因為維格表有專門為產品經理製作的專案管理模板，包括產品研發管理，專案任務協作等等，能滿足大部分資料產品經理日常工作的需求，在官網模板中心就能找到。

維格表，為有品位的資料蟾皮經理打造的神兵利器，瀏覽器輸入http://VIKA.CN即可使用哦

程式設計師的優勢：

1.得天獨厚的技術能力

雖然我常跟很多人說產品經理入行，是不需要懂技術的。在之前的文章中，我也做了詳細的說明，但很多公司會要求有計算機專業背景優先。尤其是在一些特定的行業，懂技術的背景的人，更受歡迎，比如目前比較火的“人工智慧”領域，很多公司就要求產品經理要懂技術，甚至會寫一些簡單的演算法才行；

在“人工智慧產品經理”的這個點上，程式設計師轉產品經理就直接秒了90%的其他轉行的非技術競爭者；

而技術轉產品經理經理，基本上補足了中高階產品經理一直在努力補齊的技術短板，這對於很多中高階PM來說，做專案管理，如果不知道這個專案的開發難度，那麼工期的評估就很難完成；

2.優秀的文件撰寫能力

我們先來看看實際工作中，很多由程式設計師發現的產品經理寫文件的”七宗罪“：

a、文件寫了幾十頁，一個邏輯寫的羅裡吧嗦，研發測試都沒耐心看了；

b、邏輯遺漏嚴重，值從哪裡取搞不清楚；

c、頁面極值沒考慮清楚，導致影響美感；

d、文件都少頁面；跳轉頁、分享頁包括文案配圖、404頁等；

e、頁面的互動狀態變化沒寫清楚；

g、文案寫的過長，一屏放不下，要這行，設計師不幹了；

....

讓程式設計師來吐槽他遇到的產品經理的話，可能這一篇啥都不用寫了，這槽可得半天吐；

這確實是一個比較常見的現象，為什麼很多人老黑產品經理，文件寫的不夠全面和嚴禁，確實是很多產品經理經常出現的一個問題，這個問題不僅僅出現在出入職場的初級PM，甚至很多中高階PM也會遇到這個問題。

不瞞你說，我以前也經常出現這樣的問題，畢竟這個文件主要是讓開發去看的，而除非有靠譜的老大嚴把關的話，初入行的產品經理確實會常常出現這樣的問題。有段時間這個問題也讓我非常苦惱，特別是在我後來開始學習C和Html的時候（其實證明那段沒有章法的學習是個大神坑），發現寫文件的很多東西，直接一個“if ... else...” 就可以解決了，原來可能需要寫一大段的文字說明，這一下就省去了好多行；也明白了程式設計師經常使用會使用”引用“，比如文件裡頭的某個部分跟之前的一樣，這次就沒有必要再寫一次，直接引用之前寫過的某段說明即可。節省了很多研發的時間。

這也是為什麼有一些公司會喜歡寫過程式碼的產品經理的原因，說白了就是：這樣的程式設計師，不會坑程式設計師；相對容易獲得團隊的支援，對於專案的順利推進，大有幫助。

3.專案管理能力

我認識的由程式設計師轉成產品經理的人，在產品經理的路上，由於精通專案的關鍵的推動瓶頸：技術工期；繼而在產品經理的路上的進階要比其他行業的快很多。因為在中高階產品經理這個環節，比拼的就是專案管理和高效推動其他人的能力；

而在專案裡，負責實現的程式設計師工作，直接決定了整個團隊專案的進度；

懂技術，對於掌握整個專案大有裨益；

我有一個非常厲害後端程式設計師朋友在新浪，之前給我講了一個段子：

來總(王高飛，微博CEO)做產品經理的時候，跟大家評審完一個需求，技術Leader給的排期是兩個月，但由於專案比較緊張，來總就跟技術Leader確認看看能不能提前，結果技術Leader說這個沒法提前。然後來總說：好；結果來總用了兩週自己寫程式碼把這個需求實現了。至此，新浪的技術對於來總這個產品經理十分敬佩。

後來我又從其他地方聽到過一樣版本的段子。

市面上很多人黑產品經理，其實是有原因的，如果都能像來總這樣，我想除了尊敬，應該連黑的資本都沒有了吧。

百度李彥宏，騰訊馬化騰，京東劉強東相信他們在推動一個專案的時候，可能比那些不懂技術的產品在要排期、在評估的時候，在撰寫需求文件的時候，可能會節省很多時間。

說這麼多，那麼程式設計師在轉產品經理的時候，有什麼缺點呢？

1.溝通能力

a、這個是遇見大多數程式設計師會遇到的問題，從技術應用的範疇上來說，越靠後的技術，越缺乏這個能力；而PM在他的整個工作流程中：

b、從前期需求調研，要跟使用者聊；

c、中期需求拍板要說服老大專案靠譜；

d、文件原型要提前跟研發、測試、運營等部門同事溝通協調；

e、需求評審，對著一大幫人講；

f、專案推進中，及時解決問題和突發情況；

g、偶爾要做做PPT，梳理影響力；

.....

所有的這些，都需要溝通，確保資訊的高效獲取和輸出，對於很多職業的人來說，都不是什麼大問題，可能對於程式設計師來說，就需要加強了。

現實生活中的資訊傳達，跟程式碼裡不太一樣，溝通中文字的傳播只佔很少的一部分，溝通的方式，語氣，形態都會影響溝通的效果，這個得需要進一步來加強。

2.情商

a、一份工作的職業習慣，是會影響一個人的思維，思維繼而會影響習慣，習慣就會成自然；在程式設計師的世界裡，出了bug，程式就是沒法執行，就是過不去。而現實生活中，很多事情其實將就一下，還是可以的。

b、bug修好了程式就會馬上執行，程式設計師可以接著下一行程式碼的編寫，但是先生生活中可能不太一樣，剛吵完一架，可能就沒法友好的合作了。

c、我曾經跟我們公司一位非常優秀的技術Leader溝通到程式設計師思維，他給我的最大的反饋就是上面兩個。

3.產品基本功

a、在這個範疇裡，只有”需求調研“和”競品分析“這個技能需要花點時間來打磨，其他諸如流程圖、思維導圖很多程式設計師自己在工作中都會自己畫，用以梳理技術邏輯；

a、原型圖，比學寫程式碼簡單太多，看個影片就秒會；

那麼對於一個要轉行產品經理的程式設計師來說，具體要怎麼做，才能更快速入行呢？

還是我之前說的原則：

1.嘗試著做需求調研；

結合自己的愛好，透過發現日常使用的產品中不滿意的一個(或者想投遞公司產品的)小功能，提出自己的假設，然後進行需求調研；需求調研的方法(稍等我後邊寫一篇)

2.(結合自已已有的知識)完整的走完一個功能從0到1的改進過程；

--需求調研->選定目標使用者->競品分析->思維導圖梳理功能->流程圖梳理業務流或使用者流->產品原型->邀約目標使用者使用->收集反饋->修改原型->PRD

3.把以上流程做完後，可以找身邊的產品經理幫忙看下，有沒有問題，再不斷修改和打磨。這個流程走完就可以作為簡歷上的一個專案來詳細寫。如此認真完成1個專案，簡歷上定會添彩不少，相信會有多個面試機會在等著你。

產品經理是公司的大腦，要理解老闆想什麼，又要理解使用者需要什麼，同時作為橋樑角色，把抽象的思維做成程式設計師和各部門能理解的文字，嚴格來說是網際網路公司的靈魂

需求溝通，出設計原型，專案需求修改，說服程式設計師給他改需求，與程式設計師打架。開玩笑，其實主要還是溝通需求，原型確定，專案跟進與修改，程式設計師可以轉產品啊，優勢就是懂技術，可以避免技術難點，劣勢也是這裡，我發現好多客戶的需求在程式設計師角度都是覺得沒有必要的，但是產品經理卻不這麼認為，但是當你換成使用者角度考慮其實他們需求沒有問題，只是有可能程式設計師改起來麻煩，然後覺得這個有別的方法可以用，為什麼要改，要轉行其實要走出這個角色的設定，可以結合自己的技術，但是在可以做的基礎下，一定要好好聽客戶的需求。

2、功能定義：撰寫各種文件包含：MRD、PRD、FT等等用於跟開發、設計、老闆、同事溝通確定需求，然後實現文件中定義的功能。

3、產品運營：收集使用者和運營人員對產品使用的體驗資料，用於改進產品。

4、迭代：根據上個版本沒有實現的功能進行迭代，最佳化產品。一般像IPHONE每年迭代一款IPHONE

5、程式設計師做產品經理：首先回答可以，例如：張小龍、雷軍等之前都是程式設計師，但是需要轉換思維方式。

總之：產品經理核心思路是使得產品本身的定義是正確的。程式設計師主要是實現功能。如果轉行筆者推薦轉換思維，看前面的產品經理是怎麼做的，總結自己的方法論。同時推薦多讀書，筆者也有寫過兩本產品經理暢銷書《AI+時代產品經理的思維方法》和《AI賦能-AI重新定義產品經理》。

簡單的說產品經理就是負責一個產品從設計、研發、再到運營的全過程，產品經理是產品的第一責任人。在IT領域中，程式設計師是可以從事產品經理崗位的。

產品經理這個詞雖然不是網際網路領域發明的，但是產品經理這個崗位卻在網際網路領域產生了重要的影響。產品經理、策劃、專案經理、程式設計師等一系列崗位之間的合作成就了今天大量的網際網路產品，而這些網際網路產品的成敗往往取決於產品經理的決策和能力。

對於產品經理來說，不僅要具備管理能力，還需要具備溝通能力、技術能力和業務能力，同時產品經理還要具備較高的職業素養。

在業界中不少產品經理都是從專案經理崗位上成長起來的，所以說一個好的產品經理一定是一個優秀的專案經理，對專案的管理能力直接關係到產品的成敗，所以管理能力是產品經理首先應該具備的能力。

溝通能力是協調團隊的關鍵，能否與團隊中的不同角色形成有效的溝通是每個產品經理都應該考慮的重點問題。在IT領域中，產品經理有大量的時間是在做溝通和協調工作，只有溝通順暢了，產品的研發才能按照既定計劃進行。

技術能力對於產品經理來說同樣重要，模式變革技術先行，所以能否對不同技術有一個系統的認知對於產品設計、定位、運營都有直接的關係。對於產品經理來說，對於技術起碼要有最基礎的認知，簡單的說就是一定要知道技術的邊界在哪裡，否則容易引起研發人員的困惑。

業務能力實際上是產品經理的一個關鍵知識，業務能力體現在對產品自身的定位上，通常業務能力往往需要一段較長時間的培養和學習，不同行業的產品設計和定位往往需要具備專業的業務能力。

對於程式設計師來說可以先從專案經理開始做起，然後再由專案經理成長為產品經理。

日常工作中，時常與客戶公司產品經理打交道，其工作職責範圍有且不限於：

1.轉換客戶需求：把郵件、會議紀要等轉換為產品規格書，這是反映產品經理能力的關鍵時候， 產品硬體電路的規劃、軟體工作流程、結構外觀等，都要產品經理去統籌；

3.產品研發過程中反覆的論證：工程師反饋，供應商妥協，與客戶的意見交換；產品排期等等。

4.產品出樣：測試buglist反饋，協調內部工程、QE等部門的測試驗證；送交客戶的初樣審查；

5.產品試產匯入：產品經歷DVT、PVT之後，供應商/工程資料等的存檔、移交。

不同公司對產品經理的定義各不相同，大多數軟體廠商尤其網際網路廠商的產品經理和程式設計師都是“相愛相殺”的相處模式，產品經理通常動嘴不動手，程式設計師動手不動嘴（當然也可能直接對產品經理動手）。

產品經理是負責產品管理的職位，看起來高大上，其實要做的工作很繁雜，主要包括：競品資訊收集分析、基於客戶需求梳理出產品需求、參與/主導產品設計，產品功能測試、跟程式設計師互動修改意見，甚至產品客服、營銷工作。通常來說，一位優秀的產品經理應具備多方面的能力來對應不同的專案，不能單單隻有對產品的管理和維護能力，還要具備溝通協作能力，與客戶明確需求、與廠商和內部的溝通協作，團隊的管理能力，對於產品研發團隊的整理管控能力等。

很多產品經理都是技術人員出身，因為技術能力對於產品經理來說是必備的技能，產品設計的時候很大程度上取決於對功能和技術的理解以及如何應用技術解決相關的問題，不懂技術很難跟技術人員互動，產品經理相比程式設計師則更強調溝通能力、抽象思維、人文美感、有同理心能換位思考，如果長得好看點、性格樂觀點就更好了。現在網際網路巨頭BAT中就有兩位是程式設計師做到的技術經理，當然觀點不能一概而論，也有不會寫程式碼的技術經理把專案做到極致，比如：喬幫主、老羅（雖然很多人認為是個笑話）。

在IT行業中，程式設計師似乎是一個經久不衰的崗位，很多人選擇做程式設計師，是看中它工資高，容易就業。任何事情都不是絕對的，比如你夢想成為程式設計師，別人卻覺得那是噩夢，想盡快逃離苦海。用《圍城》中的一句話說，“外面的人想進來，裡面的人想出去”。所謂三十年河東，三十年河西，現在的程式設計師遠沒有那麼的吃香了。

　　30-35歲是程式設計師的一個坎，也是程式設計師第二次面臨擇業的時刻。 這是因為大多數程式設計師在這個年紀要麼選擇做管理，要麼選擇創業，要麼選擇轉崗.....很少有超過35歲的程式設計師還在繼續寫程式碼的。 創業的艱苦我就不說了，能做到管理的又是很少一部分了。但是選擇繼續當程式設計師還是要慎重。

　　那麼程式設計師想要轉崗究竟選擇什麼崗位比較合適呢?我會毫不猶豫的告訴你，那就是產品經理。

　　同樣是IT行業中的一個職位，產品經理和程式設計師有什麼不同呢?

　　首先，程式設計師每天要做的就是敲程式碼，工作單調乏味，除此之外，程式設計師每天的工作量非常大，每天坐在電腦面前幾乎抽不開身，偶爾才有時間喝喝咖啡，解解乏。

　　但在這方面，產品經理就要輕鬆的多，產品經理主要負責一款產品從設計到上線到更新到死亡的整個生命週期，其中每個階段的工作又都不一樣，很多時候他們需要和團隊相關人員進行溝通，協調工作。相比較程式設計師枯燥乏味的工作，產品經理的工作就要有意思的多。

　　其次，程式設計師這個崗位競爭非常激烈，市場上各種培訓機構令人眼花繚亂，會的人多了，相應的就業薪資就低了。而產品經理崗位是隨著移動網際網路的興起剛熱門起來的一個崗位，社會需求量巨大，目前大學也沒有相關專業，會的人少，所以競爭小，薪資高。

　　最後，程式設計師都是那種比較宅的人，不擅長溝通，而產品經理卻是溝通能手，好的溝通不僅可以使工作更加有效率，並且還可以結交更多的朋友，擴大自己的交際圈。

　　說了這麼多，我們來說一下程式設計師轉產品經理有什麼優勢

　　1、程式設計師經常與產品經理打交道，但是在許多的網際網路公司中，經常會出現程式設計師與產品經理互相撕逼的情況，原因在於產品經理讓程式設計師不斷地改需求，雙方矛盾激烈，互不相讓。但是程式設計師轉產品經理有一個很大的優勢，那就是懂程式碼。懂程式碼的產品經理能夠更好的跟程式設計師溝通，減少工作中的矛盾衝突，促使工作順利進行。

　　2、產品經理工資跟程式設計師相差無幾，甚至高於程式設計師的工資。對於想要轉崗的程式設計師來說，工資是他們最擔心的問題，既然產品經理薪資這麼高，轉崗產品經理未必不是一個明智的選擇。

　　3、在當前的IT行業中，產品經理是一個公司不可或缺的崗位，他是整個行業的領頭羊，一個優秀的產品經理甚至會影響著一個公司的發展。並且產品經理的就業率非常的高，在目前的人才市場中供不應求。