1.使用框架的好處
框架（Framework）在不同領域有各自的定義，但比較通用的定義是一套用以解決特定問題的規範，讓大家在解決問題時，可以按照此規範來進行。
框架的使用在顧問業行之有年，知名顧問公司如麥肯錫、BCG 的員工也都大方的分享他們在商業領域或解決問題的框架。在產品經理的工作範疇，自然也發展出了一些常見的規範，許多知名公司如 Spotify、Amazon 也都有著名的產品開發框架，可參考以下文章：
在介紹常見的產品框架前，先來談談為什麼產品經理要使用框架。我認為簡單的回答是，找出自己的思考誤區與盲點、彌補經驗的不足與促進團隊協作。
首先，每個人都有不知道、不熟悉的領域，也就是所謂的 You don’t know what you don’t know。框架可以幫助你找到盲點，補足你沒想到的地方，確保做事情的品質。
其次，產品經理是個很重視做中學，很重視經驗的工作。框架累積了前人的智慧結晶，可以讓產品經理站在前輩的肩膀上，能看得更遠、更全面。
最後，如果是較大型的產品組織，產品經理彼此可能不熟悉對方所負責的產品。框架也讓產品經理們有共通的語言，方便不同團隊的協作與資訊交流。
2.產品經理常用的框架
在了解使用框架的好處後，我們來看看產品經理常見的框架。
1.優先性排序
若要說不管什麼階段的產品經理最常用的框架，那便是優先性排序 (prioritization) 莫屬。不管在什麼組織，經濟學所提到的「資源有限，慾望無窮」大概都是個真理。因此，排優先性可以說是產品經理的家常便飯。
網路上有非常多介紹優先性排序的框架，在此整理幾篇不錯的文章：
上面文章介紹了很多優先性排序的方法。無論你選擇了哪一個方法，最重要的是讓團隊清楚知道優先性排序的規則，以及準備好進行優先性排序所需要的資料（是需要時間準備的）。
當然，產品經理並非知道了優先性排序的框架就從此過著幸福快樂的日子。事實上，這些優先性框架可能有些問題，請參考下方文章：
2.產品策略
Reforge 的文章提到，產品經理常常在優先性排序卡關，原因是出在產品策略上。
“Difficulty prioritizing is often a strategy issue, not an execution issue. It is impossible to make rigorous prioritization decisions when the guidance on how to do so is missing, unclear or disconnected from what you are trying to do.”
因此，我們就順勢來介紹產品策略的框架。或許新手產品經理還沒太多機會接觸產品策略框架，但這絕對是資深產品經理或產品主管應該要掌握的。
Reforge 的 The Product Strategy 這篇文章可能是把 Company Mission、 Company Strategy、Product Strategy、Product Roadmap 與 Product Goals 這五層講得最清楚的文章之一，值得慢慢品嚐。
Gibson Biddle 的 Product Strategy Exercises 則是手把手的帶大家一步步的把產品策略生出來，作者也很佛心的把內容整理成 Google Slides。
3.產品指標
有了產品策略，等同於有了需要追逐的商業目標。接下來，產品經理需要知道如何衡量產品是否成功，是否有達成目標。產品指標框架就是來幫助產品經理思考如何系統化地衡量產品成功的問題。
我先前寫了一系列關於產品指標框架的文章（文章內也有許多產品前輩的好文章），歡迎還沒看過的讀者閱讀。
4.實驗測試
有了好的產品指標框架還不夠，更重要的是透過實驗（如 AB Testing），驗證產品假設。
然而，許多人對實驗有些誤解，以為是閉門 Brainstorming 討論出一些點子就來測試。事實上，實驗是用來驗證商業上的假設，以達成商業目標。正確的思考脈絡應該是先知道商業目標，透過研究、數據分析或經驗找出阻擋產品達成商業目標的問題，接著提出假設，以實驗來驗證欲解決該問題的方案是否有效。
Designing with data 這本書提到的實驗框架（Experimentation Framework）有效的避免這個常見的誤解，讓產品團隊一步步的把目標、問題、假設與實驗測試定出。
想要了解這本書的摘要，可以參考以下兩篇文章：
5.更多框架
除了以上介紹的框架，還有更多為了解決不同產品問題的框架，可以參考這個網站：
3.使用框架應注意的事
框架看似美好，但產品經理使用上也有一些該注意的地方。
1.框架的限制
首先，每一個框架一定有它產生的時空背景。也就是說，它可能只能解決特定的問題領域，並非所有的領域。了解框架的背景與限制是正確使用框架的第一步。例如 AARRR 是 Growth 領域常見的框架，但它並非適用於所有的產品開發。
2.框架導入不是一天造成的
羅馬不是一天造成的，框架也不是。有時產品經理在學了某個框架之後，會很急切地想要導入組織，應用在產品開發流程中。然而，任何的改變都需要溝通，需要時間。或許，先導入在某個專案，或是導入框架的某幾個環節，讓大家嚐到甜頭後，會更容易推動。
3.沒有框架也很好
並不是所有的問題都要透過框架來處理。有時候簡單的事情，快速地溝通一下即可，不要把工作過度複雜化了。
以我自己的經驗，產品經理與框架大概會有以下幾個進程（笑）：
- 框架狂熱：初次聽聞框架，開始想要在任何地方都使用框架，開口閉口都是 XX 框架。
- 否定框架：因為專案上受挫，覺得框架不管用，不再使用框架。
- 善用框架：隨著經驗的累積，知道何時該用框架，何時不需要用框架，讓工作兼具條理與彈性。
希望各位產品經理都能在對的時機使用產品框架，打造出更好的產品。
