互聯網的勝利，是AK47的勝利

05-20

互聯網的勝利，是AK47的勝利

來自專欄商業地震帶

狗叔 2018/05/17

10天前報了個線上產品經理文檔寫作班。一個行業有什麼文檔、誰在寫、怎麼寫、怎麼用，能在一定程度上反映背後的理念，我想上手操作一下，不要限於圍觀。

學了7個文檔：產品體驗報告、競品分析報告、需求池、產品需求文檔、測試用例、項目排期表和項目郵件。粗淺理解，前兩個報告重在認知，後面五個文檔是項目管理工具，產品需求文檔（PRD）具有樞紐地位，是前期認知的凝練，也是項目啟動後的共識規則。

重點聊聊產品體驗報告。從研究的角度看沒有太高深的地方，沒有太獨特的模塊，常用數據來源就那麼幾個網站，有九年義務教育水平就能完成。令我感觸至深的是它的通行性，人人能寫，處處可用。新入行的產品經理以寫報告來熟悉工作，想轉崗跳槽，也常拿報告作敲門磚，是面試的重要一環；一套模式通殺各行各業的產品，快速上手、便捷易用，絕不掉鏈子。

一切都令人想起「槍械之王」AK47。它的身影出現在CS遊戲、香港電影里，出現在前蘇聯硬幣、莫三比克的國旗和辛巴威的國徽上，出現在阿富汗的崇山峻岭、伊拉克的沙漠城鎮和美利堅的暗街小巷中。尼古拉斯·凱奇在《戰爭之王》里是這麼說的：

它是世界上最流行的自動步槍，戰士最喜愛的武器。由9磅金屬和4英尺長木頭製成。它不會壞、卡殼、過熱。就算它被泥土或者沙子覆蓋，還是可以正常地開火。它的使用很簡單，就算一個小孩都可以使用，而且他們的確在使用。

一款突擊步槍讓小孩成為戰士，一款通用易寫的文檔讓小白成為產品經理。在各大產品經理社區，他們都在分享、討論體驗報告，不論剛入行一周還是身經百戰。研究文檔的平民化、共享化，使思想和人才的交流無比高效，我認為這是互聯網行業繁榮的重要因素。

金融業的研究被視為一項專職工作，好比古代祭司，一群特殊的人在研究高大上的東西，也確實湧現了一些縱橫古今、洞穿大勢的人才。但相較互聯網，它缺乏基於標準化文檔的「思想市場」，自然而然形成了「少數人找方向定規則，多數人按規則執行」的中心化模式。在市場不確定加劇的時代，面臨去中心、自驅動小團隊的巨大挑戰。

課程的大作業就是以應聘者的身份寫一篇「微信讀書」App產品體驗報告。我沒能花太多時間精力，不過淺淺地體驗，也感受到這把AK47的力道。

它培養人的整體觀。老師給的模板有七個模塊，包括體驗環境、產品定位、用戶分析、市場分析、產品分析、競品分析、建議總結，以用戶需求為起點，覆蓋了產品的方方面面。有些高階文檔會用戰略層、框架層、交互層等維度來分析產品，至於SWOT之類的分析工具更是人人都用。很多行業都把工作拆成小環節，每個環節嵌入一顆「螺絲釘」，但在互聯網，小白也要心有大局。
它培養人的邏輯感。比如，產品分析要花主功能流程圖，這東西看似簡單，真正上手會發現有大量細節考量。要不要延伸一條支線？要不要加個行動框？流程線怎麼走？畫滴滴專車流程圖時，班上200多號人因為一個細節全軍覆沒：打開App後，要先檢查是否有上一筆未支付的訂單。我們這幫模範用戶怎麼會想到這一點！

把互聯網的勝利歸結為文檔的勝利，邏輯上肯定站不住。我想表達的是，不要忽視工具對工作機制和思維模式的影響，尤其大組織轉型時，工具是最便利的抓手。課程到尾聲時跟老師有一段微信問答，也討論了這個問題，貼在後面作為結尾。

@Bin?老師好~~學完課程後還有幾個問題，擔心晚上答疑工作量大，所以先提出來，請抽空指導；同時也想聽聽同學們的見解。主要想了解文檔相關的工作機制：
一是關於文檔的完備性。除了7種文檔外，還有沒有比較重要、有待學習的文檔？特別是7種文檔之間似有斷點：體驗報告、競品分析關乎認知，另外5種文檔用於執行，認知和執行之間應該還有「決策」，即了解市場和用戶、明確產品定位之後，拍板上馬哪些需求、拒絕哪些需求，決策環節是否也產生一些文檔？（比如用戶研究、可行性研究、會議紀要等？）
二是關於文檔的效力，也關係到決策機制。比如PRD定下的需求，是否要通過更高層的批准才生效？領導能否任意改動需求？如果領導提的需求與產品定位相悖，或者被用戶研究結果否定，產品經理能否（以及如何）拒絕？項目進行中向領導彙報頻率有多高，一般用什麼形式彙報（郵件、交互草圖還是別的）？

@狗叔 我們先來談談產品經理之於文檔以及這個課程的作用，首先，產品經理之於文檔相當於獵人之於弓箭，農夫之於農具，本質上是工具問題。我們去經營一個職業則會有「魂，道，術，器」四個層級的經營心法。您的問題當中我隱約可感覺到有以「器」「行道」，"馭術"的設想，有欠妥之處。再談談本次課程的目的，主要是想通過幾類產品經理經常要面臨的場景，去講解一些文檔，希望大家認知，熟用。談完這些看似虛無縹緲的理論，我再試著來回答你具體的問題：
【問題1】還有沒有其他文檔？答案：有的，比如BRD，MRD，交互文檔，用戶體驗地圖，調查問卷，用戶訪談文檔，甚至會議記錄等等，數不勝數。但是有許多文檔，類似BRD,MRD對於新手PM來說使用場景較少，交互文檔之類的，在很多中小團隊都沒獨立出來，而是直接將交互需求融入到PRD。
【問題2】「認知」與「執行」斷點問題答案：不存在您所說的「斷點」，因為「決策」的過程，通常是在「腦暴」「討論」「分析」「驗證」的過程，而這些過程更注重結果，就是到底聽誰的。很少說，明明得出結論了，還非要拿出一個很標準的決策過程的文檔來。這樣違背互聯網短平快的方法論。除非是特別重大的決策，需要多級彙報，這樣的話，你就寫個PPT吧，沒有標準的論證文檔。
【問題3】拒絕哪些需求的問題。答案：這個問題，其實是一個需求管理的一個延伸。就是需求收集-需求排序-需求設計-需求開發，類似這樣的過程。排序和PK需要整個團隊參與，經過協商，PK，妥協等過程才會最終出來結果。所以這個仍然是一個過程量，不建議再去輸出什麼文檔。而是所有團隊對價值的判斷（商業價值，開發成本，時間成本等）
【問題4】文檔的效力問題。答案：當需求已經到達「PRD」的時候，它一定已經是通過了大家的認可，需要進入開發階段了。而所謂的「審批」肯定是在此之前。有可能會涉及到需求變更，那也是在大家討論認可的情況下，去變更，去更新文檔版本，周知各部門。

【問題5】如何拒絕領導需求答案：沒有標準答案，國際難題。看你的溝通能力，看你自己的反省能力，看你的說服能力。這裡提供一個大概的流程：發現領導的需求不靠譜的時候。首先先自我反省一下，它真的不靠譜嗎？萬一我自己錯了呢？領導可能站在更高更遠的角度去審視產品，而產品經理經常會被所謂的「用戶體驗」耽誤了。其次，自己去論證，最好有明確的數據支持，再去下結論，說領導的需求不靠譜。第三，前兩步都過了，想辦法說服領導，需要技巧，溝通技巧，需求情商。第四，如果領導昏庸，最好的做法，聯合其他部門，看技術或運營能不能用一些緩兵之計，做一些表面上迎合領導，卻不傷害用戶的折中方案。再有就是冷處理，不建議和領導直接衝突。
【問題6】用什麼形式彙報答案：不限定，能達到彙報目的（比如只是讓領導指定進度說明你在幹活，或者需要申請資源）就可以。或者根據領導喜好（有些領導就喜歡PPT，有些領導喜好口頭彙報）總而言之，明白了產品過程的「魂，道，術，器」，不要混淆過程，不要只依賴工具，不要認死理，才能成長。
@Bin 感謝老師指導，反覆讀了幾遍，還要慢慢消化。這些問題與學習初衷有關，想通過文檔實踐來了解互聯網企業的思維和方法，確實也獲益匪淺。非常認同您關於「魂、道、術、器」的觀點，決策最終是妥協、灰度的結果，是博弈均衡點，在銀行內部也一樣。之所以關心器的用法，是因為傳統大機構的組織慣性太大了，光洗腦推不動，免不了要「以器行道」，通過工具來改變工作機制，進而影響思維。再次感謝，希望有機會作更高階的學習。