Increments 與 iterations 是基礎觀念，你身為 HoP 早就熟了。但資淺 PM 常搞混這兩件事，你要有能力解釋、畫給他們看、coach 他們。

核心區分：

• Increment（漸進）：加上新功能，讓產品範圍變大。像是一個一個越來越大的同心圓——1、2、3……每次交付都把功能的邊界往外推，產生新的 A、B、C 領域。
• Iteration（迭代）：改良既有功能——1 → 1.1 → 1.2，4 → 4.1……不是加新東西，而是把已交付的部分做得更好。

Zero to one phase（又叫 phase zero）指產品還沒上市前的階段。新創或大公司開闢全新業務線時特別常見。這階段挑戰很大——每個 increment 多大、要幾次 iteration 都要想——但也給了創意解法發揮的空間。

為什麼要漸進與迭代？#

要能幫 PM 回答這個問題，他們才會懂得用這兩個概念做優先排序與決策。三個主要理由：

1. 盡早出貨才能開始學習#

一旦拿到真實使用者回饋、觀察到真實行為，學習量會暴增。但前提是你出的東西夠大到有用——使用者用不動，你也觀察不到行為。要回答的問題像：

• 使用者會買嗎？
• 買了之後有在用嗎？還是買了就忘？
• 怎麼改能讓它更吸引人、更被使用、提供更多價值？

2. 讓開發團隊日子好過#

一個大功能悶頭開發好幾個月，會變超複雜。越頻繁釋出越好，能做到 continuous delivery 更棒。好處：

• 更少 merge conflict
• QA 更容易測試
• 更少非預期的 side effect

3. 盡早產生商業影響#

做產品的終點是賺錢。第一版 iteration 不會賺大錢（也不該以此為目標），但你要驗證有沒有人真的願意付錢。找到願意付錢的早期採用者，還能縮短 time to market。

總結：你要的是小、簡單、可出貨的東西，能替使用者創造價值、替團隊創造學習、並帶來商業影響（Figure 22-2）。

MVP 術語的混亂#

小、簡單、可出貨且能帶來這三種效果的東西，常被稱為 MVP——但 MVP 在產業裡被定義為一堆東西：

• minimum viable product
• minimum valuable product
• minimum viable prototype
• minimum viable platform
• ……

Eric Ries（The Lean Startup）的定義最通用：minimum viable product——讓團隊以最小投入取得最大「可驗證學習」的新產品版本。對多數組織這夠用。

Henrik Kniberg 的三段式（Figure 22-3）#

作者偏好的替代說法，分三輪：

• Earliest testable product：很粗糙的 prototype，測試想法與假設
• Earliest usable product：可交付基本功能的真正軟體產品
• Earliest lovable product：完整、讓人愛上的產品

別被術語戰爭綁住。挑一個貼合你組織的定義、解釋給團隊聽、然後統一使用就好。

Help Your PMs Sort It Out#

概念解釋完，PM 常常還是茫然。作者的 coach 流程：

1. 先讓他們搞懂軟體裡的使用者流程
2. 用「漸進」切 planning
3. 反覆問：「這個早期版本真的能讓使用者取得價值嗎？能真的用、真的測嗎？」

焦點永遠是：讓使用者實際體驗到你承諾的價值的那一刻。

範例：Job Board#

雙邊都有「價值遞進」的階梯：

• HR manager：能貼職缺 → 收到應徵 → 找到完美人選
• Job seeker：能找工作 → 能投履歷 → 拿到夢幻工作

起點可能只是「建幾個工作、列成 list」。下一步加搜尋。一步步疊，直到產品真的能讓兩邊達成終極目標。

兩個對立原則：省略 vs. 完整#

設計 increment 時要同時守住兩個張力：

The Art of Omission（省略的藝術）#

• 哪些是不可談判的？（例如要收錢，第一版就得有足夠價值）
• 這個現在需要做嗎？會帶來學習或使用者價值嗎？（HR 愛看 stats——但第一版要嗎？）
• 要 Create / Read / Update / Delete 都做嗎？（貼完職缺但不能編輯——刪掉重建也許短期可接受）
• 要自動化嗎？還是前期靠人工做就好？（發票可以先由一群 intern 手開）
• 能醜、粗糙嗎？（後台、資料追蹤介面可以）
• 需要 scale 嗎？現在就要嗎？

The Art of Completeness（完整的藝術）#

• 使用者能達到目標嗎？（貼職缺 vs. 收到應徵是兩回事）
• 客服支援必須可行
• 學習必須可行（埋好追蹤）
• 我們有先處理最大、最複雜、最高風險的問題嗎？

兩個原則缺一不可：產品對使用者要看起來夠完整、夠有用，但除此之外的東西——凡不是第一輪學習絕對必要的——全部先拿掉。

視覺化的幾種方式#

Whiteboard 切分（Figure 22-4）#

和 PM 一起在白板上切 zero-to-one 的 increment——連每個 sprint 大概分配什麼都先畫一版草稿。Sprint 分配最終要 PM 和團隊決定，但一份 first draft 能讓大家看同一張紙說話。

洋蔥圖 / 金字塔 / Flow（Figure 22-5）#

• 洋蔥：每一層是功能範圍的擴張
• 金字塔：層層堆疊顯示成長
• Flow：沿使用者流程標出增長點

Story Map（Figure 22-6）#

Jeff Patton 推廣的做法。用色彩編碼的卡片或便利貼貼牆，直接告訴團隊產品往哪裡長、接下來三個 iteration 是什麼。

Iteration 的典型演進#

Iteration 通常依以下順序走：

1. 1.1 修 bug / 小瑕疵
2. 優化效能
3. 檢視商業價值：功能真的有帶來該有的商業效益嗎？
4. 看 happiness、engagement、adoption 等使用資料
5. 砍掉沒價值的——拿掉期待落空的功能
6. Facelift 留下的——重做 UI/UX 讓它更好
7. Sunsetting（退場）——產品完成使命、沒人在用；先藏起來，再埋掉，最後關掉

退場也是一種 iteration。產品有生命週期，懂得結束和懂得開始一樣重要。

Telling the Story#

PM 選定路線後，還要把故事說給開發團隊、stakeholders、高層聽。資淺 PM 第一次做這件事會卡住——你要陪他們組故事、陪他們排練，不要丟著他們自己硬上。

產品傳教與說故事是下一章（Chapter 23）的主題——這是 HoP 必須主動示範、反覆練習的能力。