提筆畫流程，上馬定需求，進可穩迭代，退可跪開發。

我把產品經理分成四個階段：

1）產品執行&使用者體驗

2）產品架構&技術實現

3）產品決策&產品模型

4）產品格局&社會價值

第一階段：產品執行&使用者體驗

0-2歲的產品er大部分處於這個階段，執行上面的想法，推動產品方案上線落地。這個階段對於產品的好與壞的評判標準，基本是基於自己作為小白使用者的視角。

如何避免在這個階段被開發吐槽：

1.1 想清楚

方案idea可能是上面拍的，但方案細節是你自己定的，想清楚每一個互動細節和異常流，不要說想不全，可以拿著方案先和架構開發測試簡單聊聊。

1.2 寫清楚

寫清楚的意思是每一個流程每一個步驟都寫的條理清晰。拿一個普通的展示頁面來說：

1）流程說明，主流程、分支流程、異常流統統寫明；

2）跳轉說明：點選返回/編輯/儲存/取消等，分別觸發什麼。彈框是怎麼進入怎麼消失的。toast顯示幾秒，
   停留在當前頁還是返回上一頁；

3）顯示規則，這個頁面包含哪些元素，都是哪些欄位，格式大小要求是什麼，是否換行全部展示，
   過長或過短怎麼展示，異常輸入怎麼顯示、空態頁顯示什麼等等；

4）排序規則：第一排序優先順序是什麼，第二排序優先順序是什麼，正序還是倒序排列等等；

5）分頁規則：一頁最多展示幾個，一次拉取幾個。下拉還是上滑重新整理，是全頁重新整理還是半頁還是指定區域刷。
   等等等等………這還只是一個普通的前端展示頁面，涉及後臺邏輯的細節可以寫的更多。
 

*

建議：把評審會上被開發問住的點都記錄下來，整理起來，以免下次寫文件有所遺漏。同時可以多看看身邊優秀的產品經理寫的文件。

*

1.3 講清楚

每次開發評審少則7、8人，多則30多人，緊張怯場一次兩次可以諒解，長此以往就要反思自己。聲音是否洪亮，是否照顧每個聽眾的反應，是否準備充分，把該強調的細節都強調了？

文件要寫的條理分明，評審要講的邏輯清晰。例如：這個頁面涉及哪幾個功能，需要哪些開發支援，主流程是什麼，異常分支是什麼，特殊的規則和要求是什麼。

*

建議：自己講完可以邀請關係好的開發複述一遍，就知道哪些地方要著重再講一遍。另外，多觀摩觀摩別人是怎麼評審的。

*

1.4 溝通溝通

溝是方式，通是結果。結果不對，方式肯定錯誤。那什麼是好的溝通方式？不卑不亢。

產品經理和專案組所有人都是平等的，你不是指揮他們幹活的，也不用刻意討好。平等的意思是，發自內心的尊重，耐心聆聽的理解，相處自然舒服不添亂。

剛入行時，向技術提需求也會買零食請吃飯撒嬌賣萌。後來漸漸發現，最佳的“討好方式”是成為一個靠譜的產品經理。

第二階段：產品架構&技術實現

之前有個同事，是清華計院畢業的產品er，他曾笑言，某次提需求時，開發說實現不了，他當場指導開發怎麼去寫程式碼 = =！
聽得我好生羨慕，吭哧吭哧跑去學html學python，走了不少歪路。

產品需要寫程式碼很牛逼麼？不需要。產品需要懂技術實現嗎？需要。

這是兩回事，一個優秀的產品經理不需要會寫程式碼，但要清楚技術的實現方案，以及，能夠從業務角度，專業的回答很多個為什麼為什麼。

建議：

1）每次需求評審完，技術們都會私下再碰定下介面。產品er為何不索性再拉個技術方案評審會，聽下前端
  客戶端服務端是怎麼商量確定介面，一來了解各自分工，二來了解資料流轉。別覺得開發定介面和產品沒
  關 系，這直接關係到產品實現的互動細節。

2）大公司的產品er估計拿不到線上資料庫許可權，但可以私下找開發要開發環境或測試環境的資料庫許可權。
   要了資料庫許可權，不是用來裝逼的= =！ 請看下你所負責的專案，共涉及哪些表哪些欄位，這些資料的呼叫、流轉、更新是怎麼樣的。

*

以上，簡單來說，①看看API文件；②看看資料庫表結構；③看看架構圖；④聽聽開發講下各系統的依賴關係。

*

第三階段：產品決策&產品模型

這一塊是我至今都沒有吃透的，只談談自己近期的體驗。

3.1 怎麼確定具體功能？

1）多研究競品和優秀的app，把appstore各個類目榜單前20名的app，都下載體驗一遍。並問問自己，
   這個app吸引自己的是什麼？

   它核心使用者和場景是什麼？

   它的缺陷和不足是什麼？

   怎麼優化？

   產品經理如果能做到多問自己為什麼，並且都能給自己一個滿意的回答時，就離靠譜不遠了。

2）多和一線業務人員溝通，最好能親身體驗幾天。例如做客服系統的和客服聊，做O2O業務的和運營、
   銷售、B端合作方聊聊。注意，聊天過程，他們經常會習慣說“我要XXX功能”，產品經理要做的是
   引導他們說出他們背後實際碰到的問題，去想方法解決他們的問題，而不是去執行他們提出的功能。

3.2 怎麼做產品決策？

通過優先順序去決策，如何判斷需求的優先順序？用成本收益比去衡量。就是這麼簡單粗暴。一個需求上線後能產生多大價值，完成這個需求需要多大的成本。

成熟期的前端型產品優先順序可能會根據運營的階段和規劃，即使是運營的規劃，也是這次運營活動能帶來多少資料，而資料就能折算成收益，上線運營活動的人力時間就是成本。

3.3 什麼是產品模型？

我在上一家公司時，只做線上產品，純前端體驗型產品，我那時候覺得，專案成功的決定性因素就是“產品做得好”。後來我跳槽來了現在這家公司，開始接觸O2O業務，我忽然發現，專案成功的決定性因素是“產品運營做得好”。現在，這個O2O業務已經上線跑了一陣，資料不是很好，我才意識到，專案成功的決定因素是“產品模型要搭建得好”。

什麼是產品模型？我很贊同純銀v的一個理論：產品模型=商業模式+產品架構+運營體系。

怎麼理解？每個專案在上線之前，它會死還是活，它生命週期的上限，盈利能力的上限，產品資料的上限，基本都已經敲定了。產品運營最多隻能優化到無限接近於這個上限的理論值，除非市場發生突變或新技術產生，否則絕無可能超過這個上限理論值。而這個上限理論值就是由專案的商業模式決定的。

再舉個更具體的例子，同事之前創業做過一個專案，是智慧硬體，關於兒童體溫計。上線3個月銷量過萬，毛利潤算20*1w*4=80w/年。單個硬體20元利潤算不錯了，銷售資料對於新產品來說也不錯了，但一年80w足夠麼？完全無法cover產品研發以及後期迭代和維護的成本。毛利潤80w/年，按淨利潤算，一年就要負幾百萬了。

而他們團隊的目標是一年淨利潤5000w，即使這個智慧硬體的工業設計多棒，對應的APP使用體驗多好，運營多用心，這個5000w的目標能達成嗎？按照目前這個細分市場對於兒童體溫計的需求強度和頻次，是絕對不可能達成5000w/年的淨利潤。不算研發銷售等人力成本、辦公成本以及渠道分成等，哪怕是5000w的毛利潤，也至少要20w的月銷量啊。而兒童體溫計這個市場，目標使用者群不超過3億，其中城市使用者大約1億，再除去傳統水銀體溫計、品牌體溫計、各類測溫儀等競品，還有社群醫院、小門診也會拿走一部分使用者。剩下的使用者能支撐20w的月銷量嗎？再者，兒童體溫計屬於一錘子買賣，復購週期極長且復購率低。

小米手環也是個很好的例子。毛利薄，79元的售價幾乎接近工業成本。需求強度低，核心功能是計步和睡眠，還有心率、來電提醒、鬧鐘等輔助功能，不算強需求。需求頻次低：長期帶手環超過一個月的人很少，所以小米運動APP留存低，使用者粘度差。市場小，競品和可替代產品多。所以這個產品專案永遠也無法成為獨角獸，甚至無法依賴自身而完成商業閉環，只能依附小米手機以及其他智慧家居，成為整個棋盤裡某一顆棋子，有點像是“兵”，“帥”需要時“兵”要衝鋒，必要時就犧牲。

這兩個例子，其實想強調的是，產品模型最核心的是商業模式，其次才是產品架構運營策略，而這個才是優秀產品經理真正的價值。

第四階段：產品格局&社會價值

第一階段和第二階段，只是產品經理對使用者價值的體現。

第三階段是產品經理對商業價值的體現。

那第四階段才是傳說中能改變世界的產品經理，有理想有情懷有眼界有格局，手中的產品專案已經不僅僅考慮使用者價值和商業價值，而更在乎它有沒有產生正向的社會價值，例如滴滴改變使用者出行習慣並創造300w就業機會，淘寶推動零售業、流通業、製造業的鉅變並催生各類新行業，這就是一個產品對社會的價值。