本章關鍵句

• 對一項功能說「yes」意味著對另一項功能說「no」
• 人和產品都很複雜，在用戶研究的有限環境中得到的回饋不一定和現實世界中人們使用（或不使用）產品的方式相同
• 界定範圍需要謙卑和勇氣

概念與框架

• 漸進式開發：將一個巨大的發行版本分解成許多版本，然後從每一個版本得到經驗教訓，用它來引導下一個版本。
  • 優秀的PM會在早期驗證想法，所以可以迅速捨棄糟糕的想法，並花更多時間來建構真正可行的東西
• 最簡可行產品(MVP)
  • 常見的錯誤
    • 低品質的實驗：烤焦披薩的MVP
    • 讓產品處於粗糙或不可持續的狀態
• 時間與價值：產品的改善要在交付之後才有價值
  • 里程碑1可以提供很多價值 或 里程碑2還要很長一段時間 --->儘早交付

責任

基礎

• 將工作分解為漸進式地發表，並儘早驗證
  • 根據風險容忍度和友善程度：讓容忍度最高的用戶先使用
  • 根據需求複雜性：從需求最簡單的用戶開始服務
  • 根據能否定製：先加入滿足部分用例的固定選項
  • 根據客戶類型或用例：從最短的清單開始做起
  • 根據黏著時間長短
  • 根據成本
  • 注意
    • 絕對不能排除精修程序
    • 不要把範圍設的太小

進階

• 圍繞著精實MVP推動團隊調整
  • 團隊的可能擔心
    • 擔心程式可能處於半成品的狀態
    • 擔心在MVP完成之後，領導層可能會把人調離專案
    • 擔心他們浪費時間撰寫一次性程式
  • 如果團隊認同MVP，卻出現沒必要的範圍蔓延--->MVP沒有清楚被表達

高級

• 對支援漸進式開發的系統進行投資

成長實踐

基礎

• 接受「不知道該建構什麼」的事實

進階

• 用你的判斷力來優化正確的時間範圍：從MVP開始做起或盡量縮小工作範圍不一定是最適合的做法
  • 工作的成本
  • 工作帶來的客戶利益和商業利益
  • 工作對團隊士氣的影響
  • 想優化的時間範圍
  • 假設獲得驗證的可能性
• 精煉與簡化假設

高級

• 在組織中鼓勵MVP思維，並抵制完美主義
  • 開發時間是有成本的（所有人的薪水）
  • 延遲發表有機會成本
  • 沒有從真正客戶得到回饋，追求的完美可能是錯的

產品經理每時每刻都是在做選擇，如果沒有帶著這樣的意識，很快就會被強勢或忙碌牽著走了，為了做好一個選擇，並不是要產品經理全能，我曾經就有過這樣的誤解；同時，還有一個錯誤：用自己的完美思維，應對著上層給予的任務。所以我訂了不可能的任務，超級大的範圍，還有不合理的時程，想當然爾，跌了個狗吃屎。本章節給予了一些工具指引和心態校正，要能真正發揮，我覺得還是回歸到和利害關係人的合作，尤其是時程面的事情，「做的人最大！」這句話不是沒有道理，相信大家都想要把事情做好。我那時候，覺得要把一個範圍定好、排序好很難，但我想，要是我當時願意好好認真傾聽工程師的聲音、用戶的聲音，將雙方的聲音好好流動，可能會對事情或自己更有幫助，是，是更有幫助而非解決問題，畢竟有人就有江湖（前輩如是說），江湖可是很複雜的！