這是一本在講產品管理的書籍，作者Melissa Perri也實際開了一間線上學校專門培養產品長(CPO)。
書中開頭點出許多公司因錯誤目標而陷入了「建構陷阱」。公司運作應建立在「價值交換」，也就是公司必須利用「產品或服務」來解決顧客的「問題、欲求、需求」。但許多公司卻只在意「產出(ouput)」，通常是容易被量化的指標—-像是產品與功能數量、發布次數或開的速度。而「成果(outcome)」才是最終交付的功能。好的成果要能解決客戶問題，顧客才會願意付錢，這也就是為何「價值交換」同時有利於客戶及企業。
作者認為「專案管理」注重的是「時程」，而理想中的「產品管理」應該是注重「原因」。作者也不喜歡「產品負責人」或是「產品CEO」/「迷你CEO」這類稱呼。因為產品管理並不是單純決定產品的功能或是產品何時要進行或何時要廢止，真正的產品管理應該要能告訴成員：「為何要建構這個產品？提供給客顧的價值為何？」
Scrum所定義的「產品負責人」：
- 定義產品待辨清單，為開發團隊創建可行動的使用者故事。
- 整理並排序待辨清單中的工作。
- 接受完成的使用者故事，以確保工作符合標準。
但作者提出了反動，認為Scrum的「產品負責人」沒有回答如下的問題：
- 我們如何決定價值？
- 我們如何衡量市場上我們產品的成功？
- 我們如何定價和包裝我們的產品？
- 我們如何將產品推向市場？
- 要建構還是購買？
- 我們如何整合第三方軟體以進入新市場？
產品負責人只是一個「角色」，在Scrum團隊中不一定需要產品管理的能力。而產品經理是一個「職業」，產品經理要能夠將業務目標與客戶目標結合起來以實現價值。透過創建或優化產品來找出目標，都要依靠解決實真客戶問題的觀點，是產品經理非常重要的技能。
此書也定義了產品經理的升職階梯，作者建議不要使用「產品負責人」的職位，從最基層的「副產品經理」開始，基層的產品經理著重「戰術」然後提升至「營運」層次。最後到產品VP以及CPO，這些高層要關注「策略」，除此之外也必須了解公司財務。但許多高層想要的是「計劃」而不是「策略」，如果每年或每月都在更改策略那應該將之視為計劃，計劃只會在待辦清單中加上更多功能。而略策應該是一個可以展開的決策框架，要能超越功能的迭代，更聚焦在高階的目標和願景。
作者已經不使用最小可行產品(MVP)這個詞，他發現有些公司不管建構的內容，單純將第次發佈的版本視為MVP。他認為這樣會落入建構陷阱，重點應該是多從實驗學習，方式包含：
- 服務人員concierge：服務人員會將最終結果人工傳達給客戶，但並不像是最終的解決方案，所以被實驗的客戶會知道測試是人工進行。因為不用寫程式，可以快速開始。
- 奧茲大帝wizard of Oz：會造出一個外觀近似成品的測試品，客戶將不知道測試是人工進行，但底層運作是工作人員用人工執行。
- 概念測試：使用投影片或是影片像潛在客戶展示，並沒有建立樣本或原型。此法必須定義一個合格標準，通常是要能得到使用者的「請求」，例如客戶的e-mail或是訂金。
我認為本書提出了不少問題點，的確是造成「建構陷阱」的原因。解決的方法就是要找出真正對客戶有價值的產出，不過實際上沒有明確的執行方式，作者所說的「策略」也相當抽象。雖然要找出正確的方向不一定要像敏捷開發或lean startup一樣強調極小且快速的迭代，不過在沒有公式解的情況下，我覺得這是一個很好的嘗試。作者強調的「價值交換」我也相當認同，但還需要一個有系統的運作方式會更讓人信服。
書中附件：作者決定一家公司是否為產品主導型的六個問題：
你建構的最後一個功能或產品想法是誰提出來的：
應該是團隊提的。管理者設定了目標，而團隊則有空間找出如何實現這些目標。產品經理應負責發現並解決使用者問題，解決方案的想法可能偶爾來自管理部門，但不應該是常態。當團隊不能為自己建構的東西負責，也無法理解為為要建構它時，這是一個危險。
你決定要終止的最後一個產品是什麼？
不健康的產品管理常常無法終止不能幫助公司實現其目標的產品或想法。原因可能包括：已經向客戶承諾該想法、預算不能改、不能拒絕管理者。
你上次與客戶談話是什麼時候？
成功的組織不僅允許產品經理與客戶交談，還要鼓勵這樣做，並視為工作重要的一部份，不應將所有時間花在編寫使用者做事。
你的目標是什麼？
如果產品經理不能闡明目標，表產品管理不佳。如果目標注重輸出而不是成果，也意味著問題。產品經理的目的，是透過為客戶創造價值來為企業創造價值。如果不了解公司願景，那要如何找出實現的方法呢？目標應以成果為導向、可行動且在整個組織中清楚傳達。
你目前在做什麼？
成功的產品經理會更加熱情談論產品開發團隊正在解決的問題，相比談論發布的解決方案。
你的產品經理是什麼樣的？
作為產品經理，我們希望在一個該角色得到尊重和重視的組織中工作。產品管理部門沒有被重視的原因有兩個：產品經理被認為太強，或被認為太弱。