第十一章：評估產品機會
本章節的內容是產品設計最核心的源頭部分--確定做不做的問題，即我們的三大文件之首的brd文件，可以從以下點去驗證
通常情況下都是按領導的意願在做，你是執行者，而非決策者，所以。。。沒有所以，just do it.
第十二章：定義正確的產品
採用流水線並行開發產品，定義-封裝（非開發中的封裝，值得是不再加新需求）-開發-發布，同時定義下一版本。
應該流出一定的產品探索時間，因為1探索產品的過程不可**，2開發人員緊缺，領導的角度不能讓開發閒著，但往往開發不正確的產品才是更大的資源浪費。
所以應該正視源頭（第十一章）。
第十三章：產品原則
本庄是關於決策的一章，作為產品深知"勾搭成一體"的難度簡直就是上西天，但還是要不停的勾搭。書中的意思還是要拉攏，要優先考慮，如何做？回到源頭（十一章），可見源頭有多重要！！！團隊內的嚴重分歧非對認定的事實有爭議，大多是是對目標和目標的優先順序和解決方案有不同的理解。
制定產品原則意味著決定什麼重要、什麼不重要，哪些原則是根本的、戰略性的，哪些是臨時的、戰術性的。
第十四章：產品評審團
第十五章：特約使用者
平台產品要有示範麻豆。
第十六章：市場調研
第十八章：重新定義產品說明文件
道行尚短，不知重新定義之前的版本是啥樣。
雖然花了大量時間撰寫（產品說明文件），卻很少有人閱讀。更要命的是，對管理層和團隊來說，產品說明文件很容易成為乙個幌子，彷彿一切都進展順利。
理想的產品說明文件：完整地描述使用者體驗；準確地描述軟體的行為；受眾較廣；可以修改。
該書的作者也反對編寫冗長的使用者手冊，而強調高保真產品原型。同時強調原型還要有注釋，可以用wiki來解決。
第十九章：使用者體驗設計和實現
第二十章：基本產品--產品的核心功能
基本產品即產品的核心功能，mvp階段，產品和設計師設計產品高保真原型，找一技術參與設計原型，預估週期，使用者測試（很重要）
第二十一章：產品驗證--通過高保證原型驗證價值、可用性、可行性
第二十二章：原型測試
第二十三章：改進現有產品--不能一味的加功能
從另乙個角度改進，1明確目標2改善使用者體驗3不是滿足個別使用者，需求是一群人的需求。
第二十四章：平滑部署
版本的發行不必過於頻繁，會影響使用者已培養的習慣，須謹慎、理智的「平滑部署」方式。如兩個版本並行，小範圍逐步部署。
第二十五章：快速相應階段-發布後要快速跟蹤資料並作出合理響應
第二十六章：合理運用敏捷方法
第二十七章：合理運用瀑布開發方法
第二十八章創業型公司的產品管理
關鍵在於產品探索，mvp,可見第十一章的重要性，不然會很痛苦。
第二十九章：大公司如何創新
第三十章：在大公司施展拳腳
大部分人遊蕩在黑暗裡，他們只知道抱怨，去從不想辦法尋找電燈開關。
2016下第2本《啟示錄 人員篇》
內容簡介 如何打造有價值 具備可用性和可行性的網際網路產品，產品經理繞不開的一本書，在經歷一兩個上線產品之後，讀起來更有感覺了。本讀書筆記同樣也是書中內容和自身實踐感悟的結合。本書通過三部分講解 人員 流程 產品。人員就是定義和開發產品的參與者 流程是開發的步驟和一些相關的經驗 產品主要介紹了一些設...
《啟示錄》總結2 人員
1 產品經理的主要職責 評估產品機會 product opportunity 定義要開發的產品。2 互動設計師負責深入理解目標使用者，設計有價值的 可用的功能，以及使用者導航和產品使用流程。與產品經理合作，目標是確保產品具有可用性 使用者明白如何使用 和價值 使用者對產品的渴望程度 3 產品管理與產...
年末裁員事件背後的啟示錄（2）
接前一篇文章。1 從業者都應該想到的事情？a 專案被載 作為乙個專案的策劃者 無論是遊戲，還是嵌入式產品開發，電子商務開發等 都應該有對專案風險進行管理的能力。而專案風險管理的一般流程如下圖所示 軟體風險管理工作就是在風險成為影響軟體專案成功的威脅之前，識別 著手處理並消除風險的源頭。作為策劃者可以...