產品經理的誕生背景
定義任何一個問題，不妨從它的背景開始講起。
自1927年，美國P&G（寶潔）公司出現第一名產品經理以來，產品經理的價值逐漸被市場認可，但其實那個時候的產品經理更像今天傳統行業的品牌經理，負責產品的品牌建設、市場銷售等幾乎所有的事情，偏重於市場、商業端。
隨着互聯網和移動互聯網的普及發展，一波又一波的互聯網、移動互聯網、智能硬件、VR/AR等產品被推向了市場，還有很多生活裏的傳統行業，也被“互聯網+”的力量跨界滲入，互聯網公司的從業人員規模也極速膨脹起來。爲了提升從業人員的職業能力和效率，很多互聯網公司的崗位職責也越來越細化，將原來的策劃一職，拆分爲產品經理和產品運營。在之前，各家公司的招聘需求中，策劃是同時擔任網站的需求整理、溝通實現與推動上線，同時還要對上線後的運營結果負責的工作職責。慢慢地，就逐漸演化爲了兩個職業角色，其中一類能對產品需求把握比較準確，與開發溝通推動需求上線，並做產品規劃與迭代的人，被稱爲了產品經理；而另一類，對用戶慾望瞭解比較深入，比較擅長文案編輯、策劃各類創意活動，用戶互動等，則被稱爲了運營人員。
由此可見，產品經理的出現是爲了適應行業、公司發展的需要，就好比在淘寶還沒有出現之前，是沒有淘寶客服這樣一個角色的，但是隨着電子商務，尤其是淘寶的普及率越來越高，淘寶客服這樣一個職業的出現也是爲了適應行業、公司的發展需要。如果再進一步想，隨着人工智能的發展，以後可能有相當一部分的職業將會被機器人給替代掉，到了那個時候，是不是也會相應出現一些新的職業來讓人們去從事和勞動呢。
大家是不是也可以想想，產品經理這份職業究竟可以走多遠。
產品經理需要扮演的三種角色
瞭解了產品經理這個崗位的背景來源，我們是不是還需要了解產品經理平時都幹些什麼工作。很多還沒有入行的新人，往往不太清楚產品經理的具體工作職責是什麼，更沒有辦法詳細地闡述產品經理可能涉及到的角色。
在我看來，產品經理至少是3種角色的混合體。
首先，產品經理應該是一個商業洞察者。
所謂商業洞察者，是指具備商業洞察能力的人，說到底，其實就是對人性和隱形規則的把握能力。產品經理必須要有洞察人性和商業的能力，這樣你才能更好的發現市場痛點，瞭解用戶需求，然後用商業來完善你的產品想法，而不是僅僅作爲一名員工去實現公司給你指定的產品路線。很多產品經理工作多年無法進一步提升，其實相當一部分是卡在了商業洞察這一塊。於是很多人在問是不是應該多讀幾本書就可以系統訓練商業知識和商業嗅覺，從而來增強自己的商業洞察能力。結果未必如此，我們會發現一家公司的老闆往往是商業洞察能力最好的那一個，他們有很系統的商業知識嗎？他們有很高深的商業理論嗎？他們有相應的專業知識嗎？其實也不見得，他們中的一部分可能連報表都看不懂。但他們知道，什麼生意賺錢，什麼生意虧本。這就是商業的洞察力，就像長久在森林裏打獵的獵人，他們知道獵物在哪裏，這種本能幾乎是天生的。
其次，產品經理會變爲一個創作者。
這種創作，和其它所有的藝術家創作是一樣的，就像畫家畫畫，詩人寫詩，作家寫小說，人體藝術家創作人體藝術，而產品經理創作的則是一款互聯網產品。產品經理需要去定義和規劃這款產品，要爲這款產品確定設計風格，要去梳理這款產品的架構設計，甚至還要去確定每一個頁面裏面的每一個按鈕究竟該如何擺放，如何設計。當然，和所有的創作者一樣，產品經理也會受到現實世界裏的各種束縛，比如這個需求目前的技術實現不了，這個產品並沒有太大的商業價值等等，和其它藝術創作者一樣，產品經理也在追求一種創作的平衡，戴着鐐銬進行舞蹈。對於產品經理來說，能夠通過創作將自己的想法、價值觀灌輸到產品中去，已是一件非常令人振奮的事情了。
最後，產品經理又會變身成爲一名導演。
之所爲會說比較像導演，是因爲導演在挑好拍攝的劇本後，需要組織安排一夥人（製片、攝影、燈光、道具、演員等）將劇本給拍攝出來，其中穿插着大量的溝通、管理工作，拍攝完成後，還要帶着一票人馬跑到全國各地的院線去做路演宣傳，不得不說，這是非常辛苦也非常有成就感的一份工作。產品經理也是這樣，在產品設計完成之後，產品經理需要協調一大幫人，其中包括設計師、程序員、測試工程師、運營推廣、銷售等等，將產品通過代碼給實現出來，發佈上線並進行推廣，讓產品被更多的用戶瞭解和使用。
當然，這裏所闡述的三種角色，是一種相當理想的情況下，產品經理可以從事的三種角色狀態的切換。但一般來說，要做到這種理想狀態，往往需要產品經理具有豐富的產品實戰經驗和產品閱歷，能夠自己從0到1去創造一個新的產品，不然的話，可能只會涉及到這裏面的某一個角色，或是某一個角色裏面的一小部分。
通過這樣一種通俗易懂的描述方式，讓那些沒有從事過互聯網工作的人也對產品經理有了一定的瞭解，接下來你還可以對他們講講產品經理的幾個特徵。
產品經理的幾個特徵
沒有實際的領導權
很多外行的人，聽到產品經理這個職位名稱的時候，都以爲產品經理是什麼公司領導，管理着一票人馬來實現和推廣產品。殊不知在國內，產品經理雖以“經理”爲頭銜，但是在大多數情況卻並沒有實際的行政領導權。由於沒有實際的行政領導權，所以產品經理要想做好產品的確不是一件簡單的事情，因爲你需要去驅動和說服一批不是下屬的同事去實現公司老闆或者自己的想法。這時候對產品經理本身的人格魅力，就是一大考驗，在成爲產品經理的道路上，你會碰到一系列的困難和挑戰，比如如何去推動團隊成員完成項目，如何讓團隊成員覺得你是一個靠譜的產品經理，如何讓大家對你產生信服等等。
事多而雜
在很多人的眼裏，產品經理是一個非常高大上的職位，逼格滿滿。近年來，也有越來越多的人毅然投身到了產品經理這一行。產品經理這個職位就像忽如一夜春風來，在各大互聯網公司花開千樹萬樹。事實上，產品經理每天需要處理非常多的雜事，加班更是成爲了一種現象。
相信很多從事產品經理年限比較久遠的人，對此深有感悟。爲什麼說產品經理做的事情多又很雜呢，我們先來大致梳理下產品經理都有哪些可能要做的事情：
a.跟進類：項目進度跟進、BUG修復跟進、發版跟進、UI跟進、客服跟進、測試跟進等；
b.設計類：市場調研、競品分析、功能點設計、原型設計等；
c.溝通類：和老闆溝通、和開發溝通、和運營溝通、和設計師溝通、各種相關資源協調等；
d.組織類：組織項目會議、組織需求評審會議、組織開發會議、組織測試會議等；
e.文檔類：需求文檔、原型文檔、流程圖、會議PPT、產品PPT等；
f.分析類：數據分析、投入產出分析等；
g.打雜類：產品專利申請、產品培訓、蒐集資料、產品幫助手冊撰寫等；
以上大家不難發現，產品經理的工作不但多，而且雜，就像互聯網上流行的那首《產品經理是條狗》裏面唱的那樣“我睡得比貓晚起得比雞還早，工作在拼體力武器得用大腦，左手的P R D 右手的產品稿，什麼纔是你想要我每天在煩惱，郵件又來催催催 產品開發累累累”。
協調和驅動
產品經理有很大一部分工作是在做協調和驅動相關的工作，雖然產品經理不能直接領導其它部門，但是可以對其它部門的人員進行協調和驅動，統籌所有團隊人員來更好的完善產品。所以，產品經理平常要經常去協調很多部門，比如要和設計師打交道，要和程序員好好溝通交流，要和測試人員溝通工作，要給客服銷售培訓產品，要跟運營人員溝通推廣的事情，要跟市場人員談支持，有時候還要說服老闆給資源，去給陌生用戶做用戶訪談。
產品經理就是產品的負責人，也是互聯網公司裏面唯一一個樞紐型的崗位，理所應當爲了讓產品活得更好而去驅動更多的人爲產品服務。
1. 維護一份競品跟蹤文檔
競品分析是一個長期、繁重、瑣碎的工作，而不是在剛接觸產品時，寫一份文檔就丟在一邊。維持一份長期的競品分析文檔，保持對競品的關注，不僅可以從中分析競品的策略。競品跟蹤主要從以下三個方面來看：交互變化、功能迭代、戰略變化。
2. 維護一份產品全局文檔
年初我剛接手現在在做的產品時，踩了很多坑，當然現在也還在持續踩。當時幾乎沒有文檔，而僅存的文檔不僅數量稀少，而且過時（跟實際情況有較大的出入）。當時想要知道一個功能的實現邏輯，只能靠自己手工測試，或者讓程序員去查看代碼，效率十分低下。
除了被別人挖的坑埋了之外，我也做過自己挖坑埋自己這樣的蠢事···在做版本迭代的需求的時候，自己是非常清楚上下文和用戶場景，以及在細節處的實現邏輯（要知道在實現過程中，總是會臨時做出一些不在文檔範圍內的小調整），由於調整比較小，所以也沒有體現在文檔中。於是出現了在幾個月後，想不起來當時的實現邏輯的情況···
鑑於以上的慘痛經歷，我開始維護一份產品的全局說明文檔。在這個文檔中說明版本的大致迭代情況、各個模塊的現狀和調整。
在實際情況中，我建議你的產品全局文檔不用寫的特別長，妄想把所有文檔都集中到一個文檔中，我建議你只在這個文檔中說明『變化』和相關文件的地址。
另外，在雲筆記中保存文檔也是一個不錯的主意，這非常利於及時修改和查看。但是切記要備份。
3. 橫向記錄版本：版本的需求文檔
請注意自己的需求文檔的閱讀體驗。
好好寫需求文檔。
好好寫需求文檔。
好好寫需求文檔。
重要的事情要說三遍。如果你覺得這個不夠重要，請你去翻一下產品的歷史產品需求文檔再來說話···
結構不清晰的產品需求文檔，不僅會虐死你的繼任產品經理，還有可能虐死自己。請在寫文檔的時候，務必注意格式，注意錯別字，注意結構。確保文檔語句通順，且能夠完美的表達你的想法。
4. 縱向記錄版本
從時間軸上，記錄每個版本的基本信息和概況與上下文
之前已經說了，對競品的迭代要保持關注。但同時也要對自己的產品的迭代進行記錄。這個記錄包括了每次版本迭代的內容和相關信息，以便於以後查詢。
5. 需求池
維護需求池，而非收集所有需求。
在平常工作裏，你一定都會收到來自很多同事或用戶的改進建議，千萬不要棄置一旁，也不要立馬將需求加入需求池。多和提需求的同學溝通一下，瞭解一下需求的上下文、場景等，從多個維度對產品進行評估，如果需求足夠重要就將它加入需求池。
注意要用多個維度對需求進行衡量，建立上下游都認可的衡量體系。譬如隸屬的功能模塊（不同模塊有不同的重要性和優先級）、緊急性（影響程度）、重要性（覆蓋面）等等。
6. 記錄需求的場景與上下文
這個本來是要歸到『好好寫需求文檔』那裏，但我覺得很重要就另外抽出來了。
我知道需求文檔是給技術部的程序員看的，而大多數情況下他們並不 care 你需求的上下文、場景和合理性，但是，不管他們是不是 care，你都要記錄下需求對應的場景，好記性不如爛筆頭，千萬不要過度信任自己的記憶力。
7. 良好的文件管理習慣
所有的文件，一定要好好管理，分文件夾擺放，定期備份，及時清理。
不經歷一次找不到重要文件的事情，你就不知道好的文件管理習慣有多重要。
8. 指導全局的文案風格文檔
一個產品的文案會出現在產品的各個角落，一個統一一致的口吻，有助於塑造一個優質的品牌形象。而前後不一致、不禮貌、不細心、冷冰冰的文案風格，將會極大的影響用戶體驗。
而最簡單的解決方案是，將文案風格用文檔的方式確定下來。哪怕團隊只有你一個人在負責產品，也一定要寫下來。寫下來，那就是準則。被遵守的機會也更大一些。