當初被推薦這本書的時候，友人說，這是一本值得看許多遍的書，不論你處在產品經理的什么階段，每一次閱讀，都會有不同的收獲。

雖然他的段數也不是很高，但是我信了。

倒不是會認為看完這本書就可以點石成金，但是鑒于自己接觸的產品經理有限，大牛更少，作為一個進階中的產品經理，還是非常迫切的想知道，別人是如何做產品的。

《啟示錄》這本書很完整的闡述了產品經理的職責及其工作，包括一些常見的問題。

如果是小白，這本書可以很好的幫你了解了解產品經理這份工作。

如果你和我一樣，進階中，注意這本書中列舉的問題，這些很現實。

如果你是大牛，嗯，在這里我保持沉默。畢竟我還沒有經歷這個階段。

讀完啟示錄，很多觀點有了更系統的概念。

一、關于產品經理

本書的第一部門專門介紹的產品經理的工作職責及相關人員工作職責。講真，看目錄的時候，這一章我想直接跳過了，畢竟做產品也有兩年了，都和誰打交道還能不清楚么。

但是，萬事都離不開但是。很多事情看似理所當然，卻不一定是對的。

比如，產品和運營，產品經理和項目經理。

產品和運營的立場不一樣，運營雖然會掌握到用戶的需求和抱怨，但是產品要定義有價值、可用、可行的產品，面對各種需求需要明確哪些能做，哪些不能做。

許多（創業）公司招一個產品經理恨不得找個孫悟空，看他七十二變，點滿全部技能點。

許多公司的產品還兼職做著UE。

還有那種連設計都要兼職的產品，一般來說，這種公司可能太窮沒有產品經理，是設計兼職產品。

如果要做產品經理，首先明確，自己要做哪種類型的產品經理，或者公司需要哪種產品經理。

也許這個世界上真的有天才，能做到面面俱到，但是能將一項做好已不簡單。

二、關于業務流程

有過從0到1的產品經驗，再來看書里所說的產品流程，還是很有感觸的。

比如，你有調研過用戶么？你有分析過需求么？你的產品是有價值，可行可用么？你有問過用戶對你的產品是否滿意么？

講真，做一款產品的時候，我完全脫離了用戶。雖然那時只是個助理，但是沒有接觸用戶，注定會走向失敗。
做第二款產品的時候開始，開始接觸用戶，做調研，做訪談。有沒有用呢？可能沒有太多的直接的幫助，但是會給我不同的思考方向。

做產品，萬萬不能脫離用戶。

三、關于產品

現如今互聯網走到今天，打開APP Store 會看到數不清的APP，甚至會有人說，如今能想到的都有人做了，好像已經沒有新的機會了。可是即使微信很火，依然有釘釘出現。只要有人，就會有欲望，只要有欲望，就會有需求。需求不會有窮盡的時候，而是看你如何看待需求。結合新技術，掌握用戶的情感，可以幫助你打造更好的產品。這是《啟示錄》第三部分所揭示的內容。

對于一些問題，啟示錄也給出了一些解決辦法。

1、會議
在第二家公司做產品的時候，每天無止境的開需求會議，產品方向會議，開會開的幾乎要吐掉。這和我此前的觀點是很不相符的。一個會議開一上午并且沒有任何結論，簡直浪費時間啊！
實際上，這確實是浪費時間。但是歸根結底，是會議組織者沒有提前制定好會議內容。也就是產品經理，沒有做好會議準備工作。沒有列出會議要討論的內容，或者列出了單沒有提供具體選擇的方案供，沒有提前和與會人員討論過這些方案。既然不是頭腦風暴，那么讓會議更快更有效的達成一致的結論，也是產品經理職責。

2、程序員重寫代碼
在第二家還公司還遇到一個問題，就是后來功能改動很大，拆東墻補西墻，導致數據庫代碼混亂，程序員同學非常希望能夠重寫代碼。遇到這種問題，說明你的業務走的不是很規律。有時候產品在初期規劃的是一種，實際做起來又是另外一種，為了避免這種情況，那么在推進產品開發時，給研發團隊留一些自主時間，而不是壓的死死的，也許也是大有裨益的。（之所以用也許，因為沒有這樣做過。）

3、探索產品
這是否是一個值得做的產品？只有開發之后才能知道么？
第二家公司不停的在探索各種方向，分析需求，確定方向和功能然后就投入開發。結果上線之后不理想，在換新的方向。
講真，程序員很貴的。同時開發IOS，安卓，還有H5，結果都開發完發現大眾不買單，這合適么？
如此探索產品，成本也太大了！
《啟示錄》里給出一種了探索產品的方法，制作高保真原型。拿著高保真的原型去探索檢驗。

4、砍需求還是拖延項目進度
如果是C的市場，拖延項目進度，可能不會有太大的損失，但是對B來說，面臨的可能會使經濟賠償。許多產品都會面臨這種問題，快要上線時，發現有技術難度，有功能問題，各種等等。你說砍需求？如果不輕不重的砍了可能也就砍了，但是萬一牽連其他，就很頭疼。一般會出現這種問題，多半是前期做需求的時候，沒有把設計和技術拉過來一起討論。這個功能這樣實現是不是會有問題，有怎樣的問題，這都些都與產品可行性有關，是需要研發團隊在著手開發之前就需要先準備的。
有時候即使溝通到位了，還是可能會出現這種情況了，如果砍需求，會影響產品體驗的完整行，那么與其讓用戶使用一款不舒服的產品，不如等兩天，使用一款成熟的產品。

有意思的是，書里反復強調的一個觀點，和現下流量觀點不太相同。那就是：是否有必要畫高保真的原型。

現下流行的觀點是，畫中等保真的原型即可。產品經理太注意細節，會浪費時間，影響對大局的判斷。
書里則是非常提倡高保真的原型。理由是可以用高保真的原型先行探索用戶，測試可用性。
對于高成本的團隊，尤其是硬件團隊而言，高保真原型是必不可少的部分。
那么對待大眾團隊呢？
現實情況可能真的是，你沒有時間制作高保真原型。
要制作高保真原型，首先你要領先研發團隊至少2個版本，然后有交互、設計和測試一起完成所有用例和頁面。然后才能做出高保真的原型，才能用這樣的原型去找關鍵用戶做測試做改進。
然而現實有的時候還是蠻殘酷的。但是牛逼的團隊和牛逼的產品，應該是能做到這個地步的吧？

書里還提到了敏捷開發流程。和傳統的瀑布流不一樣，書中認為這是高效便捷的產品管理辦法，然而并沒有詳細說明，不過可以加入書單里慢慢研讀。

有的書授的是術，開本即用，有的書傳的是道，《啟示錄》講的便是一種道。產品經理之道。如何打造用戶喜愛的產品，沒有同一明確的辦法，但是有規律，在你沒有總結出自己的方法論之前，按照這樣的準則去做，可以幫助更快更好的成長和成功。

以上，是這個階段的我，一些小小的理解。

關于《啟示錄》
“啟示錄”原本是圣經里的一章，所描寫的是耶穌現身，為門徒展示人類未來的故事。譯者將書命名為啟示錄頗有一些指明方向的意思。更為有趣的是，譯者不是一個人，而是集結在網絡上一些素未謀面的人，努力將作者的想法傳達給讀者。