起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識“352”陣型：從足球陣型看工作流程
筆者重回產品經理學習之路，對產品經理工作流程有了新的思考和見解，“剝洋蔥”式工作的產品經理，該如何抓住工作重點并做出成績呢？
“352”是綠茵場上常見的一種陣型，其特點在于構建強大的中場形成局部優勢，通過提升中場控球率有效銜接前后場，實現攻守兼備的效果，進而幫助球隊達成比賽勝利的目標。
產品經理不同的階段雖然要求不同，但是都會面臨一個同樣的問題，要干的事情又多又雜，非常容易迷失方向，不是抓不住重點，就是工作中有所遺漏給團隊挖坑。
筆者通過對產品經理日常工作內容的梳理，結合足球陣型提出了產品經理工作流程的“352”陣型。
一、什么是流程？
產品經理就像是一顆洋蔥：每天我們要處理大量的雜事，和各個部門的同事溝通（sibi~）、各級別的boss溝通（baodatui~），還要各種寫寫畫畫，時間稀碎一地。沒有一套抗打的工作流程做指引，很難保證既有側重又不遺漏地完成工作任務。
產品工作所需要素
在正式討論流程之前需要拉一拉認知，當我們要完成一項工作任務的時候，其實需要的不只是流程一個方面。
比如很大一部分的產品經理每天的工作時間超過50%都在進行各種溝通，但是一方面大多數溝通本身更多的是隨機產生的，并非一個固定的工作。
常見的場景可能是文檔中的細節沒有寫到，前端直接跑過來問細節，又或是技術可行性需要和項目經理溝通，等著那個PM有空了自己顛顛跑過去請教問題。
另一方面溝通本身是一種技能或底層的素質，并非流程。想要完成某一項工作任務，僅僅懂得工作流程是不夠的，還需要知識、技能；底層素質；驅動力等等多個方面。
本文想討論的問題聚焦在流程方面，那么問題來了：到底什么才是流程？
流程是事物進行中的次序或順序的布置和安排；或指由兩個及以上的業務步驟，完成一個完整的業務行為的過程。
上述是百度百科對流程的解釋，我個人的理解，想把握好流程有如下的重點：
- 有固定的次序，但并非是線性思維（eg：畫流程的時候并非不能做原型框架，實際情況往往是做了框架反而流程更清晰了，同理需求和功能也一樣）。
- 流程本身的構成步驟之間的先后順序一定要合理配置，流程才可執行（eg：沒有流程圖，根據需求直接設計功能，根據功能直接就畫原型會把所有人逼瘋）。
二、產品經理工作流程的“352”陣型
2.1 “352”從何而來？
“352”從流程當中來，它本身就是做產品必備的流程，是一個個子流程的歸納與精煉。而子流程又是從產品經理的一個個繁雜的具體工作內容當中來，產品工作內容的繁雜從下圖就可窺探一斑：
5篇高贊產品工作內容的詞頻圖
不過產品經理的工作雖然雜，但是通過詞頻圖就可以清晰的看出來“需求”其實產品經理工作當中的核心。
那么圍繞著“需求”，再根據“時間”從前至后進行排序就是最常見的產品工作流程。
《人人都是產品經理》、《產品經理的20堂必修課》等入門框架書都是圍繞著“時間”順序來對產品經理的工作內容進行闡述的，更多的細節可以直接去翻經典書。
我這里必須要提到的是“函先生”的《寫給迷茫的產品新人：產品經理工作體系》這一篇文章?！?52”的流程圖也是在“函先生的流程圖的基礎上進一步歸納總結而來。流程圖的講解函先生已經做得非常細致了。手動給函先生點贊~
函先生的流程圖
2.2 已經有現成的工作流程為什么還需要“352”？
因為環境的改變，原有的流程很難滿足現在的產品經理工作需求。
一方面，不同公司、行業、階段的產品經理日常工作內容雖然有挺大的差異，但大家都是從基礎的功能點調研、畫原型等工作開始的。隨著產品能力的不斷提高，工作的重點會慢慢向需求的把握，產品的定位，團隊的管理進行過度。
但產品工作的流程本身也具有階段性，圍繞著“需求”產品的工作流程毅然而然會形成“需求管理”、“需求轉產品”、“產品反饋”三個階段。而這三個階段是固定的，不會輕易改變的。
因此伴隨著產品經理的成長以及行業的變更，線性的工作流程必定需要跟隨變化，如果不能及時調整，會出現不適應的情況。
另一方面，現在市場環境的變化，倒逼產品經理必須調整工作的側重點。5年以前，誰能做移動端的產品誰就有市場；3年前，誰能把握良好的用戶體驗誰就是好的產品經理。
但是現在互聯網的下半場，宏觀經濟的不確定性，功能交互的確定性，大數據、AI的新技術推動都在指向兩個方向：
- 產品數據化
- 產品運營、市場化
說白了你要么能通過數據能力幫公司賺錢，要么你就要有能力通過數據幫公司省錢。兩樣都不占的話，你很難拍胸脯說自己是一個好的產品經理。
我最近統計了薪資排名前100的幾個招聘渠道的JD，“數據”、“中臺”、“用戶增長”是出現最多的幾個產品類型，這就可以說明現在的趨勢，因此對于大多數產品經理而言如果還是用以前的工作流程，容易忽視新趨勢。
2.3 分享一下自己用過的產品工作流程
1. 線性工作流程
根據書本將產品的工作內容進行模塊化的拆解，一步一步線性地去完成產品的工作。好處是通過線性的指引，了解了產品的工作內容，打基本功。但是缺乏靈活性。
2. 以“戰范構架表”為一級分類，準線性的工作流程
好處是能很好地以用戶為中心設計產品。但缺陷是過于關注用戶體驗，而忽略了宏觀的思考。
3. 圍繞需求的三段流程，“需求管理”、“需求轉產品”、“產品反饋”
之前由于轉到TOB的崗位，沿用“戰范構架表”的流程框架各種不適應。
舉個簡單的栗子，做用戶體驗的C端產品經理，只需要考慮用戶的需求（當然還有BOSS啦~）。
但是，TOB的產品經理需求方多到令人抓狂，經常遇見客戶方面財務和市場打架的情況。這個需要產品經理對客戶公司的組織架構了解，對客戶的業務流程熟悉，還要懂利益，懂人性。顯然不是簡單的一句“以用戶為中心”就能解決問題的。
改為三段流程后，雖然多了更多的宏觀思考，更多的靈活性，但是對產品本身的關注度卻有所下降，離“產品經理”漸行漸遠。
三、“352”產品經理工作流程的特點？
3.1 精簡，但重點突出
精簡不多說了，再啰嗦兩句我認為的重點：
1. 需求是“基礎”
球迷應該都理解“防守”對于一支球隊的意義有多重要。這一點最好的說明就是號稱“橙衣軍團”的荷蘭隊，攻式足球觀賞性足夠強，是人氣最高的幾個球隊之一，但其從來沒有得過世界杯的冠軍。
同理，如果產品對“需求”方面的把握不足，就如同荷蘭隊一樣，即便你做的產品交互視覺再炫，最終也很難得到用戶和市場的認可。
2. “需求到產品”的轉化是“核心”
還是拿足球類比，“352”陣型的邏輯是構建強大的“中場”以中場的優勢去獲取比賽的勝利。
同理，“產品經理”之所以叫產品經理，產品的設計、發布、上線等保證需求轉化為產品的相關工作內容，永遠都是產品經理工作的重心。
不論不同的公司、團隊對于產品經理職責的限定，還是產品經理自身所處的階段，對于產品質量的把控是產品經理之所以能夠被成為產品經理的原因。溝通再頻繁，管理的比重再大只要還是“產品經理”的頭銜，不要忘記初心。
3. “以終為始”，數據要“貫穿”整個產品工作的流程
“352”球場的右側是基于數據分析的不斷迭代，數據是這個時代的趨勢。
無論是否愿意接受，基于運營、市場的最終數據分析能力，是接下來產品經理崗位必須熟練掌握的技能。具體掌握到什么程度，不同的公司和業務肯定有所差距，但是方向和趨勢確實顯而易見的。
產品經理除了日常的工作，一定要通過“數據”這個“GPS”時刻觀察產品的表現，及時作出調整。要將自己變成足球場上的“教練”或者“門將”，要能夠通過數據冷靜、客觀地進行分析。
3.2 可擴展性
“352”每一項都可以進行再分解，每一項需要學的東西都非常的多。但有框架流程的指引，可以保證在進行產品工作的時候不會過于陷入細節，也不會遺漏重要的工作模塊。
同時，在需要擴展子流程的時候，“352”也能幫助定位，理清思路，提高擴展流程所需知識技能學習的速度。
3.3 “352”符合閉環
其實“閉環”這個詞不知道為什么我一直感覺挺難理解的，“PDCA原則”，“良性循環”，“可持續發展”，“學習、實踐、總結”其實個人感覺與“閉環”說的都是差不多的意思，反而更容易讓人理解。
最后，由于筆者最近兩年離開產品經理崗位，“352”來源于近期重新學習產品經理相關知識，梳理流程過程中的思考，不足之處，歡迎大家評論里拍磚，共同探討。
本文由 @MR.魏氏 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
然而遇到的更多是首發451，指望著穩固陣容，適當防反偷一兩個，從開始就以弱示人，過度信賴單前鋒個人能力……于是當球隊落后時候，想要加強進攻的時候，沒有合理的預備方案。
是雙邊提上去變433，還是撤一腰加一鋒變442也沒想清楚
更可怕的是單前鋒一直壓著向前，不愿意回接中場，5中場里面沒一個能持球向前的，依舊按教練開場說的那樣橫向分邊或者橫向轉移
于是，單前鋒掉入后衛包夾中
雙邊翼衛眼看禁區內就一個點還特么45°直接吊球，畢竟突不進去，邊后衛又懶得插上
所以，教練不會臨場變化，也沒預備方案
球員依舊只做自己認領的工作，該咋踢就咋踢
更可笑的既不像出力，又不得不累的要死
另外單前鋒還是個大獨逼
方法很新穎，寫得很好，可以多向足球那邊類比，這樣就讓人容易記住了。
好的，謝謝您的建議，以后再有機會分享這個想法時我會再想想和足球之間找共通點。
歡迎再給些具體的建議。
一直感覺產品經理更像是干了主教練的活，卻沒有主教練的權利，卻背了主教練的鍋。不僅要懂產品技術（足球戰術），還要懂人際（與球員溝通、與老板、媒體的溝通），最后不管你過程做的多好，只要是輸了比賽，就要背鍋了
哈哈哈，好像是這么個道理。只能讓自己更強大。
不過贏了的話，產品經理的光環也最大，沒有人會記得干累活的程序員的名字。沒有免費的午餐，只能自己逼自己更優秀，這個感覺就是產品經理的宿命。