[譯] 產品管理思維模式適合每一個人

• 原文地址：Product Management Mental Models for Everyone
• 原文作者：Brandon Chu
• 譯文出自：掘金翻譯計劃
• 本文永久連結：github.com/xitu/gold-m…
• 譯者：EmilyQiRabbit
• 校對者：zhmhhu

思維模式是對複雜的過程和關係的簡單表達。這些模式會隨著時間的推移由個人逐漸積累，並能讓人作出更快更好的決策。

一個例子是：帕累託原理（Pareto Principle）指出，大約 80% 的產出來自 20% 的努力。

在產品管理的語境中，模型建議你應該更希望尋找如何付出 20% 的努力解決 80% 機會的方法，而不是去試圖創造 100% 的客戶機會。產品團隊在一直權衡這一點，結果通常看起來像是特性發布後，20% 的有著更復雜用例的使用者沒有被支援。

儘管思維模式非常強大，但它們的效用取決於它們所處的背景條件。為了防止這種情況發生，你應該不僅僅依賴一個或幾個模型，而是應該持續的建造一個思維模型的框架，你可以從中吸取教訓，做出更好的決定。

查理·芒格（Charlie Munger）普及了這個概念，他是著名的伯克希爾哈撒韋公司副董事長，他在一次演講中提到了如何獲取智慧：

什麼是基礎的、世間通用的智慧呢？第一條規則是，如果你只是記住孤立的事實，然後進行嘗試和重複，你就什麼都不知道。如果從這些事實沒有總結出一致的理論體系，它們就沒有可利用的形式。

你的腦海中已經有很多模型了。你必須要整理你的經驗 — 間接的或者直接的都要 — 整理到這個模型框架中。你可能已經注意到有些學生只是試圖記住並重復已經記住的東西。好吧，這樣他們在學習和生活中都會失敗的。你必須要將經驗和腦海中的思維模式連線起來。

什麼是模型呢？第一個規則就是你必須擁有很多模型 — 因為如果你只有一個或兩個使用著的思維模型，人類心理自然就會讓你將現實世界折射得符合你的模型，或者至少你認為是符合的。你會成為像脊椎按摩師那樣的人，毫無疑問，他是醫學界的笑話。

就像老話說的，“對於一個只有一把錘子的人來說，每一個問題都像一顆釘子。”當然，這也就是脊椎指壓治療者對醫學的處理方式。但這是一種世界上的極其災難性的思維和操作方式。所以你必須有多個模型。

這篇部落格概述了一些在我職業生涯中積累下的最有用的思維模型。如果我又獲悉了新的模型，我將會持續更新部落格。

這篇部落格也不僅僅適用於產品經理，而是所有為產品作出工作的人們。產品思維對於產品經理的作用並不是神聖的，事實上，它被構建者掌握可能更有用。

我們將會提及的思維模型被分為如下幾類：

1. 找到投資點
2. 設計與範圍
3. 運輸與迭代

---

找到投資點 — 接下來的這一組思維模型對於決策團隊應該構建或“投入”什麼非常有用。

1. 投資回報

一個財務概念：你投資的每一元，獲取到了多少回報？在產品中，把你擁有的資源（時間，財力，人員）當成是投資，把對客戶的影響當成是回報。

如何應用

對於一個產品團隊來說，可用的資源包括時間，金錢以及人的數量和能力。當你在對比手裡的專案時，你應當選擇那個能夠使你手裡的每一個資源對客戶產生最大化影響力的專案。

2. 交付的時間價值

對於客戶而言，產品提前交付要比延後更加有價值。

如何應用

當在困難或者機會中抉擇如何投入的時候，你應該不僅僅權衡你構建的不同功能所能獲取的收益（當然如果你這樣做了，你一定會選擇收益最大的那個功能）。

相反的，為了作出最好的投資決策，你也要考慮這些功能的交運速度，並對那些能夠更快交運的功能多加關注。

3. 時間範圍

和運輸的時間價值相關，最佳決策會根據優化的時間段而變化。

考慮到足夠長的時間範圍，3 個月與 9 個月構建的成本都是微不足道的。

如何應用

選擇追問 “你在接下來三個月中如何能夠獲取最大影響” 或者 “你在接下來三年中如何能夠獲取最大影響” 所能夠導致的結果將會非常不同。

接下來，通常情況下團隊和股東的第一次討論通常都是協調關於在哪個時間範圍上進行優化。

4. 期望值

預測未來是不準確的。相反，所有的決策都會給未來帶來多種可能的結果。這些結果的概率加權和就是決策的期望值。

如何應用

當考慮專案的影響時，找出所有的可能結果並分配概率。結果的可變範圍通常包括它可能會需要比期望更長的時間，以及它可能並沒有解決使用者提出的問題。

一旦你列出了所有的結果，並對所有結果的價值進行概率加權求和，你就能更好地瞭解投資的收益。

---

設計和範圍 — 在選好了投資目標後，下一組思維模式對於確定產品的範圍和設計非常有用。

5. 反向工作（反轉）

為了找出應該從哪裡入手，應該從一個完美的解決方案開始，然後反向工作，而不是從一個有問題的部分開始，然後尋找解決方案。

注意，反向工作並不總是更好的方法，它僅僅是創造出了一個不同的視角。

如何應用

大多數團隊更傾向於正向工作，它優化了實用性，但是代價卻是最終的影響力。

反向工作則幫助你確保你將專注於對使用者最有影響力的長期工作上，因為你總是在一個完美的方案上逆向開展工程。

注意，反向工作並不總是更好的方法，它僅僅是創造出了一個不同的視角。同時採用兩種不同視角進行規劃也是很不錯的。

6. 對產品的信心決定速度與質量

你所擁有的信心 i) 對於解決問題非常重要，並且 ii) 你正在構建的解決方案的正確性，應該會決定你在產品構建中，多大程度上願意去權衡速度和質量。

如何應用

這個思維模型可以幫助你建立一個晴雨表，用來更巧妙地權衡速度和質量。通過觀察上面頻譜的兩端，解釋這一點是很容易的。

在最右側：對於使用者來說，你正在專注的問題十分重要，對於這點你十分自信（經過使用者驗證，你的自信還會鞏固），並且你十分肯定解決問題需要構建什麼。在這種情況下，你不應該接受任何缺陷，因為你知道使用者將來將會十分需要它，所以最好是高質量的（例如：可擴充套件性，使用者友好）。

現在我們再看看左側：你甚至還沒能確定這個問題對使用者是否重要。在這種場景下，你投入專案構建的時間越長，就有大風險會生成某些之前不存在的問題。因此，你應該推出某些能快速迭代的產品來試錯，並獲得使用者的認可，證實它確實值得最終高質量的構建。例如，在這些情況下，你可以為一個甚至是現在還不存在功能配置落地頁面，來衡量客戶的興趣。

7. 全面解決使用者體驗問題

使用者體驗不止於介面。在使用者使用產品之前和之後會如何，也是很重要的設計點。

如何應用

在設計產品時，我們趨向於過度關注產品內的使用者體驗（比如軟體內部的使用者介面）。

但是市場體驗的設計（如何獲取使用者，以及如何在他們使用產品之前設定他們對產品的期望），還有產品支援/事故的使用者體驗（公司如何應對產品失誤）也是同等重要的。

特別的，產生較大產品事故時的體驗，是獲取使用者長期信任的大好機會。例如，當作為客戶的你不得不退回某些東西的時候，亞馬遜贏得了你很大部分的信任。

8. 實驗，特徵，平臺

產品開發有三種型別：實驗，特徵和平臺。每個都有他們自己的目標，以及最佳方式來權衡速度和質量。

如何應用

認清專案的產品開發型別，你將能夠為每個類別定義更合適的目標，並且為速度和質量與產品之間的權衡找到合適點。

實驗意味著要給出經驗，因此你可以投入新的功能或者使用者認可的平臺。如果你是為了獲取經驗而作出的優化，你要考慮那些不經過實驗就不合適的事情：比如使用你打算丟棄的 hacky 程式碼，以及偽造複雜的軟體，它們只是人們僅在幕後會做的事情。

和實驗相反，平臺則是永久性的。其他人會在它們之上建立新的特性，因此，在平臺生效後對平臺進行更改是非常具有破壞性的。

因此，平臺專案需要高質量（穩定，效能良好，可擴充套件，等等），並且它們需要實際構建有用的功能。構建平臺最好的法則就是和你的第一個客戶一起構建它，即和一個在平臺之上建立功能的團隊同步開發 -- 這樣，你就能確保平臺實際上啟用了可用的功能。

9. 反饋迴圈

產品中的因果關係，是由正面和負面反饋迴路所連線的系統產生的結果。

如何應用

反饋迴圈幫助我們記住，一個產品增長和下降的最大驅動因素可能來自系統的其他部分。

例如，比如你是支付團隊，你的 KPI 就是增加信用卡支付總額。你和使用者獲取的團隊之間存在一個正向反饋迴圈，因為當他們增長了使用者，你就有更多將會用信用卡支付的潛在使用者。但是，你和現金支付團隊之間有一個負向反饋迴圈，他們的目標是幫助使用者更方便的使用現金交易。

知道了這些反饋迴圈，可以幫助你調整方案（例如，你可以選擇將獲取一般使用者作為增加支付量的最佳方式），或者瞭解指標的負面變化（例如，信用卡支付量下降，但是是因為現金支付團隊做得很好，而不是信用卡產品糟糕）。

10. 飛輪（遞迴反饋迴圈）

這是一個正向或逆向反饋迴路能夠以自身的動量為動力並加速的狀態。

如何應用

飛輪和反饋迴圈是相關的概念，但是對於管理平臺和交易市場非常重要。例如，假設你在執行蘋果 iOS 應用平臺。你有兩種使用者：應用開發者，和應用使用者。

飛輪就是更多應用使用者吸引到更多應用開發者（因為有更多的機會可以售賣應用），然後反過來又會吸引更多的應用使用者（因為有更多的應用可以買），反過來又繼續吸引更多的開發者，這樣迴圈的現象。只要你培育好這個飛輪，就不僅是普通的增長，增長的速度也會提高。

如果你正在管理一個飛輪，你就要傾盡全力來確保它向正向旋轉，因為它逆向旋轉的時候力量同樣很大。例如，如果平臺上的應用過多，新的應用無法被發現，應用開發者的增長速度就會下降，這將打破飛輪 -- 你需要解決類似這樣的問題。

---

構建和迭代 — 當你在構建、操作和迭代已有產品的時候，下一個系列的思維模型就非常有用。

11. 收益遞減

當你專注於改進相同的產品領域時，隨著時間的推移，每一份努力創造的客戶價值也將隨之減少。

如何應用

假設你正在基於使用者反饋和調研對產品進行有效的迭代，你最終都會達到那個無法使產品做得更好的程度。 那就是您的團隊繼續前進並投資新事物的時候了。

12. 本地最大

和收益遞減相關，本地最大指的是增加優化但根本不產生使用者價值，它迫使你在產品功能上作出改進。

如何應用

這個思維模型與收益遞減緊密相關，增加了一個限制，繼續維持改進實際上將沒有任何實質性的差異。迭代現在已經毫無意義，唯一繼續的方法是革新。

最近，由於 Eugene Wei 的病毒帖 Invisible Asymptotes，這個概念很流行，帖子中包含這樣一個例子：亞馬遜的預見引領他們創造了 Prime。

13. 第二版是謊言

在構建產品時，請不要依賴版本二的產品。確保版本一是一個完整的產品，因為它可能永遠存在。

當軟體在貨架上出售時，團隊必須永遠使用版本一。

如何應用

當你定義產品的第一個版本時，你將聚集所有你希望在以後的版本中新增的令人驚歎的功能。你要認識到，一些功能可能永遠也不會發布，因為你不知道將會發生什麼：公司政策調整，你的工程師總監辭職，或者你的團隊被重新分配到了其他專案中。

為了避開這樣的場景，確保你釋出的是一個“完整的產品”，就算它再也不升級，在可預見的未來裡，它對於使用者來說也依舊是可用的。不要釋出一個依賴於未來改進才能解決問題的新功能。

14. 免費錦標賽

指的是通過快速釋出，損失很少而收益很大的場景。

如何應用

免費錦標賽通常在這樣的產品中出現：當前的使用者體驗非常差，以至於作出任何一點基於直覺的合理的改變都很有可能帶來很大改善。它們與修復 bug 不同，因為 bug 指的是沒有按照設計工作的東西。

如果你正在這樣一種情境下：你的團隊正在考慮，“我們就這麼做吧...反正也不能更糟了”，也許你面前就正有一個免費錦標賽的機會。

（Reddit 上的 r/CrappyDesign 是一個上述情況的寶庫）

15. 大部分價值在第一個版本之後被創造出來

在你釋出了產品之後，你將會從使用者那裡學到很多，不要浪費了在這些經驗之上構建產品的機會。

如何應用

在使用者大規模地使用產品之前，一切都是假說。你的團隊在釋出前所投入的 — 使用者訪問，原型測試，定量分析，測試，等等 -- 都能大幅度支援你成功的可能性，一旦你將功能釋出給所有的使用者，總會出現產品行為（異常）和偏離的情況。

學習一部分客戶的審美價值後，你將會在產品釋出後獲取很多知識經驗。如果不通過迭代產品（有時是大幅度的修改）進行相應的投入，那麼學到了這些也是毫無意義的。

16. 失敗的關鍵指標（KFI）

將關鍵績效指標（KPI）與你不希望看到的指標走向配對，以確保你專注於產品的健康成長。

如何應用

團隊經常選擇能夠直接反應他們正在尋求的正面結果的 KPI，而不考慮實現這些結果的負面影響。一旦他們開始為這些 KPI 優化，對於公司，他們實際上創造的是很糟糕的產出。

一個經典的例子是，當登陸頁面上註冊轉換翻倍了的時候，一個團隊認為他們取得了成功，但是卻發現（為時已晚）總使用者量並沒有增長，因為由於相同的變化，轉換率下降了 60%。

KFI 能控制團隊績效，並確保您只為公司建立淨健康產出。

流行的 KPI <> KFI 配對的例子包括：

1. 維持毛利率的同時增加收入
2. 在不取消採用功能 B 的情況下，逐步採用功能 A
3. 在不增加支援負載的情況下，逐步採用功能 A

---

使用框架，而不是清單

對於讀者來說，它可能並不讓人很滿意，但是據我所知，並沒有使用這些思維模型的方法論。如果你試圖將他們作為一個清單來使用 — 逐個嘗試每一種方法來看看它們是否適用 —— 你最終會發現你只是在做思維訓練，這會讓你和周圍的人都感到困惑和沮喪。

相反，它們成為了你的思維框架的一部分，幫助你做出更好的產品決策，併為您提供一種語言，以便為您的團隊傳達複雜決策背後的原因。

當你累積了更多的模型，同時模型隨著經驗的累計變得更理想，你將會更加優秀。

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。

---

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。