概述#

在啟動第一個「客戶價值創造 Sprint」之前，我們需要一份初始的 product backlog；而要產出 product backlog，首先需要一個 產品願景（product vision）。許多組織也會建立初步的 產品路線圖（product roadmap），描繪一系列漸進式發布。作者將這些活動統稱為 Envisioning（願景規劃），即產品層級的規劃。

Envisioning 的目標是：

• 闡述產品想法的本質
• 建立關於如何實現它的粗略計畫
• 讓決策者有足夠的信心，決定是否進入下一階段的開發資助

Envisioning 不等同於傳統的重量級專案啟動（project chartering）。在 Scrum 中，我們不相信也不試圖在開始前就知道所有細節，但承認決策者需要足夠的願景與資訊來做出資助決定。

時機#

Envisioning 是一項持續性活動，而非一次性事件。

其流程為：

參與者#

• Product Owner 是唯一必要的參與者
• 通常還包括內部利害關係人、市場研究人員、UX 設計師、系統架構師等
• 理想情況下，ScrumMaster 和開發團隊也應參與，但常因尚未獲得資助而無法加入

流程#

輸入（Inputs）：

輸出（Outputs）：

• 產品願景（Product Vision）
• 初始產品 Backlog（Product Backlog）
• 產品路線圖（Product Roadmap）
• 其他有助於達到信心門檻的產出

SR4U 範例#

作者用一個虛構產品 SmartReview4You（SR4U） 來說明 envisioning 流程。公司 Review Everything, Inc. 是線上評論領域的領導者，但面對競爭壓力，需要創新產品來超越對手。

市場研究發現使用者的兩大痛點：

• 花太多時間區分「真實評論」與「可疑評論」
• 評論數量太多，難以得到準確的整體印象

由此產生了 SR4U 的構想 — 一種革命性的方式來辨識、過濾和展示線上評論，並包含可訓練的搜尋代理。

管理層授權了兩週時間完成 envisioning，並指派 Roger 擔任 product owner，配備兩名過濾 SME、一名市場研究人員和若干利害關係人。

管理層要求 Roger 產出：

• 初始產品願景、product backlog 和產品路線圖
• 核心假設驗證 — 使用者是否顯著偏好 SR4U 過濾後的結果
• 其他重要假設的描述及其驗證指標
• 需要解決的已知未知問題（known unknowns）清單

願景建立（Visioning）#

在 Scrum 中，願景不是數百頁的長篇文件。好的願景應該簡潔有力，為實現者提供清晰的方向。甘迺迪的登月願景僅用 31 個字就表達了一個大膽而明確的方向。

利害關係人價值領域#

願景通常以利害關係人如何獲得價值來表達，包含以下類別：

願景格式#

常見的願景格式包括：

SR4U 團隊選擇了新聞稿格式，從使用者和 CEO 的角度描述了產品發布的成功景象，清楚傳達了核心價值主張：幫助使用者快速找到無偏見的評論。

高層級 Product Backlog 建立#

有了願景，就可以建立高層級的 product backlog items。在 envisioning 階段，以 Epic（史詩級使用者故事） 為主。

SR4U 團隊（Roger、利害關係人與架構師 Yvette）共同撰寫了初始 epic，例如：

• 身為典型使用者，我希望教導 SR4U 丟棄哪些類型的評論
• 身為典型使用者，我希望有一個簡單的 Google 風格搜尋介面
• 身為典型使用者，我希望 SR4U 自動監控網路上的新評論
• 身為進階使用者，我希望指定 SR4U 使用哪些來源
• 身為產品供應商，我希望在自己的網站上展示 SR4U 品牌的評論摘要

產品路線圖定義（Product Roadmap Definition）#

有了願景和高層級 backlog 後，即可定義產品路線圖 — 一系列漸進式發布計畫。

核心原則#

• 始終採用漸進式開發，聚焦較小、較頻繁的發布
• 每次發布聚焦於一組最小可發布功能（Minimum Releasable Features, MRFs） — 必須包含在發布中的最小功能集合，也被稱為 MVP 或 MMF
• 每個發布都應有明確的發布目標（Release Goal）

固定週期發布策略#

使用固定週期發布（例如每季一次）的優勢：

• 容易理解，提供可預測的發布節奏
• 建立節拍（cadence），有助於資源調配
• 讓不同團隊可以同步計畫

路線圖考量因素#

1. 客戶區隔 — SR4U 先針對「典型使用者」，未來再服務「進階使用者」及「產品供應商」
2. 架構/技術議題 — 先做 Web 瀏覽器版本，未來再做 iOS、Android、開放 API
3. 市場事件 — 如年度 Social Media Expo 大會的發布時機
4. 路線圖範圍 — 不要規劃太遠，只規劃到合理且必要的範圍

SR4U 的九個月產品路線圖分為三個季度發布：

其他活動#

Envisioning 可包含任何有助於達到信心門檻的工作：

SR4U 的知識獲取 Sprint#

Roger 團隊在 envisioning 期間進行了一個知識獲取 Sprint，目的是驗證核心假設：使用者是否真的偏好過濾後的評論結果。

做法巧妙且低成本：

1. 建立一個簡單的 Google 風格搜尋頁面
2. 使用者提交查詢後，由 SME 手動過濾（而非自動化）
3. 隔天透過 email 同時提供過濾與未過濾兩組結果（使用者不知道哪組是哪組）
4. 訪談使用者了解偏好

這個做法的精髓在於：在投入大量資源開發自動化系統之前，先以最低成本驗證核心價值主張。如果 SME 手動過濾都無法產生令人信服的結果，那自動化系統更不可能成功。

經濟合理的 Envisioning#

Envisioning 必須以經濟合理（economically sensible） 的方式進行。它是一筆投資，目的是獲取管理層做出明智決策所需的資訊。做太少會讓團隊毫無準備；做太多則產生大量尚未驗證的庫存，可能在獲得實際回饋後被丟棄。

1. 設定務實的信心門檻（Target a Realistic Confidence Threshold）#

信心門檻定義了決策者做出下一步 go/no-go 資助決定所需的最低資訊水準。

門檻設太高的後果：

前期規劃應該是「有幫助但不過度」的。新的高風險創新產品的門檻可能較高，但長期存在的核心系統的下一版本門檻通常較低。

SR4U 的管理層設定門檻為「足夠好」或「勉強足夠」，不要求完整的專案計畫，而是要求對目標有清晰的理解以及衡量結果的方式。

2. 聚焦短期範圍（Focus on a Short Horizon）#

• 不要試圖一次規劃太多，主要聚焦在第一個候選發布的必備功能
• 過廣的規劃範圍很可能是浪費時間
• 對於創新產品，大部分假設尚未驗證，過早規劃只是將假設建立在假設之上

3. 快速行動（Act Quickly）#

• Envisioning 不應是漫長的過程，要快速且高效
• 市場時鐘從商業機會被發現的那一刻就開始計時
• 設定 envisioning 的預期完成日期有助於推動緊迫感
• 不同想法需要的 envisioning 時間不同，但都應有合理的邊界

4. 為已驗證的學習付費（Pay for Validated Learning）#

• 從經濟角度評估 envisioning 活動，看它們如何貢獻於已驗證的學習
• 警惕那些產生大量「高度不確定資訊」的預測性活動 — 這些資訊被認為有效但尚未真正驗證
• 大量低價值、高度不確定的資訊會混淆判斷，讓人在確定性幻覺下做重要決策

SR4U 的管理層願意在 envisioning 期間花錢驗證核心假設（使用者偏好過濾結果），因為這比花大量資金開發產品後才發現假設錯誤要划算得多。

5. 使用漸進式/暫定資助（Incremental/Provisional Funding）#

• 不要在第一次 envisioning 就試圖產生足以批准所有未來開發的資訊
• 只產生足以資助獲取下一個重要、關鍵的真實世界知識或回饋的資訊
• 資助決定應隨著更好的資訊不斷被做出和修正
• 分配了資金不代表一定會花掉 — Sprint 回饋可能導致轉向或終止

SR4U 的政策是資金從不以大筆方式給予，而是給予足夠的量來驗證下一個重要假設。

6. 快速學習與轉向（Learn Fast and Pivot）#

也稱為 Fail Fast — 快速且廉價地完成 envisioning，然後快速驗證假設：

• 如果願景符合商業期望 → 堅持（persevere）
• 如果不符合 → 轉向（pivot） 重新規劃，或乾脆終止產品
• 從快速起步和快速發現錯誤中學習，通常遠比花大量時間金錢確保「正確」決定後才發現錯誤要便宜得多

flowchart TD
    A[快速完成 Envisioning] --> B[驗證核心假設]
    B --> C{結果符合期望?}
    C -->|是| D["堅持（Persevere）\n繼續開發"]
    C -->|否| E{是否有其他可行方向?}
    E -->|是| F["轉向（Pivot）\n調整產品方向"]
    E -->|否| G[終止投資]
    F --> A

小結#

本章透過 SR4U 範例詳細展示了 envisioning 的完整流程：建立產品願景、高層級 product backlog、產品路線圖，以及如何透過知識獲取 Sprint 驗證核心假設。核心訊息是：envisioning 應該經濟合理、快速行動、聚焦短期，並以漸進式資助和快速學習的方式，讓前期產品規劃工作與後續的 Scrum 開發流程良好對齊。