如果我知道我會死在哪里，我就一定不會去那個地方。

——查理·芒格

對于很多工作1-2年的產品新人來說，可能在不知不覺中就已經踩過了或者現在就身處“坑中央”，希望本文以下的內容可以幫助你脫坑或避免踩坑。

中臺產品的四個坑

1. 基于系統1設計“一次性”產品方案
2. 脫離業務場景定義產品邊界
3. “照抄”思維
4. 解決方案的執行者

避坑指南

1. 基于產品“慢”思維，設計可“成長”的產品方案

丹尼爾·卡尼曼在《思考，快與慢》一書中提到人大腦中有兩個系統：系統1和系統2。

無意識的系統1依賴情感、記憶和經驗迅速作出判斷，它見聞廣博，使我們能夠迅速對眼前的情況作出反應。但系統1也很容易上當，它固守“眼見即為事實”的原則，任由損失厭惡和樂觀偏見之類的錯覺引導我們作出錯誤的選擇。有意識的系統2通過調動注意力來分析和解決問題，并作出決定，它比較慢，不容易出錯，但它很懶惰，經常走捷徑，直接采納系統1的直覺型判斷結果。

對于有1-2年工作經驗的中臺產品來說，對于自己所負責的系統/工作有了一定的了解，可以相對靈活面對業務方提出的需求了，在這個時候，很容易出現基于系統1去解決問題的場景，基于產品的直覺和慣性思維解決當前的業務問題。

按照這種方式，也許當前的問題解決了，需求提出方也比較認可產品的解決方案。但是在后續的業務擴展、復盤時，會發現當初的產品方案是“一次性”的方案，只能解決當時所面臨的業務問題，在后續需要擴展的時候，當初的方案完全無法復用，如果需要擴展只能推翻重來，對于開發、測試成本、產品設計成本，都會成指數倍的增加。

那么如何避免系統1影響產品方案的決策呢？

有兩個簡單方法：

（1）在需求分析階段，得出需求分析結論后再問自己一個問題：這個需求產生的本質原因真的是自己分析出來的這個問題么？如果不是，是不是可以再挖掘一下更深層次的原因，到底是什么導致了當前問題的產生？

（2）在方案設計階段，產品方案完成后再問自己一個問題：這個方案可“成長”么，即這個方案具不具備后續擴展性，針對未來可能出現的場景，當前的方案能否輕松應對呢？這個方案是否可以在未來形成一種對外的服務能力進行輸出呢？

回答完上述兩個問題，理論上你設計的產品方案就具備成長性了，但是能成長多少，還是和每個人的經驗、認知有一定關聯性，如果對自己回答問題不滿意，可以尋求有更多經驗的產品的幫助。同時在日常實踐中學會思考、復盤與總結，可以幫助你更好的提升可“成長”產品方案設計能力。

2. 基于業務場景，定義產品邊界

當需求方提出一個需求：需要實現一個功能或者一套完整流程的時候；很多產品經理來會定義這個功能歸屬與哪一個系統模塊，然后由這個業務模塊的產品經理去承接；基于功能定義產品邊界，是ok的。但是，在業務場景沒有清晰，業務流程沒有明確前，先去定義這個功能放在哪個模塊去做是不適合的。

為什么這么說呢？

不管是系統也好，產品也好（本文中產品主要指中臺產品），都是為業務服務的，是將線下業務的線上化，本質目的是通過業務系統化、流程化提高原有線下流程的效率，如果拋開業務場景聊產品設計方案，那么即便做出來一個很好用的功能或流程也可能是和業務場景不契合的，這樣的方案也不會是完美方案。

業務模塊的職責需要有明確的邊界，即什么模塊需要承擔什么樣的角色。但是在涉及到業務流程的運轉、系統模塊的交互上一定要貼合實際業務場景，基于業務流程決定系統間的交互流程，不能因為當前這個業務流程實現的業務場景，與自己所負責的模塊沒有關系就抱著一副事不關己高高掛起的態度。在設計產品方案上，要兼顧產品邊界與業務場景兩個方面，保證產品方案是符合業務的、是合理的。

3. “原樣照抄”與“重新做”的權衡

這里說的原樣照抄，其實有兩種場景，一種是你的產品沒有一個功能，但是競品有，需求提出需求也要有這樣一個功能；另外一種是內部業務的融合，涉及到兼并另外一條業務線，在兼并過程中，原有業務線的業務邏輯、功能、流程是不是原樣照抄過來就可以了。

這兩種場景其實都會涉及是“原樣照抄”還是“重新做”的權衡，在做決策前，一定要對原有功能、邏輯、流程有充分的調研和分析，即為什么要這么做，這么符合當時的業務場景，但是對當前的業務場景同樣適用么？只有對競品或者原有業務有充分的分析，才能知道這個邏輯是保持不變還是要重新做。

如何判斷哪些重新做，哪些原樣照抄呢，這里給出幾個參考條件：

（1）原有功能/邏輯/流程是否有時間、空間上的特殊性，還是普適方案；

（2）原有功能/邏輯/流程是否具備對當前或未來業務擴展的支持能力；

（3）原有功能/邏輯/流程是否足夠簡潔，是否可以繼續精簡，達到效率的最優。

充分了解原有方案的優勢與劣勢，并結合當下以及未來的發展訴求，做出正確的權衡。

4. 做有獨立思維的產品，而不是方案的執行者

剛工作1-2年的產品新人，缺乏獨立產品思考能力的時候，往往容易遇到兩類問題：與技術溝通產品實現方案時，已技術提出意見作為最終解決方案，不思考方案合理性。在與業務方溝通需求過程中，被動接收產品方案，不做設計而是單純執行。

這兩類問題都是我在與產品新人打交道過程中發現的，技術同學在開發代碼過程中考慮的是開發的復雜性以及實現成本的最優化，但是這種實現不一定是符合業務場景的或者現實邏輯的。

以一個電商類平臺都會遇到的用戶申請發票的場景為例：用戶在商品訂單詳情頁申請發票時，進入發票填寫頁所需要展示的信息需要從商品訂單詳情頁代入。但是開發為了減少代碼開發復雜性，向產品提出在進入頁面前調用發票詳情接口查詢需要代入的信息，產品沒有思考就同意了這種方案。

這個方案合理么？

無論是現實世界還是線上業務場景，如果一個訂單都沒有申請發票，就不會存在發票詳情頁的概念，這個現實業務場景和開發實現方案完全背離，很明顯不合理的實現方案，對于產品經理來說竟然沒有發現，這是非常不應該的。

再來說產品方案執行者，從產品經理崗位職級描述上來看，執行者應該是產品助理，在沒有獨立產品規劃能力前，根據產品經理規劃的方案去執行。但是對于產品經理來說，不經過自己思考和設計，直接做一個方案的執行者，這種方式是不可取的，這種方式永遠無法讓你提升。

產品經理最大的能力體現就是將需求經過自己的設計、規劃形成產品落地，如果把這最重要一步省略了，那么你也就失去了做產品經理的意義。

這四個容易踩的坑是筆者基于產品工作中與產品新人溝通或對自己以往工作復盤的思考與反思中總結得來，希望可以幫助你盡可能的不要踩坑，產品經理就是在不斷填前任留下對的坑，多實踐多思考多總結，踩坑不可怕，可怕的是同一個坑踩了很多次。

#專欄作家#

記小憶，公眾號：PM龍門陣，人人都是產品經理專欄作家，OTA中后臺產品經理。

本文原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自?Unsplash，基于 CC0 協議