- 對一項功能說「yes」意味著對另一項功能說「no」
- 人和產品都很複雜，在用戶研究的有限環境中得到的回饋不一定和現實世界中人們使用（或不使用）產品的方式相同
- 界定範圍需要謙卑和勇氣
- 漸進式開發：將一個巨大的發行版本分解成許多版本，然後從每一個版本得到經驗教訓，用它來引導下一個版本。
- 優秀的PM會在早期驗證想法，所以可以迅速捨棄糟糕的想法，並花更多時間來建構真正可行的東西
- 最簡可行產品(MVP)
- 常見的錯誤
- 低品質的實驗：烤焦披薩的MVP
- 讓產品處於粗糙或不可持續的狀態
- 時間與價值：產品的改善要在交付之後才有價值
- 里程碑1可以提供很多價值 或 里程碑2還要很長一段時間 --->儘早交付
- 將工作分解為漸進式地發表，並儘早驗證
- 根據風險容忍度和友善程度：讓容忍度最高的用戶先使用
- 根據需求複雜性：從需求最簡單的用戶開始服務
- 根據能否定製：先加入滿足部分用例的固定選項
- 根據客戶類型或用例：從最短的清單開始做起
- 根據黏著時間長短
- 根據成本
- 注意
- 絕對不能排除精修程序
- 不要把範圍設的太小
- 圍繞著精實MVP推動團隊調整
- 團隊的可能擔心
- 擔心程式可能處於半成品的狀態
- 擔心在MVP完成之後，領導層可能會把人調離專案
- 擔心他們浪費時間撰寫一次性程式
- 如果團隊認同MVP，卻出現沒必要的範圍蔓延--->MVP沒有清楚被表達
- 對支援漸進式開發的系統進行投資
- 接受「不知道該建構什麼」的事實
- 用你的判斷力來優化正確的時間範圍：從MVP開始做起或盡量縮小工作範圍不一定是最適合的做法
- 工作的成本
- 工作帶來的客戶利益和商業利益
- 工作對團隊士氣的影響
- 想優化的時間範圍
- 假設獲得驗證的可能性
- 精煉與簡化假設
- 在組織中鼓勵MVP思維，並抵制完美主義
- 開發時間是有成本的（所有人的薪水）
- 延遲發表有機會成本
- 沒有從真正客戶得到回饋，追求的完美可能是錯的
產品經理每時每刻都是在做選擇，如果沒有帶著這樣的意識，很快就會被強勢或忙碌牽著走了，為了做好一個選擇，並不是要產品經理全能，我曾經就有過這樣的誤解；同時，還有一個錯誤：用自己的完美思維，應對著上層給予的任務。所以我訂了不可能的任務，超級大的範圍，還有不合理的時程，想當然爾，跌了個狗吃屎。本章節給予了一些工具指引和心態校正，要能真正發揮，我覺得還是回歸到和利害關係人的合作，尤其是時程面的事情，「做的人最大！」這句話不是沒有道理，相信大家都想要把事情做好。我那時候，覺得要把一個範圍定好、排序好很難，但我想，要是我當時願意好好認真傾聽工程師的聲音、用戶的聲音，將雙方的聲音好好流動，可能會對事情或自己更有幫助，是，是更有幫助而非解決問題，畢竟有人就有江湖（前輩如是說），江湖可是很複雜的！
看影片追技術