作者在開場有個小自白:這一章標題雖然是「假設驅動的產品開發」,但本質上就是在談產品探索(product discovery)。為什麼不直接叫「Product Discovery」?因為這個詞被用到爛,每個人都覺得自己已經很懂、做得很好——於是就跳過章節。作者希望你別跳過。

好的產品探索,就是在降低「把錯的東西做得很漂亮」的風險

以下是 Petra Wille 點名要最小化的四種風險(Figure 16-1):

  • No value(沒人要用、沒價值)
  • Hard to use(難用)
  • Not able to build/ship(做不出來、出不了貨)
  • Doesn’t work for the business(商業上跑不動)

Figure 16-1: The four main risks you want to minimize: Building something that has no value, is hard to use, you...

章首引述 Roman Pichler:

If you can’t confidently state why people are going to use your product, who those individuals are, what makes your product stand out from the crowd, and why it’s worthwhile for your business to develop and provide the product, then you are not in a position to build the actual solution.

作為產品主管(Head of Product, HoP),這一章會幫你:

  1. 理解什麼是產品探索
  2. 確保基本要素就位,讓假設驅動的探索能真的跑起來
  3. 幫 PM 掌握核心概念
  4. 幫 PM 依經驗等級打磨工具箱

用 COVID-19 類比理解產品探索#

作者用 COVID-19 疫情作為全球性的探索類比,抓出好的探索需要的五個要素

  • 真實問題 + 共同目標:COVID-19 會害死人、傳得快 → 在不殺死經濟的前提下,最小化死亡人數
  • 策略當過濾器:首要策略是「flatten the curve」(壓平曲線)——是否有助於達到這個策略,就是判斷要不要做的濾網
  • 跨職能團隊:政治人物、醫師、病毒學家、經濟學家、心理學家……一起解題
  • 可用的資料:儀表板、趨勢圖、各國數據——但要注意資料背後的故事(例如德國週末不測,週末數字必定下降)
  • 急迫感:必須「現在」就開始實驗。例如封城(lockdown)本身就是一個大型實驗,風險低、可能性高、初期信號不錯,於是就試了

疫情讓全世界進入全速 discovery 模式。沒有全球總舵手告訴大家要做什麼,靠的是高對齊 + 高自主:目標與策略帶來對齊,團隊的執行、實驗與資源配置則高度自主。

這就是產品探索的本質:不斷提出假設並驗證,以最大化對使用者的價值與對公司的影響力。

HoP 要確保的基本盤#

在要求 PM 全面 hypothesis-driven 之前,先檢查下列要件是否齊全。這是 HoP 的工作(但不必親力親為,確保有人在做就好):

  • 共同目標(Shared goal)
  • 策略(Strategy)可作為過濾器
  • 對的人(Right people)願意在跨職能團隊裡工作
  • 容許實驗的文化時間——實驗過程本質上亂,但那是常態

如果這些基礎缺一角,別急著推假設驅動——先把地基補好。不然只會讓 PM 在半成品環境裡挫敗。

核心概念(給 PM 的 coaching 素材)#

假設驅動方法(Hypothesis-driven approach)#

完整路徑:

觀察 & 資料點 → 提出假設 → 排序(哪些最致命)→ 寫成假設陳述 → 驗證 or 反證

關鍵做法:

  • 把假設顯化:寫下來、貼牆上、排序
  • 小塊進行:不要做成一個龐大流程。「現在的假設是?最有潛力的哪幾個?要怎麼拿到資料?」
  • 資料支持 → 建下去;資料不支持 → 調整假設或換下一個

Figure 16-2: The hypothesis-driven approach and what to optimize for once it's in place

Laura Klein 的假設排序框架#

Step 1:寫下所有現有假設。

Step 2:分成三類:

  • Problem assumptions(關於使用者):例:「身為懶爸媽,我需要月訂尿布來省下採購時間。」
  • Solution assumptions(關於解法):「我們認為訂閱制 + 直送平台能解決。」
  • Implementation assumptions(關於執行):「我們能低成本進貨、能談到好的物流方案。」

Step 3:把每個假設放到兩軸尺度上:

  • 若錯了會多致命?(devastating vs. annoying)
  • 有多確定它是對的?(likely vs. uncertain)

Step 4:依 Figure 16-3 決定要測試哪些:

  • 落在「致命 + 不確定」:最優先投資學習資源
  • 落在「不致命 + 不確定」:有潛力就試,沒潛力直接砍
  • 落在「致命 + 看起來很可能對」:依風險偏好決定要不要保險地做實驗
  • 落在「不致命 + 很可能對」:先不用管

Figure 16-3: Laura Klein's framework for validating assumptions

寫出恰當的假設陳述#

假設陳述要讓團隊能對齊:怎麼衡量影響、何時停止研究、何時做決定。對應三類假設,各有模板:

  • Problem validation(valuable)

    We believe that this problem/challenge exists for this persona and solving it will result in customer behavior and company gain.

    We will know this to be true if …

  • Solution validation(viable + usable)

    We believe that this solution will generate value for persona Y.

    We will know this to be true if …

  • Implementation validation(feasible)

    We believe this implementation of solution A for persona Y will deliver the value we want.

    We will know this to be true if …

「把對的點子做出來」vs.「把點子做對」#

借用 IDEO 版的 Double Diamond(雙菱形)模型(Figure 16-4):

  • Problem space(探索問題,把對的點子找出來):從 what iswhat could be
  • Solution space(把點子做對):從 what should bewhat will be
  • 每個 diamond 都有**發散(diverge)收斂(converge)**兩階段

Figure 16-4: IDEO's version of the double-diamond mental model

在 1:1 裡,用這個模型問 PM:「這個 idea 你現在在 discovery 流程的哪一段?」——即可快速對齊彼此認知,也方便對高層解釋。

不要只靠單一實驗或資料點做決策#

很多公司跑一個 A/B 測試就拍板,或是三場使用者訪談決定下三個月的走向。都不對。Henrik Kniberg 的三支柱提供一個更扎實的依據:

  • 資料(data)
  • 使用者回饋(user feedback)
  • 直覺(gut feeling)

三個都說 Go → 衝;兩個說 Go → 強信號;只有一個 → 再做更多研究。

直覺需要時間養成。PM 與團隊每多理解一點使用者、公司與世界,直覺就更準。這也是為什麼 discovery 不能外包——外包等於把未來會用到的直覺,交給一個不在乎你產品的人去累積。

提防瀑布式思維#

產品開發已從「一年燒兩次 CD」演進到「持續交付」;discovery 也該如此

  • 大探索要切片,持續產出洞見
  • rock / pebble / sand 時間管理框架(見 Ch.18):把 discovery 深度配給 rocks 與「危險的 pebbles」,sand 則用最輕量流程
  • 像 COVID-19 一樣——不可能等到看清全貌才行動。只要價值、可用、可行、可持續有足夠證據,就先動

Marty Cagan 的說法:Discovery 與 Delivery 是 dual-track——永遠同時在跑,永遠在交付、在學習。

聚焦結果與更快學習#

在 1:1 裡常問 PM:

  • 我們學得夠快嗎?工具要不要換?
  • 我們有優化結果嗎?還是只是在「為了 discovery 而 discovery」?

好答案通常是:

  • 「我們會更快,因為每次 discovery 都在累積直覺。」
  • 「我們會更快,因為我們有熟練的流程、工具、框架。」
  • 「我們會更快,因為要試一個看起來很有潛力的新框架。」

幫 PM 打磨工具箱#

如何處理資料#

  • North Star 指標:找出全公司可共用、代表「你真正交付承諾價值的那個時刻」的單一指標(營收不是 North Star
  • KPI 樹:把 North Star 放頂端,往下展開「哪個指標直接影響它?」
    • 證據充分的連結畫實線
    • 假設性連結畫虛線
    • 視覺化整個追蹤體系,帶來透明、對齊、聚焦

Figure 16-5: A supersimple KPI tree I'm often asked by HoPs how they can help their PMs come up with new ideas and assumptions.

  • 案頭研究(desk research):看統計、研究、競爭者動態、macro 趨勢——很多 PM 根本沒做。做了才會看到 pattern、冒出新假設

訪談技巧#

每個產品開發團隊成員都該會做訪談(無論使用者或利害關係人)。

訪談做得好是最佳洞見來源;做不好會讓團隊對著錯的方向狂吠。

推薦延伸閱讀:Teresa Torres、Nick Babich、Veronica Cámara 等人的相關文章與著作。

關於人的知識#

在「找對問題」階段,幾個概念很好用:

  • Value Pyramid(價值金字塔):產品提供的價值分四層——functional、emotional、life-changing、social impact。越多層被滿足,顧客忠誠度越高、營收成長越穩健
  • 行為經濟學(behavioral economics)習慣養成
  • 《The Paradox of Choice》(Barry Schwartz):選項越多越難決定、也越不滿意——直接影響導航、列表呈現等 UX 設計
  • 認知偏誤(cognitive bias):過程中每個人都要持續自我校準

關於數位產品與商業模式的知識#

  • 不同商業模式(SaaS、電商、廣告、平台訂閱……)的驅動因子差異巨大
  • 換商業模式或擴張商業模式,可能開啟全新問題空間與解法空間
  • Funnel(漏斗):要確保 PM 知道怎麼畫漏斗、抓漏斗數據、做成長駭客

Figure 16-6: Using a funnel to visualize how new customers are acquired

作者經驗:很多團隊看到漏斗圖時 (a) 從沒看過 (b) 不知數字從哪來 (c) 開始蒐集後才發現沒人追蹤過——這是警訊

實驗類型與時機#

實驗百百種:

  • 單人訪談 → 小線索
  • 假門測試(fake door)→ 強證據
  • 嚴謹 A/B 測試 → 複雜度高
  • 原型可用性測試 → 準備要時間
  • 輕量快測 → 立即可做

推薦 PM 必讀三本:

  • Testing Business Ideas(David Bland、Alex Osterwalder)
  • The Lean Startup(Eric Ries)
  • Sprint(Jake Knapp)

記錄與分享洞見的方式#

很多人執著於「哪個方法最好」——重點不是方法,是核心概念

  • 只要 PM 能清楚說明:使用者分群、當前假設、問題、可能解法,用什麼工具都行
  • 可用:Story MapsJTBD(Jobs To Be Done)、persona、願景影片……
  • 沒有一刀切的框架,各 PM 依熟練度選工具即可

規劃與導航探索#

  • Story Maps:用顏色編碼每一張卡,標示何時要深入
  • Teresa Torres 的 Opportunity Solution Tree:視覺化總目標 → 機會假設 → 候選解法 → 實驗——這就是 discovery roadmap
  • 一張能看到所有 discovery 進度的任務板不可或缺(下一章 Discovery/Delivery 會再細談)

延伸閱讀#

作者在章末列出完整書單與資源(詳見 strongproductpeople.com/further-readings),重點包括:

  • Sylvia Lai《5 steps to a hypothesis-driven design process》
  • Karl Popper 的 Falsification(否證論)
  • Predictably Irrational(Dan Ariely)
  • The Art of Thinking Clearly(Rolf Dobelli)
  • Interviewing Users(Steve Portigal)
  • Trustworthy Online Controlled Experiments(Kohavi、Tang、Xu)
  • Escaping the Build Trap(Melissa Perri)