大約在幾年前，當時任職的新創公司在完成地獄般的產品開發，並且成功的舉辦上線記者會之後，獲得了一個和當地最大銀行合作，進軍東南亞的機會。這是公司第一個2B的案子，背後藏著龐大商機，因此全公司的資源都投注在這個專案上，董事會也是緊緊盯著。

我很幸運的被指派為專案負責人，帶著全公司的團隊和當地客戶系統整合，調整產品，準備大展身手，邁向東南亞。

因為文化差異，語言溝通障礙以及彼此開發流程的差異，讓我不得不帶著團隊在上線前一個月住在當地的飯店，日以繼夜趕著在記者發表會前上線。這段水生火熱的日子讓我在跨國專案管理的經驗上成長很多，很值得拿出來討論。日後有機會再來專門寫一篇。

總之，團隊排除萬難，順利上線後，我們從數據上發現一件很奇怪的事：付費完成度很低。

不是付費的人數很低，而是所有進入付費流程的用戶中，完成付費流程人數的百分比只有台灣的一半。數據顯示，點擊付費按鈕並且走進付費流程的用戶，大約有80% ～85%的完成度，但是這個地區卻在 ” 選擇付費方式 “ 的頁面出現很高的bounce rate，流失超過一半的用戶。我們以為是技術上的bug，導致用戶無法走完付費流程，但是無論怎麼測試，都找不到任何可疑的地方，所以我們重新定調這個問題為需求偏差，因此轉向當地合作夥伴求救。

原來，這個國家人民收入低，錢存銀行的意願不高，加上信用制度不完善，擁有信用卡的人數只佔全國不到10%，而我們初期的付費選擇只有信用卡，造成多數人無法完成付費流程，直接影響了公司營收。

在這個案例上，我們陷入了產品經理設計功能時最容易誤踏的陷阱：unknown-unknown的困境。

什麼是Known-Unknow Matrix :

… because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones.

– Donald Rumsfeld

這是美國國防部長在2002年回應記者關於伊拉克威脅時發表的言論，他提出資訊認知分成以下幾類：Known Knows — 我們意識到我們知道某些事 ; Known Unknown — 我們意識到我們不知道什麼事 ; 以及最困難的類別Unknown Unknown — 我們沒有意識到其實我們不知道某些事。

現在我們試著以產品經理角度出發，把這個matrix對應到產品功能和市場需求的認知上：

1. Known Knowns 我們知道市場需不需要這個需求：

這是最好的狀況，我們理解使用者痛點，並且依據事實建立需求，這個象限的需求具備明確的目標以及痛點解決方案。我們最想要把其他象限的需求往這裡靠近。

2. Known Unknows 我們知道我們還不知道這個需求是否被市場接受：

這類需求可能來自團隊腦力激盪的創意，或是市場上某些客戶群的聲音，尚未被驗證，因此產品經理必須通過數據、AB測試或是市調找出答案，調整需求樣貌，慢慢將需求往第一象限靠近。

3. Unknown Known 我們不知道其實我們了解這個需求：

這通常發生在資訊斷層上，像是新到職的PM沒注意到以前做過類似功能，並且因爲效果不彰而移除。或是數據已經證明了某項功能的成果，但是沒有人分析那批躺在資料庫裡的數據，白白浪費了一個好機會。

4. Unknown Unknown 我們不知道我們不知道

我最害怕從產品經理口中聽到三個字：「我知道」，就如這篇文章開頭的故事，我以為信用卡是全世界最普遍的付費管道，導致跨出海外時少了當地支付的功能。這個象限很難自我察覺，但是能透過不斷驗證，不斷提問來減少存在這個象限的需求數量。

Known-Unknow Matrix 如何幫助產品經理 :

1. 優化需求排序：

在排定需求清單時，試著把這些需求按照Known-Unknow Matrix分類，並且不斷詢問自己：「這些需求真的屬於第一象限嗎？我是否已經和數據、UX、需求單位在各個層面都確認了？」如果有任何疑慮，就把需求放到第二象限或是第三象限，並且安排資源盡力將需求移往第一象限，而不是直接排進開發。

2. 釐清突發需求：

當大老闆沒頭沒尾的丟個需求過來時，第一步先確認需求是哪個象限：1. 這個需求是老闆突發奇想，需要你幫忙驗證（第二象限）或是 2. 老闆已經有內幕，並且知道這個需求背後的邏輯及合理性，只是沒告訴你 （第三象限）。

這時候要做的，就是驗證老闆的論點，讓需求從第二象限移到第一象限，或是跟老闆詳談，找出需求的邏輯，讓需求從第三象限轉到第一象限（也有可能是第三象限到第二象限再到第一象限）

總結

Known Unknow Matrix是一個思考框架，在安排product backlog時就可以一併使用，這不旦能強迫產品經理思考需求的可靠度，也能確保需求在付諸實現後，能達到預期的效果，增加產品開發效率及成品設計的成果。