面對變化的環境和襲來的各類浪潮，產品經理要怎么把握確定性，穿越周期？或許最根本的事情，就是把基本功練扎實。那么，產品經理需練好的基本功有哪些？產品經理又該如何培養基本功？不妨來看看作者的總結。

不可否認，大多數行業都存在生命周期，互聯網也不例外。

于是產品經理的命運也隨生命周期而浮動。

2015年移動互聯網紅利期，大家認為產品經理是CEO的后備軍；

2019年互聯網下半場言論開始興起后，產品經理的熱度似乎有所減退；

到最近兩年，大環境下的裁員潮，開始讓更多產品經理開始討論起「新出路」這個話題。

身在漩渦中，自然也能感受到一些微妙的變化。

在宏觀層面，招聘需求的銳減是直觀的。

前段時間，我字節的小伙伴跟我說，他準備跳槽，試著在網上掛了簡歷，本來以為先拿一些面試機會練練手，最后發現幾乎沒有hr找他，這跟他上次跳槽形成了鮮明對比。

在公司內部，晉升周期變長，普調逐漸取消，專家崗大頭兵明顯增多，低P員工生存環境越來越卷。

在個人層面，副業、個體、身心靈等話題吸引了越來越多的人。

我總覺得，似乎大家忽略了對工作本身的研究。產品經理曾經被傳得很厲害，但它終究是一份工作，是工作的話就有它的基本功。

雖然很多想找新出路的產品經理，因為找不到路而焦慮，那在焦慮的時候，是不是更應該專注基本功的修煉，尤其是那些不被重視過的基本功。

01

產品經理到底在創造怎么樣的價值，這是我們應該去思考的第一個問題。

我的理解是，產品經理完成了產品的第一次創造。

任何新事物從無到有，無非經歷兩個過程：規劃和實現。

規劃屬于第一次創造，主要是想好怎么做，可以是建筑圖紙、可以是腦海里的想法、可以是原型圖、也可以PPT。

規劃的目的，就是在當前和目標之間規劃一條路徑，并想盡辦法證明，按照這個路徑走，就能實現目標。

實現屬于第二次創造，按照規劃好的路徑，以各種現實中的方式去實現目標。無論是工程隊造房子，還是工程師焊接電路，或者是程序員編程，最終都是實現了第一次創造的結果。

當然，這是理想情況。

事實上，規劃和實現間可能有巨大的差異，也可能在實現過程中不斷調整最初的規劃。

但不管怎樣，新事物的創造離不開這兩個階段。

對產品經理來說，每天都在「創造新事物」打交道。

無論是一個完整的產品，還是產品中的一個模塊，甚至是一個很小的需求。產品經理都會負責它的從0到1 —— 也叫做功能上線。

而在這個創造過程中，產品經理尤其要對第一次創造負責。

需求調研、競品分析、方向討論、方案細化，直至最后的需求文檔產出，一切的一切都是為了形成一個共識——這個需求應該怎么做。

是的，產品經理最核心的交付物，需求文檔，就是為了明確所有人的共識：關于這件事應該怎么做。

后續設計師會依據需求文檔進行交互和視覺設計，軟件工程師會依據需求文檔進行編程，一旦共識有問題，就會影響后續的所有工作。

02

基于上述這個答案，我們可以得出產品經理有幾個非常重要的能力象限。

首先是對業務的理解，確保是沿著正確的道路在做事情；

其次是基于用戶體驗的審美能力，保證產品是友好易用的；

接著是項目管理能力，確保工作成果可以按時交付；

最后是數據分析能力，確保以正確的方式去分析產品的迭代。

除此之外，還有一些軟性能力，溝通能力、學習能力、同理心等等。

但今天我并不想討論它們，況且討論它們的文章太多了。

我想聊的是一些非常實在的東西，這些東西存在于產品經理每天的工作中。

我曾經問過一些研發和設計師，在他們的職場經歷中，合作過特別愉快的產品經理都有什么樣的共性呢？

我以為會得到一些與上述幾個能力象限相關的評價，但最后發現，得到的答案都非常具體：

首先，需求單能寫得清楚和明白；其次，該考慮的點都可以考慮到，別漏東西。

初聽起來，這樣的要求也太零碎了吧，但細想，這樣的要求真的很難啊。

回到那個問題，產品經理本質上做的就是第一次創造，他們給下游同學直接交付成果就是需求單。

清晰而完備的需求單，就是產品經理做好的作品。

進一步的，我在想，無論外界對產品經理或者互聯網多么看衰，踏踏實實地寫一份清晰而完備的需求單，應該是產品經理關注的首要工作。

再聯想到馬斯克收購推特之后，現場檢查研發高管們的編程能力，我堅定的認為：

環境越是波動，越應該修煉好那些不被看重的基本功。

03

在具體介紹這些基本功之前，我想再聊聊，如何衡量產品的第一次創造的價值。

我的答案是，減少二次創造過程的損耗。

很多人問，為什么不是看數據呢？

因為我漸漸發現，產品經理無法100%決定產品的數據表現。好的數據會依賴于「老板想清楚了」，依賴于「運營給力」，甚至有時候依賴于一點點運氣。

但二次創造過程的損耗，卻是產品經理幾乎可以100%決定的。

如果你是開發、設計、運營，你有沒有覺得，跟某些產品經理配合得很舒服，幾乎無需太多來回的拉扯，但跟某些產品經理合作得就很痛苦，不是這里表達不清楚，就是那里邏輯不正確。

俗話說，盡人事、安天命。

產品經理的「人事」，就在這「規劃到實現」的路程上。而這個過程，100%體現了產品經理的基本功。

04

第一項基本功，是產品方案表達清晰，沒有歧義。

有人會覺得這也太小了，值得說么？我覺得太值得了。

記住，一次創造的最大問題，在于它并不具體，一個不具體的東西，1000個人就可能有1000種理解。

有時候我們作為產品經理，看著自己的需求文檔，以為說得很清楚了，但拿給其他人一看，可能理解完全不同。

舉一個最常見的例子，微信公眾號文章左下角有閱讀數據。如果當初設計這個文章詳情頁的產品經理這么描述：在這個位置（位置在圖示中說明）展示文章的閱讀數據。

僅僅這一句話，就有如下需要明確的問題：

1. 閱讀數據是指閱讀人數還是閱讀人次？
2. 數字展示到底是如何展示，非常大的數字也需要精確展示么？（現在我們知道，微信公眾號創造了10萬+這個概念）
3. 數據更新機制是怎么樣的，是每次刷新都去獲取一次數據，還是每天定時更新？

當然，在實際研發過程中，可能還會有更多問題。

有人會問了，既然我已經創造了微信公眾號這個偉大的產品，還有必要摳這些細節么。

有，非常有。只有把這些問題都想到了，都定義清楚了，才是真正交付了一個作品。有時候，對于細節問題的定義，在我眼里甚至是具有美感的。

畢竟，代碼是不含糊的，不清不楚的東西，在代碼那里，是要出問題的。

05

第二項基本功，是方案閉環，不出現邏輯錯誤。

在美團內部有一句名言，所有問題的解決，第一步都是「解」。所謂「解」，就是分解。做好分解，后面就會順利得多。

我們都知道，分解的原則是MECE，不重復，不遺漏。

不重復確保唯一性和確定性，不遺漏確保閉環。

舉個例子，如果某個資源位要實現分層運營，針對不同用戶的身份跳轉不同頁面，那么在方案的考慮上就一定要考慮到所有身份，不能有遺漏。

例如：普通用戶，會員用戶以及未登錄用戶。

我看過一些新人產品經理的需求文檔，經常會遺漏掉未登錄用戶。

負責任一些的研發，會默認給你做一個邏輯，未登錄用戶點擊資源位時自動喚起登錄。

如果這個研發就在這里寫了一個邏輯：未登錄用戶點擊后報錯。你可能會覺得這個研發腦子有問題，但要我說，還是因為你作為產品經理，沒有考慮到所有情況，導致邏輯沒有閉環。

不重復的情況很少發生，但也會有。

例如在需求文檔的前半部分說，這個資源位點擊后跳轉A頁面，后面又說點擊后跳轉B頁面，那在代碼里，就很容易出現問題。

除了這兩個，當然還有很多其他方面的基本功需要去培養。

但我認為，這兩個基本功直接關乎完備而清晰的需求單，是所有其他基本功的前提條件。

如何培養這些基本功呢？

06

首先是無歧義的表達。

必須認清，語言是有歧義的。要消除歧義，那就盡可能用結構化工具去表達復雜的邏輯和信息。

大家都知道，原型圖是一個很好的工具，但原型圖不能代替所有邏輯表達。

例如用戶的登錄邏輯，其實包含了短信服務、發送和驗證，這些在原型圖中是很難清晰表達出來的。

我的建議是，復雜的邏輯盡可能用流程圖表達。

流程圖這個工具，本身就包含了開始節點、結束節點、判斷、分支、串行、并行等常見的邏輯內容。

流程圖的優勢就是可視化的流程走向，一讀就明白?？捎袝r候，產品邏輯沒有那么多縱向節點，但是有很多橫向判斷。

比如用戶在不同身份下，訪問當前頁面時，需要展示什么要素。

這種結構化程度非常高的信息表達，我建議大家多用表格。

當我們用表格的時候，無形中就在做邏輯歸納。表格中的第一行就是維度，以上述例子而言，用戶身份是一個維度，頁面展示要素是一個維度，可能還有頁面交互以及補充說明這兩個維度。

于是一個4列N行的表格，就完全可以表達「不同身份用戶訪問頁面」這個需求點的所有內容，這比一大段文字要清晰多了。

對一個需求文檔而言，圖、文、流程圖、表格，我覺得足以表達很多復雜的邏輯。

但我遇到過的很多情況都是，針對我弄清楚的邏輯，我可以想辦法進行無歧義的表達，但問題往往出在我不清楚的邏輯。

07

這就要說到第二點，如何考慮到所有點，不出現邏輯漏洞。

首先得說，需求文檔不出現邏輯漏洞，就跟代碼不出現bug一樣困難，幾乎是不可能的事情。

要不然測試就不用寫用例了，以及后續的開發過程中也就不會存在那么多的溝通成本了。

但追求無邏輯漏洞的產品方案設計，應該成為每個產品經理的目標。尤其是在增長緩慢的大背景下，產品經理更應該注重修繕屋頂、修煉基本功。

雖然這個目標很難，但并不意味著沒有方法接近它。

我的建議是，多多跟研發和設計溝通，收集他們平時會問到的高頻問題，從而看看你的方案到底哪里有問題。

換句話說，從一個開發者的角度，來進行產品方案的設計，這樣就可以在一開始考慮到盡可能多的情況。

我做過C端產品、也做過B端產品，姑且聊聊我積累的一些設計經驗吧，這些經驗已經成為了我做產品設計時的潛意識。

08

C端產品設計，常見的考慮要素包括頁面和模塊兩個維度。

頁面維度常見的考慮維度：

1）頁面框架是什么，原生、H5還是小程序

2）用戶瀏覽該頁面的條件，游客、登錄用戶、或者是條件更嚴格的其他身份。

3）頁面流，入口有哪些，下級頁面是哪些。在頁面流中，最容易被忽略的是逆向邏輯的考慮。

模塊維度常見的考慮維度：

1）模塊數據源：是后臺傳過來的數據，還是前端寫死的數據，還是系統自動記錄并展示的數據（例如時間戳）

2）模塊內要素的數據源：如果模塊的數據源來自后臺，那就要進一步考慮模塊內的每個控件分別來自后臺表格中的哪個字段。最常見的遺漏是，前端頁面定義了要展示哪些內容，卻發現需求單里沒有定義這些內容到底從哪里取到。

3）字段級別的限制條件：為了美觀的顯示、流暢的加載、系統的容量等，很多字段都需要有限制條件。例如說明文案字數限制、圖片大小限制等。這種限制既包括后臺配置的限制，也包括前端顯示層面的限制，都需要考慮到并明確。

4）兜底邏輯：大多是空數據的處理，包括網絡異常帶來的數據獲取為空，或者是很多初始化場景下帶來的數據為空。

5）逆向操作提示：用戶做一些解綁、刪除等逆向操作時，需要考慮一些提示邏輯，主要是防止誤操作。

09

從后臺頁面搭建的角度看，后臺產品有常見的三個要素：表格、表單和詳情頁。

先說說表格。

表格常見的考慮點包括：

1）表格數據源：展示是哪個對象，這個對象和其他對象之間有怎樣的關聯關系，這是后臺設計第一步需要考慮的問題。

2）表格的字段描述：逐個說明每個字段的含義、數據源以及展示方式。

3）表格查詢區域說明：相對復雜的表格都有查詢功能，往往是基于某些重要的字段做查詢。查詢需要說明，每個查詢控件的名稱、控件類型（選擇類注意單選和多選區分開），查詢方法（查詢控件與表格哪個字段匹配，如何匹配）

4）表格操作列說明：操作列是表格記錄的操作區，一般進行狀態控制或者刪除操作，這部分功能的說明一般帶有邏輯判斷，例如滿足什么條件的記錄會出現哪些功能按鈕。出現這樣的情況就建議用流程圖或者數據表格去說明功能，結構化程度更好。

5）其他功能：包括創建、導出、刷新、翻頁器等等。

再說說表單。

表單是管理后臺產品的核心模塊。任何一個系統，只要涉及到數據輸入，就一定會用到表單功能。

表單常見的考慮點包括：

1）表單字段說明

每個字段對應什么輸入控件、代表什么業務含義，都需要說明。

復雜的表單字段間往往有聯動邏輯，例如單選字段的值為A時展示X輸入框，值為B時展示Y輸入框。

順便說一句，業界已經有非常成熟的輸入控件庫和對應的標準設計，基本不需要產品經理去創造一種新的輸入控件。

2）表單校驗邏輯

這是我見到很多人做后臺設計時容易忽略的部分。數據輸入是一個很謹慎的過程，如果沒有很充分的校驗，會導致數據表中有非常多的臟數據，給后續的處理帶來不可估量的風險。

校驗有兩種，by字段的和字段間有聯動的。by字段的校驗，就是看每個字段控件內的輸入內容是否正確，不正確的話需要定義對應的錯誤文案。字段聯動校驗，就是看多個字段之間的輸入是否滿足某種組合公式。

字段校驗的錯誤文案一般展示在字段控件下方，字段聯動校驗的錯誤文案一般展示在整個字段區下方。

每一個錯誤文案跟一條校驗邏輯匹配，所以邏輯之間往往具有優先級，這一點也記得要說明。

3）表單提交后的工作流

很多人在做表單設計時，只關注字段，卻忘記說明數據提交后的工作流。事實上，我們很多在用的表單，都有其下游邏輯，是提交后刷新數據庫，還是提交后打開另一個聯動表單，或者是提交后打開某個新頁面，這些都是工作流的范疇。

管理后臺設計，跟業務邏輯耦合程度非常高，我曾經不知道該如何梳理要注意的邏輯漏洞，但在字節做過低代碼產品后，我對這塊就產生了肌肉記憶。

所以啊，做產品的每一步，只要好好做過，都算數的。

再次說明，我個人的經驗畢竟有限，如果有更多補充，歡迎大家在評論區友善留言。

10

最后從細致的具體的內容中抽離出來，聊聊我為什么要寫這篇文章。

前面說到，行業是有生命周期的，而宏觀周期的變化，對個體產生的影響是不可估量的。

我見過很多優秀的同學，懷揣著改變世界的夢想做產品，成為螺絲釘之后，滿腦子都是郁悶和抱怨，失去了當初的一點熱情。

甚至身邊有小伙伴正在經歷裁員、失業、不知道下一站在哪里。

吳軍老師寫過聞名遐邇的《浪潮之巔》，但沒有人告訴我們，當我們處于浪潮之谷，甚至被漩渦卷入深淵的時候該怎么辦。

我也不知道怎么辦，但我覺得，這說白了就是一份工作，踏踏實實做好，總結、復盤、改進，把基本功練扎實——

是我能想到的能穿越周期的辦法之一。

在見識、理解、人脈、把握趨勢等不確定性面前，完備而清晰的需求單，是難得的確定性。