序言
原本以為這本書是講產品如何從客戶那里總結故事的方法和具體事例的，通過序言發現和開始的認知完全不同，書中應該把整個軟件從無到有的整個過程進行統一為：交付。書中會圍著交付的不同過程進行步步講解，期待。。。
第一部分：交付卓越產品，步步為贏
要知道正確的組織交付過程，共7個階段：
1.確定正確的產品方向。問題：怎么才知道是正確的產品方向？要能滿足眾多客戶所共有的某個真實需求。
2.盡可能清晰詳細的定義產品。
3.設計用戶體驗。問題：2和3階段如何做到迭代過程？
4.做一些基礎的項目管理工作，不要太多也不要太少。問題：如何判斷多少？
5.開始測試。
6.差不多可以準備發布了，不過在發布之前要清楚地知道怎樣才算成功，這就是建立一套衡量產品成敗的標準。
7.正式發布。
以上階段可見：縮小項目范圍，簡化用戶體驗，提升推進速度。整個過程越快，迭代就越快，交付的產品也就越好，因為每次迭代都會吸收上一次地阿呆中客戶提出的建議和意見。
問題：七個階段如何提升推進速度？
贏在使命和策略
使命：解決客戶的問題。
策略：找到一種獨特的方法滿足這個群體或細分市場的共同需求
1.1如何找到正確的需求
以客戶為導向，而不是以競爭為導向
必須專注于解決真正的客戶問題。還得確保這個問題是個很多客戶都存在的大眾問題。
Google Pack之所以成功，要訣便在于它解決的問題比我們最初意識到的那個問題要難得多。
1.2如何構建卓越的使命
團隊一定要有自己的使命。目標不一致會導致各自為戰。
何為卓越的使命：能夠喚起人們的興趣；提供言之有物且能指明方向的原則；適合印在T恤上；可以為一貫團隊找出使命。
需要的是一個能夠反映代表性的使命，而不是一個面面俱到的使命。
1.3如何制定正確的策略
策略是指在競爭對手的壓力下，利用公司獨特的優勢來爭取目標用戶的錯略計劃。不是產品描述、不是詳細計劃。需要闡明：客戶、公司和競爭。
本質：如何長期未客戶提供比競爭對手更優質的產品。
方法：用最多三段文字寫下來，再濃縮成一段文字。越簡短的策略越容易實現，也越容易獲得他人的認可。
使命和策略制定需要大家認同和支持。然后再開展細化的工作。
贏在產品定義
交付的下一個階段是讓你的產品方案具體且可理解。通過制定使命和策略，你知道了你的客戶是誰，他們的需求是什么。也知道如何做才能比對手更出色、更具備差異性。
如何證明臆斷是否正確：吧產品提供給客戶使用，然后聽聽他們的意見。
產品定義主要分為10步。每一步都建立在上一步完成的基礎上。10步是不是太多了？
2.1. 撰寫新聞稿。新聞稿：一篇向市場宣布將要推出新產品的通告。應簡明的傳達關于產品的關鍵信息。新聞稿的媒體屬性注定了它天生就更簡潔、可讀性更強且更關注真實的產品能給真實用戶帶來了什么價值。六大要素：產品命名、發布時間、目標客戶、解決了什么問題、如何解決（務必簡明扼要）、CEO的公開贊辭。不要深入細節，很少包含圖片且從不包含財物信息。從用戶視角出發。
2.2. 創建并不斷更新FAQ文檔。隨著產品方案的不斷細化，各種問題也層出不同，其中大部分都非常重要，之處了產品的不足之處。吧這些問題記錄到內部FAQ文檔中并盡力回答。分為外部問題和內部問題。好處：能節省大量回復郵件的時間，還能抵御一些內部責難；需要整理所有面向公眾的內容時，FAQ是一個很有價值的資源。
2.3. 繪制線框圖或流程圖。流程圖可以幫助你準確的解釋用戶工作流和系統交互相關問題，簡要線框圖可以幫助具象化產品各環節的用戶體驗，并在之后的匯報中發揮不可思議的作用。
2.4. 撰寫產品單頁或10分鐘的演示文稿?，F在需要去爭取工程團隊、管理層、VC或其他利益相關方的初步支持。產品單頁或演示文稿都是新聞稿的延伸，他們增加了市場機會（用戶量）、收益機會（解決方案的價值）和長期競爭優勢這三方面內容。需包含的五個要素：產品名稱、目標客戶+數量有多少、解決了什么問題+這個問題對于目標客戶有多大價值、解決方案+與類似產品的長期優勢、何時交付+主要的里程碑有哪些、團隊背景（針對VC）。演示的最佳方式是先講用戶現狀，再延伸開來（參考五大要素），迅速把藥店講完后再留出時間供這些聰明的聽眾就他們關心的點刨根問底。
2.5. 在FAQ中添加API文檔。API文檔可以說明你的團隊如何與其他團隊協作、外部開發者如何使用這套系統以及你需要儲存什么數據。API最重要的作用是明確系統的各個邊界。API的詳細程度？是不是可以適當放寬？
2.6. 撰寫功能規格文檔。用來詳細描述用戶應該如何體驗產品的文檔。它不包含系統在后臺如何運行之類的技術細節，這類細節應該包含在工程主管撰寫的技術規格或設計文檔中。此時需要寫出所有部分的詳細描述？在完成共10步過程中是不是和敏捷中的產品story細化過程是否一致？
包含九個內容：1. 簡介（使命和策略）。2. 目標與非目標。3. 用例或用戶場景。4. 原型圖或線框圖。5. API。6. 負載規劃。7. 依賴。8. FAQ和開放問題。9. 關鍵事件。
這里說的用例（用戶場景）和UML中的用例是否是一個含義？
2.7. 邀請設計團隊和工程團隊主管參與產品評審。
2.8. 找客戶測試產品概念。
2.9. 命名、定價以及預測收益。定價和預測收益是否可以忽略或簡化，畢竟軟件行業的變化比較快，而且國內大家沒有花錢在軟件上的意識？
2.10. 想管理層匯報。
贏在用戶體驗
用戶體驗不僅是產品的外觀樣式，它還是產品的使用方式。交付卓越產品就是指交付卓越的用戶體驗。你的工作不是去解決所有的用戶體驗問題，而是確保產品盡可能提供最好的用戶體驗。為了讓設計團隊發揮出最佳水平，需要了解以下內容：
3.1了解各類設計角色：
用戶體驗：關注用戶如何完成任務以及該如何優化向用戶展現信息的方式。工具有流程圖、原型圖、可點擊原型。用戶使用流程？
用戶體驗設計師：對信息架構尤為關注。對信息進行優先級排序？
視覺設計：是關于如何通過一種即賞心悅目、奪人眼球又清晰明了的方式來展示內容的一門學問。相當于裝修？如果以上三個角色有不同意見應如何協調?
用戶體驗研究：是用戶體驗的一個特殊組成部分，他專注于研究用戶是如何看待你的產品的。通過數據統計、調研等幫助研究用戶對于產品的想法。但他不管解決提出的問題。
角色建模：提供給你和你的設計團隊、工程團隊一個蘋果設計的框架。是否和UML中的角色建模是一樣的概念？
3.2了解如何評價設計：在沒有接受過設計師的訓練和相關知識時如何檢查原型或設計是否優美、直觀？可以使用下面的6個問題。
該用戶界面要求用戶完成的最重要的任務是什么？這個問題確認主要角色的主要任務和設計的主要任務是一致的。
這是最簡單的解決方案嗎？簡單化框架：SHE（簡化、隱藏、附加）
信息是否組織得當？
設計是否易用并且一目了然
標準是否一致
能否減少用戶點擊次數
3.3了解如何與設計師溝通：應避免直接說問題，從用戶、原則、慣例、數據之類的側面或原始出發點溝通
以用戶的口吻說話
以提問的方式建立共識
反復講述業務目標，如果有些目標相互沖突，則反復簡書他們之間的相對優先級。
用數據說話
一共一些競爭對手或類似體驗中運作良好的案例
