前言：產品經理是幹嘛的?我當下的理解是他是提出方案，解決問題的一群人。

忠告：程式設計師轉型做產品人，把我這一年半新悟出的道與理，送給大家。想轉型產品經理，或者產品初學者建議認真看完!

此文產品經理方法論，僅供參考，請不要完全模仿!

本文目錄：

一、思維模型

二、工作方法

三、坑有哪些

四、專案延期

一、思維模型

思維模型是我們部門老大鄧春林總監經常對我們說的一個詞語，那麼什麼是思維模型呢?

我所理解的就是，每個人自己在做產品思考問題給出解決方案的時候，形成的一套固有的思維方式，而且因人而異，每個人都必須形成自己的思維模型，沒有強制要求每個人的思維模型一模一樣，但可以參考借鑑別人好的思維模型，從而悟出自己的道。

定義

我的思維模型：用技術MVC架構思考解決問題。

解析

M：資料庫底層，也就是事務的本質。

C：業務邏輯層，也就是各種事務之間，各個業務流程的流轉。所以，我思考問題的順序是：先挖掘此需求背後事務的本質以及他的價值，再分析涉及到的各環節的業務流程，最後用原型介面將整個事務過程串聯起來。

因為是技術出身，所以我希望將經典的MVC技術架構與我做產品經理時，思考問題的方式進行完美的結合;我不知道我是不是第一個提出使用mvc架構作為思維模型思考問題的產品，但我不希望我是最後一個。

二、工作方法

1、如何需求調研

a.瞭解問題現狀

問清楚需求方遇到什麼問題，要解決什麼問題，不爽在哪裡，痛在哪裡，不解決會怎樣?最後，將需求加以記錄，並與需求方確認。

b.現有業務流程

問題是出現了，那麼當下你們是用什麼方式規避這個問題的呢?現在你們的業務流程是怎樣的呢?希望在流程上做哪些最佳化呢?

c.功能價值

這個問題解決後，對你有什麼好處，產生什麼價值?

d.可行性分析

排好優先順序，及時反饋結果。做還是不做，都要給合理解釋;並不是需求方說的全部就是需求，要自我加以過濾;他說的痛，是不是以偏概全，要追究問題的本質，他到底要解決什麼問題?

2、如何需求評審

a.產品出原型+規則

評審之前，必須自己獨立想清楚此次需求所有涉及到的規則。雖然，可能未必有些情況自己考慮完全周全，但必須自己用心深度思考一番。否則，召集其他專案組成員，是極其不負責任的行為。這裡，與我以前做專案經理時候的思維方式，完全不同。相當於是我要改變以前固化的思維模型，此中過程，有些困難，還好我挺過來啦。

b.產品初步與需求方原型評審(可多次)

自己初步畫的原型和規則，得先跟需求方單獨過一下，確認是否達到初步預期。如果沒有的話，那就要及時調整出新的原型+規則，迴圈往復，直到需求方滿意為止。

c.產品初步技術原型評審(可多次)

需求方搞定，那麼就要單獨搞定專案組中得技術成員(前端、後臺、測試、UI等)，技術與需求方關注的是不同的視角。需求方，是告知其有這樣的頁面和規則。技術，會問為什麼有這樣的頁面和規則，能否解釋清楚明瞭。技術提出的問題，你解釋不清楚，那就要修改原型+規則，直到任何一個技術都沒有問題為止，此輪評審才算結束。

d.產品組織專案組所有成員正式評審

需求方與技術都搞定了，那麼召集專案組所有成員，組織大會議室，進行系統當前版本的正式評審，就水到渠成了。最後調整完畢的原型+規則，必須同步給專案組所有成員，如果此次正式評審仍有疑問，那麼又要重新調整原型+規則;如果沒有疑問，那麼專案評審成功，順利推進到開發階段。

e.專案排期

f.上線驗收

測試驗收需求後，進入產品+需求方驗收階段，此時一般在灰度環境，不會影響正常線上資料。雙方同意上線後，測試走上線流程，專案當前版本上線成功。

3、如何自我開展工作

a.遇到問題，先至少想個解決方案，再和別人溝通

b.事事有反饋

出於尊重，任何人任何事，都要給予反饋。即使當下沒有解決方案，即使當下很忙。訊息已讀未回覆，容易給人造成誤解，也容易讓別人失望。

c.多聽少說，不要插話，不要強加個人觀點

此點更像是為人處世之道，要懂禮貌。實在要插話，請先說句：不好意思。有時候，產品經理組織會議，作為主持人，必須要打斷大家偏離主題相關的話題，必須要有控場能力。這不是不尊重人，我們只是想讓會議變得更高效有價值，產品經理的會議多而複雜，如果不會控場，那會浪費極其多的時間;別人討論的時候，不要用自己的主觀意識誘導別人、誤導別人。特別是需求方的吐槽，讓其暢所欲言，讓其說個痛快。然後，自我再總結挖掘問題的本質。

d.時刻關注問題現狀、業務流程、功能價值

這三點缺一不可，很重要很重要很重要。公司當初系統改造的時候，我就吃過不少虧，就是因為自己當初還是個小白產品，沒有自己的思維模型，沒有關注問題現狀、當下業務流程、功能的價值，為後來自己所做的產品，挖了不少坑。結果，上下游系統巢狀太深，坑也是越陷越深，好不酸爽。

e.對上下游系統必須要有所瞭解

這點，也是感悟很深。很多時候，各個系統的產品，都是隻關注自己那一畝三分地，想需求想問題，沒有把涉及到的上下游系統考慮進去。導致的結果就是，在自己系統沒有什麼問題，結果串聯上下游系統就暴漏各種問題。有些時候，也能理解，自己系統的需求不斷，加班加點趕原型寫規則，哪有時間去了解其他系統哦?不過，時間猶如X溝，擠擠還是有滴，各位老鐵。

f.控制好情緒，別激動

產品，被人質疑，背鍋俠，被人diss，那再正常不過的啦。你會不會做產品?你做的什麼垃圾產品?我要換產品，你不行。你會不會畫原型?你有沒有想清楚?這個專案做出來有什麼意義?你是什麼垃圾?老鐵，淡定，Sunny總在風雨後滴，乾巴爹!

g.多換位思考，保持同理心

不同的人，你要切換自己成為不同的角色，爭取與其保持同頻，明白其所思所想，這點很難，我也就說說，目前感覺依然差之十萬八千里

h.對過程和結果都要負責

很多時候，咱們明白對過程要負責。但是，結果其實我們更要負責。產品上線了，就算是完成任務了嗎?後續能不迭代就不迭代?產品的死活，與我無關，反正我已經做好了。這些想法，我認為都是不對的。我們只是做了0到1，1到100，依然是任重而道遠，要有產品人該有的情懷，要創造更多的社會價值。

i.自己做的產品一定要比任何人熟悉

自己做好的產品，一定要將輸出物弄完整。至少有原型+規則+操作手冊，如果有影片那就更好了。一來便於傳承，二來便於後期自己回憶。有時候自己負責的系統有點多，部分功能忘記細節，有資料的好處就體現的淋漓盡致，希望各位產品多為後人栽樹，讓其乘涼。

j.一定要經過關鍵大佬同意

有些新的產品、新的業務、新的需求，會牽涉到多個部門多個關鍵人物，這個事能不能做、怎麼做，一定要跟相關關鍵大佬正式確認，全部同意才能去做，千萬不能火急火燎。不能因為一個關鍵人物的單方面決定(其他大佬未知，或者不同意)的情況下，去為其做這件事。要不，不僅吃力不討好，而且夾在中間裡外不是人。總結：必須正式會議正式檔案，所有關鍵人物必須都在，沒有最終定方案，產品不做任何調整。

k.關鍵節點及時通知

#已上線版本通知：專案上線了，要及時告知需求方和專案組所有成員，上線功能+功能價值等關鍵資訊；

#未來規劃通知：專案當前版本上線了，未來的規劃，要簡明扼要的通知給需求方和專案組所有成員。

#專案風險通知：這個必須通知，下面第四點我有再次強調。不僅要通知，而且還要解釋清楚原因。

l:會議關鍵人物

j.原型與TAPD如何規劃

如果是新的專案，那麼以原型為主，tapd為輔；

如果是已上線的專案，那麼以tapd為主，原型為輔。

4、如何與專案組成員合作

a.我們應該互相尊重，相親相愛形同一家人

b.站在使用者的角度去寫程式碼

我時常提醒自己專案組的技術，不要死寫程式碼，多思考下他背後的意義。如果你是使用者，你會用這個功能嗎?價值何在?有的技術就做的特別好，根本不用我提醒，反而很多時候能給予我極大的幫助。

c.有鍋我來抗

產品，很多時候是背鍋俠。有時候，專案組其他成員的鍋，我覺得沒必要去追究，就是咱們的鍋。單獨再去找出問題的專案成員溝通，讓其注意就好。

d.不會為難你，但請別給我挖坑

說實話，如果我要較真，技術同事評估的工期，我自己都能評估的出來(之前創業時幾乎天天給客戶評估工期)。我並沒有干涉技術評估的工期，並不是放任不管，而是對他們的尊重，各自評估自己的開發時間，我心中自然有一杆秤。但是，不要總是快到上線的時候才告訴我要延期。評估工期，不是兒戲，請認真對待。我喜歡，未雨綢繆，提前告訴我任何風險，這樣我好把控專案進度。

e.所有新需求必須經過我同意

所有需求，必須經過我這邊過濾。部分小改動，需求方有可能直接跟技術溝通。但必須告知我，我同意才能改，不同意我會告知需求方與技術原因。

5、如何與專案組之外同事合作

a.關鍵人物溝通

外部團隊協作，一定要找到關鍵人，能拍板、有話事權、決定權的人，這樣溝通協調事情事半功倍

b.藉助外力

如果外部團隊相關關鍵人不配合，那麼請求上級領導協助，並告知此事來龍去脈。反正，逐級往上彙報，直到此事有個處理結果。不要害怕得罪人，我們是做事的人，對事不對人。

c.所有正式的決定必須有據可查

所有正式的決定必須有資料儲存(公司郵件等)，便於日後以防雙方忘記，或者扯皮

三、坑有哪些

a.歷史資料

任何一個系統改造的大難題，我就深深地被其困擾過。要把按照以前舊規則的幾萬條舊資料匹配系統改造後的新規則，而且還要保證這些資料上下游系統能夠跑通，此種過程是極其困難和麻煩的。

b.技術沒空，導致專案延期

有的時候，被這樣坑，也是無語的很。本來大家都溝通好的上線時間，突然技術跑過來說我這邊沒空搞你這個專案，要搞其他更重要的專案，你的專案要延期(此時，心中一萬個策馬奔騰)。一次還好，一次又一次，你爽嗎?你的需求方爽嗎?

c.遺漏的技術bug

測試小哥哥小姐姐其實很給力，沒有他們把關，一個專案上線肯定更多問題。但百米也有一疏，上線後仍有技術bug情況，也是有的。如果重要緊急的，要求團隊成員加班加點必須解決;如果不重要緊急的，也別太為難人加班加點，雙方定個寬鬆點的最佳化時間期限就好，技術都是很好的一群人，不要為難他們。

d.需求變更

又一個老大難問題，需求變更導致的風險，是很麻煩嚴重的。不過，要根據自己的經驗與能力判斷，此次需求方變更需求的影響範圍。如果影響不大，那能改就改;如果影響較大，那必須報風險;如果是影響思維模型中的底層資料架構，那必須報嚴重風險。

e.緊急需求

最怕這類人，不講理還霸道，整個專案正常的上線流程又不是不知道，但還要提出我現在就要，一週之內就要這種不懂網際網路專案正常上線流程的無理要求。誰的事不急，誰的需求不重要?你現在要，我也給不了，小需求我可以快速評估，儘快上線，儘量做到能今天上線絕不拖延到明天。但是，大需求該怎麼走流程還是得怎麼走。

f.影響上下游系統

上面已提過，再次強調其重要性。我覺得此牽一髮而動全身之事，應該是整個專案組的成員，都要去考慮，而不只是產品經理。

g.部分原型規則遺漏

這個鍋，是產品經理的，考慮問題不周全。但是，我覺得不完全是，專案是有需求方、所有專案組成員一起評審的，大家都沒發現，咱們不小心漏掉也是無心之舉，只能透過不斷刻意練習，儘量避免這種問題的發生咯。

h.專案組臨時換人

專案開發到一半，技術突然離職或者被其他專案借調，導致專案突然報風險，也是很容易讓人措手不及。如果技術離職，得找人儘快接手咱們的專案。如果技術被借調，咱們產品得去了解具體原因，想解決方案。最終目的，保證專案正常上線。

i修資料

資料在，各上下游系統中流轉，難免出現一些錯漏的資料，在系統上已經是無法修改的了。這種時候，只能透過技術手段，後臺修改該部分問題資料，保證資料正常流轉。

j.雜事纏身，無法專心出原型+規則

很多時候，咱們會被各種雜事幹擾自己正常的工作。各個需求方的需求都很急，但卻被各種雜事、會議拖慢了專案正常進度。很多事很多問題，不得不處理;很多會議，不得不參與。此時，高效的處理問題並給出解決方案，高效的討論會議並達到會議目標，尤其重要。這一點，仍然堅持對事不對人原則。

k.各系統需求邊界劃分不清

估計很多產品，自己都沒搞清楚自己做的系統目的是什麼，只要需求方提出來的需求就接進來，根本不在乎自己系統的定位是什麼，邊界是什麼。這樣做，沒錯。但是，需求方提出的是其他系統的需求，你是不是應該找其他系統產品聊聊，將各個系統邊界劃分清楚?我認為是很有必要的

l.崗位職責劃分不清

很搞笑的一點就是，我目前所在的公司，我所負責的產品，同時擔任產品經理、客服、日常運營維護三個崗位職責，卻拿著一份產品經理崗位的工資。產品經理是做什麼的，我是搞清楚了，可貌似我們公司有些人沒搞清楚

越做越發現，產品經理的崗位職責很難界定清楚，需求溝通，產品設計，運營，客服，系統維護等等，貌似很多方面都會涉及的到。我們就像個家裡的保姆，哪裡需要，就去哪裡解決問題。

四、專案延期該怎麼辦

看到這裡，相信大家也發現了，專案最大的風險就是專案延期。因為延期，導致的後果，可大可小，這點因專案而異。那麼，該如何解決呢?

a.查明原因

導致專案延期的原因：離不開需求變更、原型+規則考慮不周全、技術bug、專案工期評估有誤、突然更換專案組成員等等。是其中哪個原因，還是哪幾個原因?找出來，然後對症下藥，爭取下個版本或者其他專案，不要再犯。

b.定解決方案

出現問題不可怕，可怕的是連產品經理都手足無措，沒有解決方案。

c.上報風險

專案都報風險，導致延期了，如果該知道的人還不知道相關原因的話，那就說不過去了。而且，必須給出大家合理解釋。

總結

感謝這一年半以來，所有對我給予幫助的公司同事，有點進步，餘下的時光，請多多關照。

首先你要知道自己為什麼要轉型產品經理。我記得《從為什麼開始：喬布斯讓Apple紅遍世界的黃金圈法則》這本書裡的一句話，是這樣說的：人人都知道自己是“做什麼的”；有些人知道自己是“怎麼做的”；但只有極少數人知道自己“為什麼”要這樣做；唯有那些明白“為什麼”的人，才是真正的領導者。

我是這樣理解這句話的：做事情，是自內而外、自上而下，必須先考慮其核心本質，然後再去著手其他的，這樣才會有成效。

所以，你一定要問自己：為什麼想轉型成為產品經理？Why？

其次，付諸行動轉行不難，轉行後有成績才難。所以說不是每個人都合適轉產品經理，產品經理是最複雜、最綜合、最考驗人的職業。他需要很強的思維邏輯能力，明白產品前後端各種複雜的邏輯銜接；需要很靈活的思考能力，能快速從規劃者與使用者之間進行思維的轉換；需要很敏感的資料觀察力，能從複雜的運營資料推導產品運營過程的真實場景；需要更夠多知識的儲備，要懂技術、懂設計、懂推廣、懂運營、懂使用者，對事情的理解要有足夠的深度和廣度；需要很好的協調合作能力，面對不同性格、職業、職位，協同team作為一個整體完成產品的各項支撐工作；需要很主動的推進力，能夠及時發現公司、專案、產品運作中的短板，並能夠在沒有實權的前提下協調全部資源把事做好，資源包括人力、資金、時間和老闆的支援；需要足夠的領導能力，在團隊中被信任、有影響力、有話語權，能夠讓兄弟們為你去拼命，同時公司不會賦予你這樣的權力，而是透過自己人格魅力的展現……還有很多很多。

並且，初級的產品經理雖然很容易做，但整個職業生涯有多個分水嶺，你在這個職業能走多遠，除上述還需要很多，包括同理心、執行力、擅於歸納和總結的能力等等。

周鴻偉在演講時就曾說過產品經理是最委屈的，因為他頭銜最低，經常要協調很多人，要忍受技術部門的白眼，要忍受公司不同高管不同方面給他近乎矛盾的要求，甚至有時候不得不忍受一些所謂白痴領導給他的指令，而且很多時候還要協調公司內部不同的部門，包括市場、傳播。但是他也認為產品經理就是總經理，就應該把自己當成一個總經理，就要透過人微言輕，但是你要敢於說話，要能夠表達自己的意願，敢於對一些意見說不，要能夠鼓起勇氣去推動很多事情的進展，哪怕非常難。

最後，助你轉型成功吧！

看你怎麼選，選擇路徑不同，難度就大不一樣。

產品經理是思維，不是技術，思維的特點就是門檻低、天花板高、驗證成本高。編個程式，跑通就是過了，很好驗證，但門檻高；設計一個App沒做過也用過，至少有用其他App的經驗，所以門檻低，但到底怎麼設計是好的，總不能都給你編好程式、設計好UI，還切好圖，找批使用者給你試效果吧？！

所以，如果你遇上不正規的小公司，可能也沒有做產品的經驗，會吹的話，也許能蒙一個產品經理或者助理。但是正規的公司一定很重視產品經理的實戰能力，所以一般會要求你經過專案驗證、有深入的思考甚至知識體系。畢竟一個專案的資金也不是大風颳來的。

1、關於轉崗產品經理，必須越過的心魔對於想轉職的人來說，最大的擔憂莫過是自己又要從0開始。記得很多人對我說，不要隨便轉職，當你重新在一線打拼的時候，同齡人都已經當上資深員工，和管理者了。的確，這是真誠和現實的建議，我很感謝他們。但我相信，只要是一件事情能讓自己成長，和朝好的方向變化，這件事情就是好的；即使自己可能會失去之前的積累和地位。另外，我也相信，一些事情不能和別人對比，也不能太在意別人眼中的形象，而應該考慮自己是否能真正的，獲得內心的寧靜、愉悅和滿足。

2、關於轉崗產品經理，其實轉職一定不是從0開始職場常識+互動設計能力+專案經驗，這些都能立即運用到產品崗位上。至於做產品的思維、感覺和做事方式，也肯定不是0。只是在應聘時，需要做一些功課來證明。

3、關於轉崗產品經理，原公司轉，還是換公司轉？前者肯定是最保險的方案，因為你對業務和人事都相對熟悉一些。我當時有機會在原公司轉崗，而且是產品負責人主動招募我，但我還是選擇了後者。因為我還要選擇一個更合適的行業，而不是僅僅完成轉崗。我相信隨著網際網路行業的成熟，做網際網路產品經理的方法論，也會越來越成熟。會有一大批經過標準方法論洗禮的產品經理，出現在市場上。因此，我的觀點是，在未來更加吃香的產品經理是這3類：1）懂技術，會運用新技術；2）掌握某一領域和行業的專業知識；3）能整合資源。自我判斷，我適合在第2條上深耕，而我很確認對前公司所做的行業沒有真正的熱情，因此，我選擇換公司轉。

4、關於轉崗產品經理，技能短板，需要迅速補足前公司招募我的產品負責人說，如果我到他們那，需要迅速找到專案管理和資料分析的感覺。而這兩項，是我真正沒有實際操作過的東西。的確，別人和自己認為自己能做，和自己真的做過是兩碼事。其中有很多隻有實際操作過，才知道的細節。對於轉職的人，必然存在技能短板，必須有意識的在短期補足。

5、關於轉崗產品經理，相信自己能做到我想了很多說服自己的理由，推匯出自己能轉職成功，但真到了要做抉擇的時候，內心還是有一些惶恐和擔心。於是，我這樣對自己說：“你知道前方是什麼嗎？”“…不知道。”“…那你怕個X啊！”

這要看你想轉型成哪一類產品經理。

還有一類是金融產品經理，給金融公司做軟體產品。這就比較複雜。除了懂網際網路，還要懂金融知識。這類產品經理比較難做，門檻高，需要培訓。當然，工資也很高。月薪1.5萬元起。