在進入某個行業或者某個崗位之前，我們需要對其進行一定的調研，形成足夠的認知，從而讓自己和行業、和崗位達成更好的適配。這篇文章里，作者就從幾個方面闡述了產品經理的工作內容，一起來看看，或許會對想要成為產品經理的人有所幫助。

大學稀里糊涂的熬到畢業，沒去實習或者就發了發傳單，校招時又是稀里糊涂的面試，開始還想著挑挑揀揀，后面越面越慌，沒人要你啊，能找到需要招人的公司就不錯了，至于是干人力資源還是干銷售，總先要填飽肚子。

這里面最大的問題是啥？

沒有拿出足夠多的時間，認識自己和認識行業、崗位，所以就更別提去做自己和行業、崗位的匹配。

然后工作個1年，發現現在這個工作真心不喜歡，哪哪都不好，卻又不知道該做些什么，再拖一拖等個3-5年，雖然不喜歡干現在的活吧，但畢竟也積累了這么多年的經驗，想一想轉崗從零開始更虧了，再到后面有了家庭，左邊孩子吃奶學費，右邊房貸車貸，認了，就這樣吧。

互聯網產品經理，是一個相對來說熱門的崗位，畢竟一方面薪資足夠吸引人，另一方面我們年輕時都在憧憬著能夠改變世界，看看喬布斯、張小龍這些大佬做出的東西確實多多少少影響了太多人的生活。

這篇文章就想從幾個方面講述一下最真實的產品經理的工作內容，我認為沒有完美的行業和崗位，只有最匹配你的行業和崗位，每個崗位總會伴隨著優點和缺點，當你真的能夠接受這個行業、崗位的缺點的時候，可能才真正的適合。

下面我會從一個功能的從0-1講述，產品經理究竟如何把一個沒有的東西變成有的。

一、需求池

這潭池水比你想象的來源要多得多，也并不是你想做啥就做啥，當你逐漸成熟為模塊或者系統的負責人時，才會有更多決策權，我把這池水的來源，歸納為兩類：

被動流入：產品經理每天都會接受到來自于四面八方的“問題”，來自于功能使用者、業務方、領導等，仔細去分的話可能大致分為三種：

1）看似是問題，但其實是對功能不熟悉：可能是新功能上線時的培訓或幫會文檔沒寫到位，也可能是功能設計的不好，沒有讓人一看就會。

2）新功能：一般會有專門的需求對接會議，在這個會議上關鍵業務方會提出遇到了什么問題和想要什么功能來解決問題，有一些公司還專門設置商業產品經理崗位來評審BRD（商業需求文檔 Business Requiment Document），除了專門的會議，也會單獨提出，有可能是業務方看到你的功能才想到，原來他真正需要的是什么，畢竟對于有些提需求的人來說，不上線他是想不清楚自己要啥的（這樣恰好說明前期溝通、功能原型講解的重要性）。

3）上線的功能無法使用：這種問題是最棘手的，需要立即查清楚原因并給出一套合理的解決方案，如果是半夜發生還要做好熬夜的準備。線上問題的優先級最高，處理不好可能還會引發新的問題，有這種問題不管是誰的原因都會被噴的，遇見脾氣不好的業務方或者領導，可能會被問候家人。

主動引流：能主動去挖掘潛在需求，才能夠比別人成長的更快，有以下三個方面。

1. 研究競品：競品是指的跟我們在同一垂直賽道的友商，又出了什么功能，這背后的業務場景是什么，我們的業務是不是也需要？注意，一定不是抄。
2. 驗收、體驗自己的產品：多用用自己的產品能發現很多問題，有些時候是功能可用性問題，但可能更多的是交互還原的問題，比如按鈕的位置等。
3. 看數據：要學會找關鍵數據，數據異常時要多研究是為什么，比如電商場景下，某一天單量突然減少了，沒準就是下單環節出了問題，主動發現問題并解決能有效避免被噴，降低損失。

大多數的產品經理，都不是像想象的那樣每天都在做著特別高級的規劃，更多人不是在處理問題就是在處理問題的路上，如果遇到軟件質量極差的團隊，需要習慣成為“救火隊員”。

此階段的產品經理能力關鍵詞：抗壓能力、主動性、同理心。

二、需求分析

經過第一步的洗禮，會發現有很多問題等著解決，但是要怎么把問題變成解決方案呢？

需求的本質就是啥？是預期與現實的差異。

挖掘需求的過程中往往有很多迷惑性，這里面充斥著情緒和方案。

情緒：因為某些問題很棘手，會導致相關利益受損，此時提出問題的人可能非常的沖動，根本無法說清楚具體的預期和現實。你覺得你自己有不被情緒影響的能力嗎？還是一點火就著，直接就跟人干起來了。

方案：產品做久了會發現，太多的提需求的人都是帶著方案來的。比如一個老生常談的例子，一個人說他需要一匹更快的馬，那需要馬是需求嗎？不是，馬是解決方案，他想要的可能是想更快的從A點到B點，那汽車是不是更好解決方案？你覺得你有能力或者通過學習去發覺背后實際的需求嗎，還是會非常容易受別人的引導？

我看到過太多的產品經理一直停留在別人說啥他做啥的階段，這不能讓你成為更高階的產品經理，只能讓你成為更好的寫需求文檔的工具人。

你覺得你是一個善于創造東西的人嗎，把一個東西從沒有變成有，并享受其中的過程。還是更喜歡在比較固定的框架或者規則下，每天完成差不多的事情。

此階段的產品經理能力關鍵詞：情緒控制能力、分析&抽象能力、刨根問底的能力。

三、設計方案

記住，永遠沒有完美的方案，只有最適合當下的方案，固執的尋找完美方案會導致錯過更多。

設計方案的時候要考慮的問題就更多了，這里只簡單的把維度列出，具體的案例會在后續的文章/視頻中講解。

需要同時滿足：商業、研發、用戶三方面的訴求。

1. 從商業上是有價值的，要么增加營收，要么降低成本，最終的目標就是利潤。
2. 從研發上是可以實現的，不要搞什么烏龍，要求研發做一個手機屏保是根據手機殼顏色，就算能做成本要太高了。
3. 從用戶上是使用便捷的，除特殊情況以外，用戶用著爽才是一個軟件產品能夠長久發展的必不可少的因素。

方案完整性：再初階的產品提出的方案都必須要自恰和他恰。

自恰是指的你這個方案里面的邏輯不能自相矛盾，一會說A是麻雀一會又說A是猴子是不行的，他恰是指的你的方案不能肆意妄為，大概率你的方案是要成長在別人搭的框架之下，不能你來一個方案把整個框架都改了，如果不是以重構為目的的方案最好不要動。

進階一些的產品需要考慮到方案的續恰性，也就是方案的可拓展性，對于高階產品來說不能要完成這個方案就完了，還要依據邏輯和行業經驗把架子搭好，方便后續業務的拓展和其他產品經理添加東西。

時間：時間是一個非常隱藏的成本因素，需要評估這個需求有沒有時間要求，如果有時間要求一般會將大的方案拆分為多個階段。第一個階段先搶救或者先搶占市場，后續慢慢完善。

以上還僅僅一個比較獨立的系統所需考量的，規模越大的公司會越容易涉及到跨部門的需求，此時還需要關注幾個方面：

共同目標：尋找共同目標利益是合作的前提，不同部門之間的墻遠比你想象的高，必要時還需要借助更上級的資源進行推進。

明確位置：在一個需求中，不同部門之間會有依賴關系，梳理不清依賴關系會導致項目推進中出現非常高的風險，比如你的需求是依賴其他部門給你計算的一個結果，如果方案設計階段沒有評估到，在研發的過程中再爆出來就還導致需求延期。

持續溝通：跨部門溝通的另一個難點就是大家都只了解自己的系統，緊密溝通非常重要。

具備以上的能力以后才是真正的將方案落地為原型和文檔，原型是產品經理用來描述需求的界面，往往軟件功能都是有操作界面的，文檔更多的是更嚴謹的文字形式的邏輯說明，這兩者是產品經理的基本功。

原型示例：產品一般會用最簡單的線框圖說明白這個功能的本質和邏輯。

圖片來源于網絡，侵刪

文檔示例：文檔是配合原型將邏輯描述的更加清晰，尤其是涉及到業務流程和復雜邏輯的系統。

你是否愿意為了這個崗位學習如何畫產品原型，寫需求文檔？

你覺得你是否是一個可以在多個因素的要求與制約下找到最合適方案的人？

你是否善于在多個職能/部門之間溝通，找到共同利益并有效推進需求。

此階段的產品經理能力關鍵詞：多因素決策能力、大局觀、溝通能力、基礎原型&文檔能力

四、需求評審

前面3個環節是需求的吸收、內化、總結，而需求評審是一個交付的過程，需要讓交互設計師、研發、測試清晰明白的了解你的需求要做什么。

這個過程最重要的是能在評審會議上，將你的方案講述的明明白白，不留任何疑問，但如果你以為這是一個相對輕松的過程，那你就大錯特錯。

參會人會和你提出非常多的問題，甚至會挑戰你，因此你要做的不光是解釋清楚要做什么，還要解釋清楚為什么要做。比如：

• 你為什么要設計這樣一個功能，為什么不用另外一種，我覺得XXX做的很好。（應該提前想清楚不同方案的優缺點以及為什么選這個方案）
• 你有沒有考慮過如果不這樣，那會出現什么問題。（流程不僅有正向設計，還有很多逆向和分支流程，這些最見產品經理的功力）
• 要實現這個功能，我們需要XXX，這個誰提供。（這在涉及階段需要考慮到依賴關系，如果依賴別的系統需要在會議時說清楚）

如果會議上人比較多，可能會由某個點引申討論非常多的問題，比如本來需求評審會是為了講清楚需求是什么，而研發可能會討論實現的方案，以及排期，此時需要及時識別并控制住，繼續進行評審。

你是否能適應公開演講的場合？能夠條理清楚的表述自己觀點？

你是否具備良好的控場能力，在各個職能的人討論得不可開交的時候找出問題的關鍵給出結論。

你是否能在非常短的時間內判斷別人的建議是好還是壞，是應該吸收還是應該用邏輯的方式拒絕？

此階段的產品經理能力關鍵詞：表達能力、控場能力。

五、功能開發

需求評審只是初步的交付給研發，功能開發的過程（代碼編寫的過程）研發、測試還會源源不斷的給你提出新的疑問。

你要針對這些疑問進行答疑，并且需要將這個過程中新的結論更新到需求文檔中，否則這將成為日后你與研發、測試撕逼的開始。

如果你的項目沒有專門的項目經理，你需要及時關注項目進度，在關鍵時刻提醒風險，保證需求能夠按時上線。

你以為完成上面這些就可以高枕無憂？又錯了？

別忘了還有需求變更！

需求變更是指最根本影響的是你的方案要變了，原因有很多：

• 當時跟你提問題和需求的人改變了主意，之前要A現在要B。
• 當時跟你合作的部門出爾反爾（也可能是你找的人根本沒有了解很清楚），之前說能提供某個能力，現在由于資源不夠不能給你提供了。
• 你自己的設計有問題，突然發現某個地方應該做調整（這種必須要杜絕掉，不允許發生）。

遇到需求變更，要根據需求變更的程度，重新拉通相關的人員，做出解釋、安撫情緒，需求變更越早發生越不容易影響最終的上線時間，如果明天就要上線了，你今天說要變更，這意味著：

• 這段時間以來所有跟你合作的人部分努力都白費了。
• 需求不能按時上線，影響了業務發展，更直接的會影響你的績效，無論是出于什么原因，你負責的項目事實就是沒上線。

你是否具備給別人不厭其煩的解答的能力？

你是否能耐心的將文檔維護成最新的？

遇到需求變更，你是否有能力協調一切資源，將變更降到最低并按時上線？

此階段的產品經理能力關鍵詞：主人翁思維、風險控制能力。

六、功能上線

需求開發完，研發和測試的工作即將結束，此時需要你來對功能進行驗收。

你需要提前寫好驗收的場景和這個場景對應的預期效果，比如點擊某個按鈕應該出現某個提示。

• 驗收是枯燥且重要的過程，能夠把問題暴露在上線前是對用戶最起碼得尊重。
• 驗收是嚴格的，不能因為顧忌研發、測試的面子而將問題忽略掉。

上線前需要編寫此次功能的指引文檔和組織培訓，目的是為了讓使用這個功能或者負責推廣此功能的人知道該如何使用，并告知具體的上線時間。

一般來講功能發布上線不是你想象的簡單的點擊一下上線就上線了，研發和測試需要做大量的工作將代碼部署到線上環境，這個過程很多公司可能要持續幾個小時，期間還真的有可能發生新的問題，產品經理盡量能隨時待命保證按時上線。

不同的公司要求不同，有些公司可能會要求產品經理必須在發布的現場的，而這可能會導致加班甚至通宵。

需求上線后還需要對功能做相對簡單二次驗收（一般來講上線后測試同事會進行回歸測試）

你是否能耐心的書寫并驗收即將上線的功能？

你是否能嚴格且禮貌的提出問題？

此階段的產品經理能力關鍵詞：表達能力、耐心、責任心

這些過程，每個需求都要走一遍，因此在同一時刻，你會有不同的需求在不同的階段，要合理的規劃好時間，同時也要做好被打斷的準備。

想想自己剛畢業的第一份工作，工作內容非常的雜，僅有一小部分跟產品經理有一點關系，大部分都是做重復的運營工作，在工作了將近一年后發現自己非常不適合在別人的規則下每天做著同樣的事情，更傾向于創造和制定規則，更希望能夠用上帝視角看問題。

當時買了幾本書，大概了解了一下互聯網產品經理的工作，同時報了一個班學習了Axure（實時證明沒什么用），毅然決然的投入到了產品經理大軍，在屢次碰壁后終于拿到了一個產品經理的Offer，還好我當時及時放棄了舊工作，不然到現在自己應該挺痛苦的。

了解完產品經理日常，你還認為你適合做產品經理嗎？評論區告訴我。

感謝@小智 @Joey @Mandy @Hotel的勘誤和建議。