不知不覺正兒八經做產品兩年多了，title 也從「顧問」變成「經理」了。但是說來慚愧，似乎從來沒好好復盤過。所以決定小諏一文，回顧一下自己踩過的坑，和一些不成體系的感悟。

1 場景，場景，還是場景

在做產品初期需求評審的時候，boss 經常會打斷我，問我一些問題：為什么做這個功能？為什么要這么做？核心業務流程和場景是什么？有沒有更好的方案？

我時常會被問的捉襟見肘，回答也經常被質疑。幾經磨練后，我悟出一個道理：要立足于真實的場景去看需求。對于 PM 來說，可能「需求」是最重要的東西，然而所有需求都是基于用戶場景的——用戶是在什么場景下、如何使用你的產品，是產品設計師必須不斷思考和牢記于心的一件事。

以那個著名的馬和汽車的故事來說，其本意是想講挖掘用戶真正的潛在需求，但是仔細審視一下，這是一個典型的將「需求」和「場景」剝離的案例。

舉例來說，有個用戶來到馬廄，說要在明天前趕往某地，需要一匹比平常更快的馬。你總不至于說，好的，我們理解您的深層需求，請您耐心等待十年，我們會研發出一種叫「汽車」的機械載具，來滿足您的需求。

當然，和缺少背景的原故事一樣，這只是一種寓言式的簡單敘述。實際的情況，往往比這要更復雜。

我之前做過一個客服知識庫的項目，業務提出說，在服務客戶時，客服如果要查詢知識庫內容，需要切出操作頁面，在新頁面中打開知識庫，搜索內容。為了提升客服處理效率，想在客服操作頁面上，集成一個查詢插件，方便他們搜索。

于是我們做了這個功能，但是上線一段時間后，發現使用量寥寥無幾，更別提效率提升了。去現場調研后，我發現客服通常會將知識庫的頁面常駐一個標簽頁，遇到問題會非常順手地切過去檢索。在與顧客通話過程中，點開和使用區域較小的查詢插件，反而會影響他們的操作效率。

而之所以會產生這樣的問題，是因為我錯誤地理解了需求的真實場景，把「客服切出操作頁面」的場景和「提供查詢插件」的方案建立了因果關系。

實際上這個需求，真實的場景是：客服在操作頁面上，遇到了某些無法獲取答案的「問題」，導致需要切出頁面檢索信息。那很顯然，找到這些「問題」，在操作頁面上提供相關信息，才是正解。問題是錯的，自然給不出正確的答案。

至于如何把握真實的場景呢，沒有什么捷徑，只能實地去體驗，去做場景觀察和調研。不過當然，充足的經驗多少也能保證方向上的正確。

2 MVP不是造輪子

兩年時間里，我做過最為失敗的一個項目，是一個業務自動排班系統。

業務方對系統的預期很高，希望實現的功能，包括對小時業務量的預測、滿足各種約束條件的自動排班，和員工考勤以及遵時的監控。幾乎每一個單獨功能模塊，都需要克服很多技術難題，而且需要長時間的優化迭代。

但是坑爹的地方在于，項目周期很短，幾乎是趕鴨子上架。我在殫精竭慮了幾個禮拜后，終于拿出了一套自認為行之有效的 MVP 方案。

我先是對業務流程進行拆解，認為「自動排班」是當前最大的痛點，所以準備最先實現這部分功能。我們花了大力氣研究算法，解決運算資源問題，調優運算結果，好不容易勉強達到了「能用」的地步。

然而，上線后的效果卻令人難堪——不僅排出的結果有各種問題，業務在一次試用后，也完全沒有再想日常使用的跡象。

在之后的調研和復盤中，我意識到了問題所在——要把一個完全在線下完成的排班流程線上化，第一步絕不是解決我所謂的「痛點」。提供錄入功能，將信息在不同系統間打通，實現線上流程閉環，在此基礎上，再去提升各環節的效率，進行智能化的應用，這才是正確的產品演進策略。

而我所謂的「MVP 方案」，實際上是造了個輪子，還是個不圓滑的輪子。而輪子不是 MVP，獨輪車才是。這是一個做產品很普遍且常見的坑，但卻被我完美地踩了個遍。

知易行難，干這行真的是體會特別深。

3 技術選型會影響產品形態

產品經理需不需要懂技術，這種「日經」話題被討論太多次了，通常政治正確的結論是：可以不懂，但是懂的話會有很大幫助。但是我的經驗是，對一個合格的 PM 來說，前半句是不成立的。

我有時會聽到同儕與開發之間，發生如下的對話：

開發：「要實現這個功能，可以用 A 技術，但是會有 a 影響；如果用 B 技術的話——」

產品：「哎呀，怎么實現我不管，技術方案你們自己評估。」

開發：「……好吧。」

其實原則上來講，產品出 PRD，技術籍此評估技術方案，這么分工沒什么毛病。但是實際工作中，卻總會出各種差錯。這是因為，通常開發和產品對需求的理解不是 on the same page。

之前我們業務需要上線一個數據分析看板，涉及實時和離線的數據，開發計劃使用 Druid 來實現。Druid 本身是一個成熟的解決方案，但是它有一個弊端——在去重統計時，會有不小的精度誤差。碰巧這個需求對離線數據去重精度要求很高，因為涉及業務的績效和薪資發放。

但是由于負責的產品對技術方案完全不關心，也沒有把「精度要求很高」這樣一個隱性需求傳達到位，理所當然地覺得不會有問題，導致上線后，統計結果離預期偏差很大。而且，因為一開始的技術選型錯誤，改動和修正需要耗費大量的資源。

其實這個問題很容易避免，只需要在評審時，仔細聽一聽開發說的技術方案優、缺點，選擇最符合需求、最能保證產品擴展性的方案。

這點對 2C 的產品也是一樣。比如說，一個前端頁面該用什么框架，不是開發隨便選一個就完事了，會存在諸如：是不是要做成單頁應用，要不要考慮 SEO，等等，影響因素。

所以產品懂技術，不是要真的上手寫代碼（當然懂點 SQL 之類的還是很有幫助的），是需要了解自己產品所屬領域的技術方案，和其優缺點、擴展性。因為它們是可能對產品形態產生本質的影響的。

4 用有限的資源做正確的事

有段時間幫部門負責人一起面試，有些面試者是轉崗的，我通常會問一個問題，你認為產品經理的核心職責是什么。當然，開放性問題，答案不唯一，我自己的答案是：用有限的資源做盡可能正確的事。

如果擁有無限的資源，那做產品太容易了，窮舉所有可能性，都做一遍，選擇效果最好的那個（實際上不少大公司就是在這么玩）。正因為資源有限，做正確的事才顯得格外重要，畢竟產品決策失誤，是會浪費大量企業的人力和財務資源的。

所以有的時候，要敢于對一些不合理的需求說「不」。而且有些事可能看上去無比正確，但是時機不對，資源不到位，就不該去做。

不久前看到蘇杰的一篇博客說「內部乙方沒有真正的產品經理」，深有同感。對企業而言，PM 等級的高低，就體現在他處于產品開發的哪個環節。越是前期，就越偏戰略層，等級就越高。

如果僅僅是做產品架構、系統需求的梳理，是很難觸碰到核心價值的。充其量，只是在打磨戰術。2B 產品的出路，應該是參與業務決策，影響業務決策，甚至倒逼業務決策。如果需求的主動權掌握在業務方手中，產品的價值就會被不斷壓縮。

當然，這點不是僅由 PM 自己所能決定的了，更多的，可能還是受企業管理者的影響。

5 尾巴

四件事說完，好像又什么都沒說，感覺不過講了一些正確的廢話。

但是，總結和復盤，本身是產品工作一個重要而不可或缺的環節。所以，盡管本文可能對讀者毫無益處，但至少于我，寫些來就有其價值了。