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