起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識優秀的產品經理，會把時間花在“界定問題”上
在動手去做之前，先搞清楚要解決的是什么問題，如此，才能幫助你避免做出「漂亮的廢品」。
今年春季，Intercom（一體化客戶溝通系統） 剛剛完成了 1.25 億的 D 輪融資（谷歌風投也全面加入），在?5 年內實現了年經常性營收（ARR）5000 萬美元。
可以說，在 這7 年的時間里，Intercom 一直在不斷取得進展，而這其中有一個非常關鍵的原因：Intercom團隊會深刻理解每個項目要解決的問題。
你可能會覺得這句話是廢話，因為每個產品經理都是這樣想的啊。
但是，很多產品經理也只是這樣想，到具體執行的時候，他們已經離這個關鍵點越來越遠了。
接下來我要分享的就是 Intercom 的產品副總監 Paul 的經驗總結，希望能給大家一些啟發。
一、大多數產品的開發過程
下圖展示的是一個非常標準的產品開發流程：
這個過程產品經理們應該非常熟悉，就是“瀑布”開發的常用流程。當然，如果你的產品團隊比這種瀑布式開發更“敏捷”一些的話，過程可能是這樣的：
（備注：圖中的循環也可能是“設計-開發-測試”的循環）
接下來，讓我們一起來思考一個問題：
假設在項目里一共有100個單位的可用時間。團隊里所有人（產品，運營，設計師，分析師，工程師…）都投入工作，你會如何安排？
在工作中，大多數的產品開發團隊初期是這樣規劃的：花一點點時間決定問題的優先級，界定問題（痛點），然后用更多的時間去設計解決方案，接下來，把大部分時間放在「把東西做出來」上。
但實際操作的時候，這種規劃常常變成這樣：
發現沒有，時間基本都放到開發上了，根本沒時間排優先級，明確問題，和初期的想法背道而馳。
二、為什么會這樣？
當一個資歷很高的重要人物（比如老板，大家都懂的～）突然想到一個新點子，并且想盡快實現時，團隊的工作方式就會走偏——研究用戶真正痛點、明確問題這一步被無限擠壓。
這個重要人物的想法可能是拍腦袋“拍”出來的：坐車的時候，洗澡的時候……一旦這個想法在他心中成型了，他會覺得一刻都不能浪費，得馬上去設計，馬上把東西做出來！
最糟糕的情況是，一旦你的產品路線圖充斥著這些“拍腦袋”的想法，產品就會變的東打一槍西打一耙，功能毫無內在聯系。
曾經，Paul 在做谷歌做某個項目的時候常遇到這種“拍腦袋”的想法，而且他發現大多數被這類想法綁架的項目都是失敗的。當然，這并不是對谷歌的全盤否定。
很多初創公司會失敗也是因為這些“拍腦袋”的想法。這類團隊的很多員工表示這就是他們的工作方式。他們會把用戶研究，用戶訪談這些掛在嘴上，實際工作時并不會執行。
Paul 在 Facebook 工作時，他看到的很多項目是這樣的：
這比在 Google 時好一些，不過從圖中你可以看出來，“開發”依然占著絕對的比重。
但是，在 Intercom，他們絕對不會這么做。
三、Intercom 的做法
在開始設計、開發之前，他們就花費了大概 40％的時間。可以說，他們「沉迷」于確定問題優先級和明確要解決的問題。Paul 會不停地「拷問」大家的靈魂：你真的，深刻的，理解了眼前這個問題嗎？同時，在 Intercom，他們也非常鼓勵產品經理去公開分享、討論要定義的問題。
為什么要這樣做呢？
因為「先理解好問題、痛點，才能有好的解決方案」。
然而，大多數軟件開發團隊都會直接跳過問題定義的部分。
在實際操作中，Intercom 建立了幾個團隊來確保做好前期定義問題的階段。
- 客戶支持團隊（他們會標記與客戶的每次對話，以便 PM 進行審核）；
- 銷售團隊和營銷團隊（根據反饋建立產品/市場矩陣）；
- 研究團隊（Intercom 從一開始就投入巨資在這個團隊上）；
- 分析團隊（Intercom?現在非常重視，也在加大投入）。
在測試階段，他們會意識到「原來還沒有將這個問題 / 痛點 研究透徹」，所以又會重新對問題進行界定。
說到這里，你會發現一個問題，如果大家都認同「先有理解好問題、痛點，才能有好的解決方案」這句話，為什么許多公司和團隊還是會跳過界定問題這個部分呢？Paul 認為有三個重要原因：
1.首先，理解問題本身就是一件非常難的事情。它需要你和一定數量的用戶瘋狂交談，一遍又一遍，進行“巧妙”的信息挖掘；它需要你走出自己的腦袋，進入用戶的腦袋，盡可能地“感同身受”。深入了解他們的實際需求（真正的痛點）。人們經常以他們想要的解決方案形式描述他們所遇到的問題。平庸的產品團隊會停在這里，不再深挖，就去做了。然而，用戶的真正痛點還在他們的思想中埋藏了幾層。好的產品團隊則會繼續前進，不斷問為什么。
2. 在這個過程中你要做的工作聽起來不潮也不酷。一份用戶研究報告，一個新的 UI 模型，一個新的原型，你覺得哪個「酷」？很多位高權重者都喜歡看到「又新又能用」的東西，他們沒時間讀那些報告。在現代的互聯網環境下，深度閱讀和反思來獲得深刻的知識并不令人興奮，也不那么重要。
3. 前期任務（排優先級，界定問題）的工作量在產品上很難得到體現。比如你花了很長時間去研究、界定問題，希望能把產品做好，但上級領導卻覺得你花了這么長時間才做出這么點東西。他們并不重視你花了多少精力研究，他們只注重最終的產量。
所以說，前期的問題界定是一項艱苦的工作，它被貼上了「無聊又不酷」的標簽，從產出量來看又很難證明這部分工作的價值。
然而，對Paul 而言，這是他們做的最重要的事情之一，也是他們項目成功的最重要的因素之一。在動手去做之前，先搞清楚要解決的是什么問題，如此，才能幫助你避免做出「漂亮的廢品」。
最后，希望大家都試著去改變對時間的分配，把更多的時間放到“界定問題”上。把問題界定清楚以后，你會發現，接下來的設計、開發都會變得很順利，最終用戶也會喜歡你的產品，因為你懂得他們的需求。
本文由 @即能 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
問題是往往產品只能按照領導的意見去做，否則拜拜
感覺截圖很清晰明了，想問下是哪里來的呀，有相關的課程嗎
國內多數公司用的是不斷試錯，快速迭代的模式吧
是的，但這里存在的問題是，在快速的迭代中，很多團隊在時間分配上會出現問題，就是大部分時間都在哐啷哐啷干活，卻沒分配時間去想清楚優先做什么。
挺好的
我印象最深刻的就是這個圖 ?? 咋看都一樣，原來左側還有個數值。扯皮，需求無法落地是根本源頭。尤其是上層意圖無法領會時
哈哈哈～需求無法落地的原因多種多樣，還是得做做“根本原因”的分析吧。