內容簡介：如何打造有價值、具備可用性和可行性的網際網路產品，產品經理繞不開的一本書，在經歷一兩個上線產品之後，讀起來更有感覺了。本讀書筆記同樣也是書中內容和自身實踐感悟的結合。本書通過三部分講解：人員、流程、產品。人員就是定義和開發產品的參與者；流程是開發的步驟和一些相關的經驗；產品主要介紹了一些設計的原則。
簡單吧？本書是產品經理必讀數目，所以採取精讀方式，三個部分分作上、中、下來讀。
豆瓣評分：8. 5
第一章：
產品經理是與市場對接評估產品機會和定義開發產品（功能）的角色，借助產品需求文件清晰的描述產品的功能和屬性。
第二章：
產品從細節上定義開發什麼產品，brp文件越細越好。
兩個人分擔產品工作沒有明確負責人的話會有只見樹木不見森林的弊端，僅停留在「產」的階段，站的起點比較低，不能讓人發揮特長，一刀切限制創新思維。
產品經理若定義了沒有價值不具備可用性和可行性的產品，累死三軍，所以產品經理要有敏銳的市場嗅覺，切不可用蘿蔔釣魚，找準源頭是核心，所謂戰術上的勤奮掩蓋不了戰略上的愚蠢。
第三章：產品管理與專案管理
產品經理負責產品，定義有價值、具備可用性和可行性的產品，專案經理負責資源、執行計畫和把控進度。
如何成為優秀（高效率、嚴要求、嚴格遵循專案管理）的專案經理：
強有力的專案管理能力是產品經理的一大優勢。
優秀專案經理的七個特點：
工作緊迫感、善於捕捉問題、思路清晰、用資料說話、果斷、判斷力、態度（這明顯更是產品經理要具備的素質啊，自己想不清楚評審現場就好比直播吃翔哇）
第四章：產品管理與產品設計
好的產品必須提供號的使用者體驗。書中給出啦與使用者體驗密切相關的分工：使用者研究－互動設計－視覺設計－原型設計。在mvp階段，市場、使用者研究－原型－互動－視覺更適合當前主流的產品設計節奏。這裡有乙個逆向思維過程，即在戰略上可以如此，即與商業市場需求對接是最高戰略層，視覺最弱；一旦進入使用者體驗階段剛好相反，即面對使用者視覺、互動成為最高戰略層。
第五章：產品管理與開發
都說產品與技術團隊相親相愛，生出產品這個兒子，然後讓運營養活。從產品的角度來看，技術團隊是實現「情懷」的直接資源。產品理應1讓技術了解使用者的痛點，讓其感同身受？2通過技術人員了解最新技術，否則最終是幻想3要讓開發人員持續的跟進。4控制開發節奏5控制版本6時刻準備著迎接需求，拿出解決方案。
這分明就是產品總賤和技術總賤飯桌上的狼狽為奸苟且之事。
關於如何與異地的開發溝通？寫好文件吧，盡一切能力協調，每月過去一趟，配個異地產品團隊。
關於外包：一定找牛逼的程式設計師，別省錢
關於**重構：**重構有風險，產品陷入停滯，請盡量避免。要留出20%的技術餘量，制定可行的計畫和時間表。不可避免時要分塊進行，實現遞增修改，讓使用者感受到在改進，算是暗渡陳倉吧。我們也**重構了...
第六張：招聘產品經理（衡量自身的標桿）
行業經驗重要嗎？通過積極的融入是可以客服的，更重要的是產品80%的技能，產品經理是一種解決問題的思維：打造優秀產品的流程、領導團隊、應對產品擴張的經驗、對個人的認知和自我激勵的能力。
第七章：管理產品經理
說給上司看的。為以後當上司偷學一點：
1組建優秀的產品經理團隊
2規劃公司的全域性是產品戰略。
第八章：巴頓將軍的忠告
永遠不要告訴別人要怎麼做。告訴他們做什麼，他們自然會發揮天賦，給你驚喜－－巴頓將軍。
不要扼殺別人的創作力。
第九章：優秀副經理
觀察和識別優秀的同事，請教和邀請ta們參與產品。
第十章：管理上司的十條經驗
－－－－－－－－－－－－－－－－－－－－－－華麗的分割線－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
第二部分：流程11-30章
第三部分：產品31-39章
第四部分總結
附上本部分目錄：
2016下第2本《啟示錄 流程篇》
第十一章 評估產品機會 本章節的內容是產品設計最核心的源頭部分 確定做不做的問題，即我們的三大文件之首的brd文件，可以從以下點去驗證 通常情況下都是按領導的意願在做，你是執行者，而非決策者，所以。沒有所以，just do it.第十二章 定義正確的產品 採用流水線並行開發產品，定義 封裝 非開發中...
《啟示錄》總結2 人員
1 產品經理的主要職責 評估產品機會 product opportunity 定義要開發的產品。2 互動設計師負責深入理解目標使用者，設計有價值的 可用的功能，以及使用者導航和產品使用流程。與產品經理合作，目標是確保產品具有可用性 使用者明白如何使用 和價值 使用者對產品的渴望程度 3 產品管理與產...
年末裁員事件背後的啟示錄（2）
接前一篇文章。1 從業者都應該想到的事情？a 專案被載 作為乙個專案的策劃者 無論是遊戲，還是嵌入式產品開發，電子商務開發等 都應該有對專案風險進行管理的能力。而專案風險管理的一般流程如下圖所示 軟體風險管理工作就是在風險成為影響軟體專案成功的威脅之前，識別 著手處理並消除風險的源頭。作為策劃者可以...