用 7 種常用的產品探索驗證方式，降低做出爛產品的機率
在正式製作之前，先驗證市場需求是否真的存在吧！
產品在不同的階段，需要利用不同的探索方式，來向利害關係人證明自己的想法是否正確，驗證自然變成產品經理工作中，很重要的一環。
最近在讀 Roman Pichler 的 Strategize: Product Strategy and Product Roadmap Practices for the Digital Age，以及 Product School 出品的 The_Product_Book : How to become a great product manager 的一些片段，整理了一些產品探索的驗證方式，將自己抓到的重點記錄於本文。
文章目錄
（一）Why:產品探索做驗證的目的
（二）How:7種產品探索的驗證方式
（三）What:驗證結束後，該繼續做下去嗎？（一）Why : 產品探索做驗證的目的
當你要打造一個產品，或是將現有產品改版優化、新增功能、修正bug，都必須花下大筆的金錢、時間去投資產品的未來發展。
然而，你怎麼知道腦中的這些想法是對的，顧客真的會買單？功能有幫助到使用者？顧客懂得如何使用你的產品？要如何證明這些價值不只是自己憑空想像的呢？
為了回答這些問題並做好風險管理，產品驗證的目的就是盡可能地「在推出產品／功能前，透過與顧客真實互動的實驗測試，來確認需求是否存在，進而降低產品失敗率以及提升成功率。」
Marty Cagan也在《產品專案管理全書》中提到：
探索的目的，是要處理這些關鍵風險
- 價值風險：顧客會購買或決定使用嗎？
- 易用性風險：顧客知道怎麼用嗎？
- 實用性風險：產品能打造出來嗎？
- 商業可行性風險：這個方案有助於事業發展嗎？
關於驗證的一些tips
- 越早驗證，越能降低未來要修改或做白工的花費。
- 越未知的產品／功能，越要嚴謹且更次的驗證，譬如破壞式創新產品就需要比成熟產品更多更多的驗證。風險越高，驗證越多；風險越低、驗證越少。
- 要盡量用最快且最便宜的方式進行概念驗證。
- 如果從沒驗證失敗過，或是總是收到正面回饋，那你有可能沒有處理到正確的風險問題，測試族群錯誤或測試方法錯誤，或是你誤解了回饋資料。
（二）How : 7 種產品探索的驗證方式
探索驗證的方式很多種，我一直對探索技巧很有興趣，常常會從不同的地方聽到一些有趣的探索驗證方式，下面概述七個常見的驗證技巧。
1. 觀察使用者或消費者
走出你的辦公室，找到使用者並實地觀察他們碰問題時，遭遇到什麼樣的困難？在什麼地方、步驟碰到麻煩？他們目前是如何解決的？
如果他們已經是你的產品使用者，實際去看他們如何使用你的產品，不要一昧地相信業務、行銷團隊或任何利害關係人！很多時候他們可能是從客戶口中「聽說」的，或是單純是他們的主觀想像。
實地觀察可以讓你清楚的知道，使用者或消費者究竟有沒有碰到你產品想解決的關鍵問題。
2. 問題訪談
找到你鎖定的潛在目標客戶，約他們聊聊看，他們多常碰到這些問題？這個問題有很困擾嗎？他們有意識到這個問題困擾著他們嗎？不解決的話會怎樣嗎？（這裡也有一點關於訪談的小技巧。）
請在訪談前先想好一系列的題目，並且事前徵求同意錄音做紀錄。別問是非題、別誘導回答、別提及你的產品、別提及功能；使用開放性問題，少說多聽並給予正面回應，表現出你的興趣，告訴他們說，他們的回答對你有很大的幫助，鼓勵他們，讓他們願意說更多。訪談也別忘了記下被訪談者的年齡、性別、工作等資訊。
將訪談時間限縮15分鐘內，或準備一些訪談小獎勵，都可以讓你更容易找到足夠多的訪談對象。
每次進行問題訪談後，我常常都會收穫滿滿，並且有新的insight，產品的開發方向也更加明確。
3. 問券調查
使用問券調查可以蒐集大量資料，並且將事實、情感等抽象內容轉為數字量化。
調查的題目包含使用者的背景、發生過的事實、行為結果、以及情感等面向。在設定題目時，要做到「問題具體」、「避免誘導」、「問題單一」、「文字好懂」四個要點。
問券調查的好處是可以不受時間空間的限制，同時對大量的對象調查，現在有很多像SurveyMonkey、Google Forms、SurveyCake等方便的問券調查工具，製作問券非常簡單便利。
不過，畢竟是冰冷冷的數據，有時候作答者也沒辦法講出填寫內容的因果關係，而且存在有效性的問題，有時候難以過濾無效問券。如果有使用問券調查，最好還是要以問題訪談作為輔助。
4. A/B Test
A/B Test是為了測試某樣假設，在兩個版本中做出特定變因，推給相似背景的用戶做測試，找出能哪一個版本是較能改善指標或達成目標的方案。
如果受測群組不同，比如 A 版本受測男性較多、 B 版本受測女性較多；或著 A 版本受測群體年齡多為 50 歲以上， B 版本受測群體多為 30 歲以下；又或樣本太少，都會造成 A/B Test 的準確度出問題，因此要注意受測者的分布。
A/B Test 適合在首頁、 Landing page 或流量大的地方做實驗，藉此可以採集到較多的樣本。另外我個人的觀點認為， A/B Test 相對來說較適合用在成熟產品，以及能夠大幅改善成效的地方；較不適合用在年輕、早期的產品，以及改善幅度不大的地方。
以前聽瑞典知名遊戲公司工作的朋友分享過，他們公司有兩款近乎同性質的遊戲，會先在低流量的遊戲中做 A/B Test 實驗，實驗成功後，才拿到高流量、高營收的遊戲中套用，藉此降低明星產品的風險。
5. 最小可行性產品（MVP）
最小可行性產品（MVP），絕大多數書籍文章都稱呼 Minimal Viable Product，但也有人稱 Minimal Valuable Product。以我個人觀點認為都是對的，可行、有價值都是產品需要驗證的重點，只是怎麼去解釋MVP三個字的縮寫罷了。
下面是一些MVP的例子：
- 著陸頁（Landing page）：製作著陸頁來說明你的產品能解決什麼問題、有什麼特點，把它做得像產品真的存在的樣子，並利用「了解更多」或「購買」等 call to action 按鈕來觀察點擊率，看看訪客是否願意留下名字、email等聯絡方式，來預約產品。也可以在頁面上顯示多種商品選擇，以食品來說就像菜色、口味等，測試顧客對哪些商品比較有興趣。
- 部落格（Blog）： Roman Pichler 有提到他利用Blog來發文，並且確認是否大家對他撰寫的主題有興趣，最後在集結成冊校稿，最後出書，這個方法在國內外都有不少作者在使用。
- 講座：如果想要開課或同樣要出書，也能利用舉辦小型講座的方式，來確認報名踴躍度，效果類似Blog的瀏覽量或讚數。講座的好處是互動性會比部落格更直接快速的交流。
- 影片：精實創業無人不知的Dropbox影片，在2007年當時，大家不知道雲端同步資料能帶來多大的便利，因此Dropbox團隊在申請YC加速器時，就加入了影片來展示產品概念，讓大家感受產品的魅力，而不只有想像。
- 原型（Prototype）：原型是不必等到程式製作出來才能確認使用者會不會使用產品的驗證方法，呈現方式主要有分低保真（Low-fidelity）或高保真（High-fidelity）。在驗證時，我會在每個畫面說明必須完成的任務，請受測者實驗看看能不能順利完成，觀察他們會在哪邊卡關，蒐集操作者的反應後，進行修正。自己的經驗是至少要實驗 5 個使用者，調整後再實驗 3–5 個使用者，第二次調整後，最終再找 2–5 個使用者確認。自己上次是測到15個左右的使用者才比較安心一點。
6. Spikes
Spikes是從 Strategize 這本書裡面看到的詞，以前從沒聽過。Spikes就像是研究一樣，幫助你探索出團隊能不能製作或發行你要的產品。不像產品正式開發，Spikes只要處理最重要的風險就行了，它通常是一次性的tasks，驗證完就可以丟棄了。
舉個例子就會比較好理解，比方說概念驗證（Proof of concept）就是Spikes的其中一種；或著是像國外論文裡面看到先進的演算法，不確定能不能實作到產品中，這時候技術人員要試驗，就是做一個Spike。你可能會做很多的Spikes，來挑選其中一個作為產品底層技術，團隊也可能只做出一個，評估沒問題就拿來使用了。
有些第三方的套件如果可以放入產品中使用，探索這些套件的費用是否符合成本預算，也可以稱為一個Spike，它不侷限於程式或技術面的內容，像各國的法規也是風險，處理這個問題也算是Spikes。
無論如何，Spikes的實驗如果不成功，或不適用在你的產品，就算有再棒的點子，產品也做不出來，或著是做出來無法推出。
7. 募資平台
現在國內外都有kickstarter、嘖嘖、flyingV這些群眾募資平台，讓我們不需要先把產品做出來，就可以用 MVP（Landing page 或上面Dropbox 的影片方式）來介紹產品，試驗消費者有沒有興趣，還能設定多種預購產品組合來測試。
募資的好處是除了在產品製作出來前，就預先募得足夠的金錢之外，最重要的是就算募資失敗了，也幫你迴避了市場需求不足，或是產品力不夠的風險，避免把錢白白丟到大海裡。
（三）What : 驗證結束後，該繼續做下去嗎？
呼應本文開頭，在產品開發、改版優化、新增功能、修正bug等之前，都要先做驗證，並且思考到底做這些項目的目的為何？
另外在考慮製作項目前，除了思考做了有什麼好處？也可以反問自己，不做會怎樣嗎？最近蠻喜歡用反問句來思考，會讓自己有完全不同的觀點。當你想做某個項目，你會千方百計去說服自己的產品現在很需要這個項目，但一反問才發現，其實不做根本不會怎樣。
決定要做了，也選擇設計了驗證方式後，別忘了設定指標來衡量這次的項目是否通過驗證。比如你發現多少比例的目標客戶，都存在產品要解決的問題？使用者付費比例上升多少？有多少人對你即將推出的項目有興趣？
如果驗證成功，產品可以更有信心的往下開發；如果驗證失敗的話，可以思考在驗證過程中發現的觀點，思考如何Pivot到下一個項目再重新驗證；最後，如果都沒有，該砍掉項目就果斷的砍掉吧。
謝謝你的閱讀！
如果你讀完這篇文章，請給我 1–20 個拍手；
如果文章對你有幫助，請給我 21–50 個拍手！
如果你對這類主題有興趣，請幫我拍50個手！未來我會多撰寫這方面的內容。
想繼續收看我的文章，請記得追蹤「Brandon Lab」，我會定期更新喔！
也歡迎留言或寫信與我交流 → brandon3guitar@gmail.com
