《人人都是產品經理》讀後感悟
花了一整天時間，終於把蘇傑的《人人都是產品經理》看完了。說真的，真正為互聯網產品經理寫的書很少，寫得好的更不多，但這一本算是十分不錯的。正如書上說的，很適合1-3歲的產品經理看。
本書從需求的收集開始，到項目的管理，文檔的寫作，團隊管理，到自我修養，把產品經理的神秘世界逐層解開。它不是枯燥的理論堆砌，而是頗具指導意義佳作。本書結構清晰明了，語言通俗易懂，彷佛是一個導師以自己的親身經歷在你面前生動有趣地給你簡述什麼是產品經理，產品經理是做什麼的，應該怎麼做。他時而嚴肅，時而風趣幽默，時而輕鬆俏皮，讓你樂在其中卻受益匪淺。
本書列舉了大量的例子來說明論點，而這些例子都是十分契合，恰到好處，而且就發生在我們身邊，讀起來很好理解，甚至感覺十分有趣。感謝作者蘇傑，把我們帶離迷途。
以下為本人在閱讀本書時收集的一些重點的，或帶給我靈感的讓我觸動頗深的段落，供大家瀏覽，想進一步了解本書的精華，請看原著《人人都是產品經理》。
【關於產品經理的意識】
是誰？每次K歌都對着點歌面板評頭論足。
是誰？逛超市時總在想“這個商品能解決什麼需求？”
是誰？會給自己的個人發展做戰略規劃。
是誰？一定要在自己的婚禮中講一個PPT。
是誰？會拿用戶調研的方法與親朋好友交流。
是誰？裝修房子的時候搶着當項目經理。
是誰？看電視廣告總想在幾十秒中提煉出三大賣點。
是誰？會給自己的孩子設計各種“功能點”。
是誰？訪問任何網站都能一下子挑出好幾個Bug。
……
這個人就是產品經理。我做了3年，體會到這種做事方法與思路真的很好用，已經忍不住用它來解決任何問題，並且想告訴每一個人，嘗試着用產品經理的視角看世界吧，你可以看得更清楚，走得更順利。
SNS里的搶車位遊戲，曾經很流行，也許你考慮的問題是：應該怎樣玩才能賺更多的錢？怎樣最快地買到想要的車？怎麼玩最爽？……而產品經理的視角則是：為什麼每個人是4 個車位？如果車位多了會怎麼樣？不同檔次的車為什麼停車費是一樣的？如果高檔車停車費高了，會有什麼優缺點？原來，這些都是和商業目標有關的，車位多了，停車費高了，對好友數量的需求就會降低，這意味着用戶互動的減少，與商業目標矛盾；而反過來，如果簡單粗暴地試圖增加互動，用戶又會不高興，也不行。
【關於用戶訪談】
在用戶訪談的時候，我們可能會遇到用戶“說”和“做”不一致的問題。用戶經常會騙我們，先看一個經典的索尼遊戲機的故事。
索尼找了一些用戶來，問他們喜歡黃色的還是黑色的遊戲機，結果發現說喜歡黃色的用戶比較多。之後，索尼告知用戶為了感謝他們的配合，將送他們一台遊戲機，顏色可以任意挑選，而同樣一批用戶選擇黑色的遊戲機帶回家的更多。很明顯，有部分用戶說喜歡黃色卻帶走了黑色的遊戲機。
用戶倒不是想故意欺騙我們，而可能是：他們被問了自己也沒仔細想過的問題，又不想回答不知道，就在現場編造了一個看似有理有據的理由，或者他們有討好訪談者的心理，會回答他們覺得你希望聽到的答案，而不是自己真正的想法。
對我們來說，防止被騙的方法恐怕像索尼一樣，盡量在用戶可以和產品發生交互的場合下進行，讓用戶在“說”的同時也“做”。
【關於傳統行業產品經理與互聯網產品經理的區別】
互聯網上的產品經理跟傳統意義上的產品經理不一樣。傳統意義上的產品經理側重的是對已有產品的管理和營銷。而互聯網上的產品經理側重的則是產品的規劃、需要分析、用戶研究、功能設計和項目管理。
【關於改版】
2007年底豆瓣為了慶祝註冊用戶過100萬的改版、2009年百度貼吧的改版，都因為用戶的反對聲音太大不得已道歉、改回去，我們真的很幸運。
對於改版，對於升級，我們要把“暴力革命”變成溫柔和諧的“和平演變”。在改版的時候，我們可以先從部分次級頁面改起，或新舊版本並存一段時間，或者做小面積試驗。
【關於處理用戶的需求】
聽用戶的但不要照着做。
在開始需求分析之前，我們先回到2007年7月——我寫了一篇里程碑意義的博文，
是《產品設計體會》的第一篇，也可以看作是為這本書寫的第一筆。2007年6月28日，網店版2.0上線，這是我主導的第一個付費產品，之後的三周我基本天天都會在淘寶論壇上泡不少時間，最大的體會就是：要聽用戶的意見，但不要照着做。
有的用戶很“危險”，在提意見的同時還說你們應該做成什麼樣子，這時候產品經理一定要頭腦清醒了，用戶提的解決方案往往是站在自己的立場上的考慮的。比如對快遞單打印”的功能，用戶提出要添加一個他經常用的小快遞公司的快遞單模板，而我們會發現，這家快遞公司可能只是一個區域性的快遞，最終的解決方案是做了一個“自定義快遞單”的功能。
有時候，用戶給出的做法存在明顯的邏輯矛盾，就算他給出的解決方案合理，也要再深挖用戶內心根本的需求，比如用戶描述“新建非支付寶交易訂單的時候必須要選擇用戶不合理，希望能自己填寫客戶”。這裡更深層的需求就可能是他需要把線下客戶也管理起來，所以我們或許更應該做一個新增線下客戶的功能，而不是在新建非支付寶交易的時候讓用戶自己填寫客戶姓名。
我們是產品經理、產品設計師，最終怎麼做應該由我們決定。
【關於需求分析】
用戶跟福特要一匹更快的馬，福特卻給了用戶一輛車。
對同一個問題，這兩套解決方案的區別就是，一個是用戶需求，一個是產品需求。而這中間的轉化過程，就是這節的主題——需求分析。
小明又出現了，這次他說要吃豬骨頭火鍋（用戶需求），80塊吧，但沒想到又碰到了大毛。
“真的想吃？”
“想吃！”
“為什麼？”
“我餓了……”（找到了本質！）
“哦，這裡是兩個饅頭（產品需求），請你吃，才1塊 錢 。”
“……”
小明無比不爽，但沒辦法，真的餓，還是吃了。
大毛是這樣分析的，想吃豬骨頭火鍋，這個用戶需求無非兩個原因——餓了或者饞了。如果他真的是饞了，那就吃吧，不過如果是餓了，那我完全可以用一個低成本的解決方案——饅頭。雖然小明眉頭緊鎖，但現在經濟不景氣，畢竟節省了98.75%的成本啊！