平台產品的研究與探索：從 Etsy 產品負責人學習用戶研究的實戰策略 🚀
前言：為什麼平台產品需要用戶研究？
在產品開發的世界中，平台產品往往面臨著獨特的挑戰。許多團隊花費數月時間開發出自認為具有革命性的功能，最終卻被默默地束之高閣；或是建構了強大的 API 功能，但採用率卻遠低於預期。這些失敗的根本原因往往在於技術願景與實際用戶需求之間的脫節。
來自 Etsy 的資深產品負責人 Nadia，擁有超過十年的產品管理經驗，曾在 Pivotal Software、VMware 等知名企業工作。她深刻理解平台產品的複雜性，並透過實戰經驗分享如何運用用戶研究來避免常見的產品失敗陷阱。
什麼是平台產品？理解雙重客戶模式 🎯
平台產品的定義
根據產品管理大師 Marty Kagan 的定義，平台產品是供應用程式開發者用來創建終端用戶解決方案的基礎軟體。這個定義精準地點出了平台產品的核心特色：它同時服務開發者和最終用戶。
平台產品的典型範例
- AWS（Amazon Web Services）：雲端運算平台的經典代表
- Netflix 內部平台：推薦系統和實驗平台
- Google Maps：既是消費者產品，也是開發者平台
- Etsy 內部平台：網頁應用、數據實驗等開發工具
雙重客戶挑戰
平台產品的獨特之處在於需要同時考慮兩個客戶群體：
第一層客戶：開發者
- 內部開發團隊成員
- 第三方整合開發者
- 產品團隊（包含 PM、設計師、分析師）
第二層客戶：終端用戶
- 實際使用產品功能的消費者
- 在 Etsy 的案例中，就是買家和賣家
成功的平台產品團隊必須深度理解開發者需求，以及開發者正在為終端用戶解決的問題。更進一步，還需要掌握企業的長期發展方向，例如是否需要支援大規模招聘、探索新的垂直領域，或是需要新技術整合。
平台產品常見的失敗模式 ⚠️
1. 產品無法滿足實際需求
花費大量時間開發的功能，最終發現無法解決真正的痛點。
2. 功能強大但採用率低
技術上可行且可用，但開發者看不到採用的價值。
3. 適用性有限
某個團隊使用效果極佳，但其他團隊卻覺得格格不入。
4. 開發者不願意使用
這是最常見的失敗模式。改變行為習慣需要明確的價值主張，如果開發者看不到足夠的價值，就不會採用新的工作方式。
為什麼平台產品需要用戶研究？破除常見迷思 🔍
常見的質疑聲音
許多團隊對於在平台產品中進行用戶研究存在疑慮：
- 「工程師既是創造者也是使用者，他們不是已經知道需要什麼了嗎？」
- 「我旁邊就坐著開發者，他們說想要這個功能，這樣不夠嗎？」
- 「這是技術領域，API 沒有介面可看，要怎麼做用戶訪談？」
為什麼這些想法是錯誤的
技術專業不等於用戶洞察
平台產品的開發者通常具備深厚的技術專業知識，往往是公司最資深的工程師或架構師。然而，他們可能缺乏對客戶端開發者實際操作情境的理解，包括：
- 快速交付的壓力和限制
- 為了應對特殊使用情境而創建的變通方案
- 即將推出的功能需求
單一意見的局限性
一個開發者的需求可能對他們有幫助，但平台產品要發揮最大效益，必須能夠擴展以滿足多數人的需求。理解不同團隊、不同平台部分的開發者使用情境，有助於確保解決方案適用於大多數使用案例。
無介面產品也能進行研究
即使是沒有使用者介面的產品，如 API、CLI 工具等，同樣可以進行有效的用戶研究。
平台產品用戶研究的完整流程 📋
第一步：善用既有研究資源
在開始新的研究之前，先盤點現有的資源可以節省大量時間：
內部資源盤點
- Slack 對話記錄
- 技術支援請求
- 團隊既有的研究和知識
- 利害關係人的期望和需求
問題框架確立
- 這是從零到一的新專案，還是既有產品的改進？
- 目前對問題的理解程度如何？
- 有哪些開放性問題需要解答？
第二步：制定研究計畫
這是整個流程中最關鍵的步驟，需要投入充分的時間和精力。
假設驗證練習 💡
團隊腦力激盪
召集團隊成員，進行假設的腦力激盪，寫下所有我們認為正確的事情：
- 對技術的假設
- 對客戶（開發者）的假設
- 對工作流程和產品互動的假設
這個練習的價值在於將團隊成員腦中的隱性假設顯性化。最有趣的情況是發現團隊中兩個人持有完全相反的假設，而這種分歧往往要到進行這個練習時才會浮現。
研究目標設定
明確定義研究要解決的問題：
- 你想要學習什麼？
- 什麼是必須快速了解的，因為如果搞錯會導致失敗？
- 哪些領域是你最不了解的？
- 需要學習什麼才能做出決策？
範例研究問題
- 這個新功能能否輕鬆融入既有工作流程？
- 開發者能否理解如何開始使用？
- 這能為開發者節省時間嗎？
訪談腳本撰寫技巧
開放式問題原則
- ❌ 錯誤：「這個工具有什麼困難的地方？」（帶有偏見）
- ✅ 正確：「請告訴我你使用這個工具的經驗。」
避免未來式，聚焦過去經驗
- ❌ 錯誤：「你下週會去健身房幾次？」（可能回答：每天）
- ✅ 正確：「你上週去了健身房幾次？」（可能回答：一次）
同樣的原則適用於平台產品訪談：「請告訴我你上次使用這個 API 的經驗。」這樣能獲得更真實的回饋。
第三步：執行訪談
確定正確的客戶群體
廣泛探索性研究
如果研究目標偏向探索性，需要與廣泛的客戶群體對話：
- 新進工程師和資深工程師
- 平台不同部分的使用者
- 不同技術專業程度的人員
特定目標客戶研究
如果已知目標客戶群體，則專注與他們對話，例如針對推薦解決方案的機器學習工程師。
既有產品改進研究
對於既有產品的改進，建議同時訪談正在使用產品的用戶和尚未使用的用戶，這能提供改進的全面視角。
訪談執行最佳實務
團隊參與原則
- 至少需要兩人：一人主導提問，一人記錄
- 不限於產品經理，任何人都可以參與
- 多元視角：工程師關注技術細節，產品經理關注可用性和價值
營造友善環境
- 開場說明沒有標準答案，大家是在共同解決問題
- 這些都是你的同事，創造輕鬆的對話氛圍
- 視訊通話時開啟攝影機有助於建立舒適的環境
第四步：多元化訪談方法 🎨
1. 共創用戶旅程
適用情境：理解開發者當前工作流程
執行方式：
- 基於現有資訊繪製高層級用戶旅程
- 詢問受訪者缺少什麼、哪裡有落差
- 隨著訪談進行，逐步填補更多細節
- 識別不同團隊間用戶旅程的差異和模式
2. 現在與未來用戶旅程
適用情境：規劃未來狀態的產品體驗
執行方式：
- 創建展示未來可能狀態的用戶旅程
- 在實際執行前識別潛在問題或落差
- 作為路線圖和用戶故事選擇的依據
- 切分 MVP，確定建立最小用戶行動集合的必要條件
3. 可用性測試
技術產品的可用性測試
即使沒有使用者介面，仍可透過以下方式獲得可用性洞察：
- 分享文件並詢問如何完成任務
- 展示計畫解決方案的原型，詢問如何整合到既有工作流程
- 觀察開發者在自己的開發環境中使用 CLI 或嘗試新指令
具體提問技巧
- ❌ 避免：「你有什麼回饋給我？」（太籠統）
- ✅ 建議：「我注意到你在安裝 SDK 前猶豫了一下，為什麼？」
- ✅ 建議：「你剛才在原型中遇到錯誤，你期望看到什麼資訊？」
第五步：整合分析與洞察產出 📊
資料整理與標記
即時整理
每次訪談後立即進行簡報，有助於加速後續分析流程。
系統化標記
依據來源、人物誌、階段或功能進行標記和分類。
快速澄清
如有開放問題或需要澄清的地方，由於客戶通常就在公司內部，可以透過 Slack 快速跟進確認。
主題識別與洞察萃取
模式識別
尋找重複出現的痛點、目標、心智模型、用語或使用行為。使用親和圖法將不同用戶的相似洞察分組。
假設驗證
回顧最初的假設練習，檢視哪些假設被證實、被推翻，或需要更多資訊。
洞察轉化
將觀察轉化為洞察：
- 我學到了什麼？
- 這意味著什麼？
- 為什麼會發生？
優先順序排定
基於頻率、嚴重程度、商業影響進行優先順序排定。可以使用「待完成工作」(Jobs to be Done) 等框架，並與利害關係人或其他數據來源進行驗證。
行動方案制定
將洞察轉化為具體行動：
- 用戶故事
- 待辦事項清單
- 進一步研究的機會
- 可以立即處理的低成本改進
第六步：分享與傳播 📢
創建易於理解的產出物
多元化呈現方式
- 用戶旅程地圖
- 人物誌
- 洞察簡報
- 其他視覺化工具
完整資訊包含
- 研究目標
- 訪談方法
- 主要主題
- 建議行動
善用客戶引言
在技術產品中，客戶的真實引言特別有力：
- 「有時候我到了程式碼的新區域，就是不知道該怎麼辦。」
- 「哇，這為我省了 10 個步驟。」
這些引言讓技術產品變得更有人情味和意義。
建立認同與支持
內部宣傳
向參與訪談的人員回報研究結果，讓他們知道你聽取了他們的需求並轉化為行動。這些早期參與研究的開發者，往往會成為產品推出時的最大支持者。
領導層溝通
研究有助於建立對機會和解決方案的信心，不僅對團隊如此，對領導層也是如此。與領導層分享研究洞察，特別有效於爭取更多平台投資。
跨部門價值
組織的其他部門可能也會發現你的研究有用。技術產品對非技術受眾來說較難理解，展示真實的客戶痛點、引言和洞察，有助於讓產品變得更個人化和易於理解。
實戰案例分析 📈
案例一：API 開發的早期驗證
情境描述
在規劃建構新 API 時，可以使用視覺化流程圖進行早期驗證測試。
執行方法
使用 AI 工具在 Miro 中建立 API 流程圖，透過視覺化圖表引導客戶了解整個流程。
價值產出
- 發現特定步驟可能無法融入既有工作流程
- 識別用戶可能感到困惑的地方，需要投資更多時間建立清楚的錯誤訊息
- 及早發現方向完全錯誤的情況
這種方法輕量且易於快速迭代，也有助於在大型投資專案中與技術領導層建立早期共識。
案例二：產品開發流程的全面研究
研究背景
透過利害關係人訪談發現，領導層認為的問題與實際開發者面臨的問題存在差異。
研究設計
- 目標：識別整個平台的痛點和機會
- 範圍：跨多個團隊的數十位工程師
- 方法：廣泛且深入的探索性研究
執行過程
- 邀請多個平台產品團隊的開發者參與訪談問題設計
- 讓開發者參與訪談過程
- 隨著訪談進行，逐步建構用戶旅程
- 分享視覺化內容，讓開發者提供不同流程階段的工具使用洞察
成果產出
建立了包含痛點嚴重程度評估的用戶旅程概覽，痛點評估基於：
- 頻率
- 嚴重程度
- 整體情感反應
長期影響
雖然這是較為耗時的研究專案，但產出的洞察和分析被團隊使用超過一年，協助多個團隊做出明智的路線圖決策，投資報酬率極高。
關鍵成功要素與建議 🎯
1. 堅持與客戶直接對話
核心原則：沒有任何替代方案能取代與客戶直接對話和觀察。
平台產品優勢：由於客戶通常是內部同事，他們往往很願意分享時間和想法。
預期成果：幾次訪談可能完全改變你的工作方法，或者證實你的直覺是正確的。無論哪種情況，都能獲得寶貴的洞察。
2. 建立系統化的研究流程
流程標準化
- 善用既有研究
- 制定詳細計畫
- 執行結構化訪談
- 系統化分析整合
- 有效分享傳播
持續改進
每次研究都是學習機會，持續優化研究方法和工具。
3. 團隊協作與跨部門整合
多元參與
鼓勵不同角色參與研究過程，獲得多元視角和專業洞察。
知識共享
建立研究成果的共享機制，讓組織其他部門也能受益。
結語：用戶研究驅動的平台產品成功之道 🌟
平台產品的成功與企業為終端用戶提供優質體驗的能力直接相關。成功的平台能幫助產品團隊高效且有效地提供優質用戶體驗，透過共享服務、簡化流程、確保可靠效能，或在技術轉型中合作開創新機會。
用戶研究不僅是避免產品失敗的保險，更是建立真正有價值產品的基石。透過深度理解開發者需求、終端用戶痛點，以及企業長期策略方向，平台產品團隊能夠在解決短期需求和實現長期策略目標之間取得平衡。
記住，你的客戶正依賴你的幫助。特別是在平台產品領域，客戶就是你的同事，他們通常很樂意與你分享時間和想法。投資於用戶研究，就是投資於建立真正以客戶需求為基礎的優秀平台產品。
免責聲明
本篇文章部分內容參考自公開可得之文章或影音資料，並透過人工智慧（AI）工具協助進行改寫與翻譯，經作者整理與審閱後刊登。文章內容僅供學習與參考用途，不代表原始資料作者之立場，亦不保證內容之完整與正確。
若您為原始資料權利人，對本篇內容有任何疑慮，歡迎與本站聯繫，我們將儘速處理。
