小白產品經理看產品：

什么是互聯網產品

當你開始準備做一個產品經理之后，你就開啟了產品經理之路。但剛開始的產品視角還不是產品經理的視角，只是小白產品經理的視角。為什么是小白呢？因為什么都不懂！一張白紙，沒有框架，也沒有太多整體感覺。

小白產品經理什么都沒有？當然不是，他們有的是想法，有的是問題，有的是“要是我來做就不會這樣”的?？?。

破除小白產品經理的視角是通往一個合格產品經理的必由之路。

第1節　產品經理面試的第一道題：你用哪些產品

很多大學生找到我，希望我給他們推薦一個職位，有些也通過我獲得一些面試機會。這個面試過程就有很多有意思的事情發生。在我的面試里面，有一個問題是必須問的。那就是“你的手機里經常用的產品有哪些？”。

我曾經在一個現場活動里面問過一個剛剛畢業的大學生朋友：

我：你想做什么工作？
她：產品經理。
我：想去什么樣的公司？
她：百度。
我：你手機里經常用的APP是哪些？
她：微信、QQ、淘寶，嗯……
我：思考10秒還有沒有第四個？
她：想不起來了。

全場大笑。

這是一個非常典型的新人，想做產品經理，但不知道產品是做什么的，也從不用第四款產品。那么，我想問的是，你覺得一個讓面試官想要的產品經理是什么樣的呢？

另外一個例子：我在負責百度搜索產品的時候，遇到一個候選人，我面試完成之后，希望他做一個搜索產品的產品分析作業。他回去做了3頁百度搜索的體驗報告。我不禁為他捏把汗。我并沒有讓他做百度搜索的體驗報告，只是讓他做搜索產品的體驗報告。

他做百度的，其實寫到頭也未必能有多出色的地方，而且肯定不如我了解百度搜索產品。他不如寫谷歌的，如果他寫谷歌，我覺得他還有點兒想法。如果他寫Bing的，我覺得他應該是個挺有產品感覺的人，畢竟敢挑戰Bing的產品分析也是難得。如果他寫Yandex的分析，我覺得肯定能進二面。如果他寫一個比較好的Naver的分析報告，那我幾乎就要錄用他了。

可是，在面試百度的人里面，有多少人是用過Yandex和Naver的呢？又有多少人知道這兩個搜索產品呢？

產品經理的早期階段，最難的事情就是培養產品感覺。我們認為培養產品感覺其實很難有捷徑。只有多用產品，多嘗試各種產品，才能在長期的積累中形成一些感覺。就像“1萬小時理論”說的一樣，做一件事，持續做超過1萬小時后，你就是這個領域的專家。像我們讀研究生的時候，長篇累牘地讀論文，老師要求每周至少80頁外文論文，當時覺得很枯燥，但讀完之后發現慢慢地就有對某些知識的感覺了。

多嘗試，多體驗，不要怕，不緊不慢，堅持下去就能培養出產品的感覺。然后用一些系統的方法認識產品。具體的認識方法，我們會在下面提出來。

你認識這些產品嗎？自測一下吧，如果這些產品你都用過，那恭喜你，你已經涉獵頗豐。那接下來你應該知道他們的競品在國內外都有哪些。如果你都還沒用過，那趕緊加油去用一下吧。

廣泛的體驗產品，是從一個小白用戶轉化為職業產品經理的重要一步。如果不能做到這一點，就像設計汽車的不研究各種設計風格、踢球的不研究各種比賽視頻、設計園林的不考察各種園林一樣。

我們曾經做過線下活動，把一些很少見的APP截圖去掉Logo后，一張一張地讓大家去猜這是什么產品。比較厲害的產品經理基本能猜到80%，厲害的小組20個APP都對。這說明他們不僅在用產品，而且能把這些產品記住，把一款產品和競品區分出來。

你能通過圖片看出哪個是百度外賣、哪個是美團外賣嗎？也許你覺得這樣很變態，但我反而覺得這樣很好看！

第2節　什么是好產品，好看還是好用

什么產品是好產品？好看的還是好用的？我想，略微經過思考的同學，都會回答好用的產品是好產品。但是，又有多少人在使用產品的時候，會認為好看的產品比較喜歡呢？

我曾經在很多場合問過大家：請問，在座的各位，有沒有看到過一個產品是丑死的？因為它太難看，活活丑死了？如果有，請告訴我，我可能能救活它。答案是沒有。

我并不否認設計和交互越來越影響產品的認知和感受，第一印象真的很重要。我也特別認可“設計改變生活”這個理念。但是，我們真正在反思一個產品的時候，往往會發現，先要讓它好用，然后再讓它盡可能地好看。

好用是普世訴求，好看是因人而異的。

我們看到的是58同城和愛幫網。這兩個網站，其實做的事情有點兒類似，都是本地生活服務。我們也能很容易地發現，58很丑，而國外有個類似58的網站叫Craglist，更丑。愛幫從UI層面看，還是很好看的。但前者的市值應該是后者的百倍，用戶量也是千倍的差距。

第3節　什么是互聯網產品：黑盒子模型

那么，你認為什么是互聯網產品呢？我曾經面試過上千個產品經理，也被很多人面試過。有很多次的面試，我們都會問：你認為互聯網產品是什么？

這是一個很大的問題，很少有人能回答得特別清楚。大部分人說互聯網產品是解決方案、是一套流程、是服務、是平臺、是一整套代碼……

我一直追求一個互聯網產品的定義，這個定義不僅可以用來定義互聯網產品，還可以邏輯性地用來推演出產品運營、產品設計和商業模式的選擇。如果它真正可以定義產品，那么也應該可以用來推演一些結論。

本書的一大創新點，就在于我們嘗試著建立了一套產品的定義。

我認為，互聯網產品就是黑盒子（Black-Box），我們下面所有的推論都是從這個定義開始的。

互聯網產品是一個黑盒子，通過這個黑盒子，用戶會從哭臉變成笑臉，同時它會從底部掉出一些錢來。

所以互聯網產品是一種能夠帶來用戶微笑價值和可能帶來商業價值的黑盒子。這個黑盒子因為不同的行業和語境，內部結構也不一樣，但最基本的結構是T模型。T的上面橫向是信息架構，縱向是業務流程。

也就是說，互聯網產品是一個通過信息架構和業務流程組成的黑盒子，它首先能夠帶來用戶微笑，然后能夠帶來商業價值。

• 推論一：互聯網產品的第一價值是微笑價值，然后才可能帶來商業價值。
• 推論二：傳統行業的產品，比如房地產，就是反向進行的，用戶從微笑變成哭，然后帶來商業價值。
• 推論三：不管什么行業，黑盒子里面的基本結構都是T模型組成的，而橫向的信息架構一共有3種類型，縱向的業務流程應該也是呈現“泳道狀”的。

以上，我們基本完成了互聯網產品的定義。我們后面還有許多推論，同時，我們也會用這個定義去解釋互聯網產品的運營核心、運營方法和其他內容。

我特別高興，在這本書里能夠第一次把我的這一發現分享給大家。

第4節　像庖丁解牛一樣去觀察產品

那么，我們在定義好什么是互聯網產品后，是不是可以根據它的定義去使用了呢？第一個問題就是，如何觀察產品和認識產品。

觀察產品和認識產品，有兩個階段，第一個階段，遠遠看，看外觀；第二個階段，細細看，像庖丁解牛一樣剖析它的結構。下面我們就一起來看看怎么去觀察、認識產品。

既然互聯網產品是黑盒子，那么我們就套用這個概念來分析。我們把它分為黑箱和白箱兩個方式去認識。

所謂黑箱，套用測試里面的定義，就是不去考察產品內部的線路、流程和設計思路，而是直接按照它的交付預期去測試。比如這個產品就是讓100個人站上去不會垮，它的黑箱測試就是讓100人站上去，看看會不會垮。如果不會，就成功了。至于里面是用鋼筋水泥做的，還是塑膠做的，統統不管。

所謂白箱，就是要看產品里面的設計邏輯、線路結構、流程等細節是否符合設計方案。

那我們認識產品也是一樣，首先可以通過黑箱的方式，去看產品是否帶來微笑價值。這一微笑價值的評估，我們采用了一套畫布的方式來解析。

白箱則是要去分析產品的流程、交互、原型和版本迭代了。

接下來我們詳細說說這兩個方法。

畫布分析法。我們通過回答畫布上的問題來認識這款產品。產品分析流程對應了相關的工作流程。我們認為，把產品當一個黑箱去分析它要解決的問題、提供的解決方案、獨特買點和用戶場景及目標用戶等，可以讓一個產品比較清晰地勾勒出它的框架。

要注意的是，我們一定要真實地回答問題，比如用戶的痛點和問題，我們可能要站在用戶的角度去想，用戶到底有什么問題，而不是這個應用目前解決了什么問題。

說起來有點兒枯燥，我們看看用戶對一些APP的認識吧。

第5節　學會用App Store的版本還原產品

版本還原是一種重要的產品認識方法。我在百度的時候，曾經指導過一些產品經理，通過App Store和豌豆莢市場的版本描述，還原產品版本。最后我們發現，這樣的方法在復盤一個競爭對手的時候是非常有用的。你可以很清晰地看出這款產品的迭代節奏、走的彎路、交的學費，同時你也能看出，哪些功能點的發布帶來了用戶的顯著增長。

我自己也曾經用這個方法還原了微信這款產品，發現了微信很多的“秘密”。

我們以春雨醫生為例?？梢钥吹?，第一個版本（1.0）和第二個版本（1.1）之間經歷了3個子版本，都在修復之前的Bug。第一個版本到最后一個穩定版本之間，經歷了大概８個月的時間，這個時間是什么？測試用戶需求，尋找產品定位！

４個月的時間內，一共發布了8個版本，其中每隔兩周就有一個產品版本發布。從大量產品迭代周期來看，這是一個比較健康的節奏，不是很快，但也不慢。其中有7個版本是新增了一些功能。

在2.7.0版本之后，我們發現春雨醫生的版本節奏變慢了，趨于穩定，更多的時候，可能在做市場運營和資源整合。

我們再更多地看一下春雨醫生在這些版本中都實現了哪些功能。我們希望通過這些功能來還原春雨醫生的產品歷程。雖然我沒有參與他們當時的產品設計和開發經過，但我今天依然可以看得很清楚。尤其可以看出，在V5.0的時候當時上線了幾個核心功能，比如“私人醫生”“預約就診”“線下求助”等，這些看起來非常重要的功能其實不是在產品一開始就上線的。這是為什么呢？

為什么很多產品都找不到節奏，或者浪費了很多走回頭路的時間呢？是否可以通過這樣的版本復原，找出你的競爭對手或者潛在的競爭對手，來看看他們是怎么做的，是不是比和某“產品大?！背灶D飯，找一些八卦來得好呢？

梳理完了版本功能之后，我們再試著歸納一些產品的發布節奏。V1.0-V2.0時隔5個月，V2.0-V3.0時隔10個月，V3.0-V4.0間隔了10個月，V4.0-V5.0間隔了6個月，這樣的節奏看起來是比較長的版本更新節奏。但事實上，我們在當時的場景下理解，第一個版本到第二個版本的過程看起來是有些產品需求和想法要去實現的，這個過程應該是開發摸索過程，其中團隊磨合、開發設計的時間都比較正常。而第三個版本以后，可能進入不斷調整和面向用戶測試不同功能的階段了，所以這個階段小版本多了，發布的功能也多了，在大型框架上暫時沒有太多的時間更新。第四個版本也是一樣，這兩個大版本都堅持了接近1年。

所以，我們可以看出一些常規的規律。

1. 大型版本早期要更加扎實和簡單，這樣可以容納不同的小版本失措和功能迭代，不斷測試用戶需求。
2. 大版本的更新不應該太頻繁。如果太頻繁，則小版本沒法充分釋放，用戶需求也沒法充分測試。而且，如果大版本更迭頻繁，那一定是整體思路沒有想清楚，不斷在底層設計上“調頭”。
3. 小版本要快速發布，不斷測試用戶需求，不應該對小版本功能的定位太過糾結，要知道，小版本的需求可以不斷更迭，最快的一周就可以更新。這個時候，重要的是不斷更新需求、排出優先級，控制節奏。

最后我們做一些總結，看看這些版本的迭代和節奏的控制過程，產生了什么重要的產品功能，哪些產品功能點帶來了市場影響力。
其實，經過兩年多的版本建設，春雨醫生并沒有創造性地“發明”很多功能。大部分做的事情都是“打地基”，少部分功能實現了“微創新”，所以如果你的想法有一堆創新點，那這個開發時間會拉得更長。

要知道，“打地基”的事情就要做好久。我們不是不喜歡創新和發明一些東西，而是產品的每一步，都是在前面的臺階上往前走。很多傳統行業或者不專業的老板不深知這些道理，都是“拍腦袋”出想法，“拍大腿”定方向，“拍桌子”訓產品經理。

不遵循產品規律的項目和負責人，也不會受到太大的挑戰，無非就是多交一些“學費”，多浪費一些時間，比別人先“死去”而已，放心吧，不會出大事的。

選出你喜歡的3款作業，從App Store去還原他們的版本迭代信息。

根據我們的白箱分析方法，用版本還原的方法，去蘋果應用商店，或者豌豆莢應用商店尋找3款產品，做一個分析。在這個過程中肯定會遇到問題，我相信你們一定可以自己解決，而且一定要自己解決。

因為，產品經理生來就是解決問題的！

本文選自《產品的視角：從熱鬧到門道》

未經書面授權，禁止轉載，違者追究法律責任。