source: pngwave
工程師背景的我們，從以前最擅長與專注的就是在 Deliver 的優化，以及學習相關的方法論，但是隨著在社會闖蕩碰壁多年，漸漸發現其實 Define and Discovery 的方法論更是至關重要，可以幫助我們減少許多白費工的狀況發生（工程師最怕需求一直改，改出來又沒人用）。
去年聽了 Marty Cagan 的演講 - Product Is Hard ，就開始仔細閱讀『Inspired 產品專案管理全書』，並且思索如何應用在現在的產品，有許多內容和方法真是相見恨晚，在第 39 章整理了 Marty Cagan 在 2013 年寫的一篇文章 The Power of Reference Customers，而這個套路在矽谷的 SaaS company 更是隨處可見，可以在許多產品的業面看到以下訊息：
我們都知道要提供成功使用者故事，也知道要列出成功使用者，但是實際上該怎麼操作？該怎麼挑選客戶？應該要注意什麼事項？
最近在會議中不斷的討論相關議題：
- 我們要怎麼找到前幾個客戶（Early Adapter）？是來者不拒嗎？
- 如果每個客戶都有一些獨特的痛點，那我們要幫他們客制化開發嗎？
- 對於每個客戶我們應該要花費多少心力？這會影響到我們的客戶獲取成本（CAC：Customer Acquisition Cost）
- 我們應該專注於特定領域或是各個領域都要多方嘗試？
探索客戶計畫
書中提到探索客戶計畫很重要，首先要專注在某個 Vertical 找尋 6~8 個客戶，這個 Vertical 可以是某個產業，或是某個地理位置，不要亂槍打鳥。
接下來挑選符合以下條件的客戶：
- 對於我們設計的 Feature，確實有解決他們痛點，並且提供商業價值的客戶
- 願意作為 Early adapter 跟我們密切合作，試用產品並且給出 feedback 的客戶
- 能了解我們的目標是要打造『通用產品』並不是只為他們客製化開發的客戶
- 客戶的行銷/公關部門願意合作，被我們列為公開參考客戶
一旦有了具體評估的條件，再搭配以下的矩陣，我們就可以比較能聚焦的討論，到底這個客戶是不是我們初期應該關注的客戶？或者是以後再來服務？
以我們跟 Microsoft 和 AWS 的合作為例就是很好的例子：
因此產品經理與產品行銷經理必須通力合作確保兩件事：
- 確保得到客戶行銷部門的許可
- 確保公開銷售前客戶的滿意度，將來他們就是你們的公開代言人
此外針對三種不同產品類型，也有些許不同
1. 平台 / API 產品 (2B)
除了 Reference customer ，更應該列出 Reference application (焦點放在以 API 成功開發出來的應用程式)
2. 客戶支援工具 (2B)
挑出主要 6 到 8個受到敬重和有內部影響力的用戶或員工 (意見領袖)
3. 消費品 (2C)
選出消費族群 (類似焦點使用者) 10～50人 總結
書中在 39 章 - 探索客戶計畫，有給出許多具體的建議，讓處於 Discovery and Delivery 雙軌模式運作下的我找到一個依歸，覺得這篇可以當作 Product Manager 的一個查核清單，確保不但 Do the things right 也可以 Do the right things！
Call to Action
如果你的 Business 會需要把影片放在網路上串流播出，但是又苦於沒有 Video Streaming 相關的技能，也不想直接放到 YouTube 上任意讓人使用，我們這邊即將推出一個簡單易用的影音轉檔串流平台，有興趣的歡迎跟我聯繫試用。
延伸閱讀：
沒有留言:
張貼留言