我們的產品是如何走向成功與失敗的？本文作者從這一問題出發，結合自身項目實踐，對推動產品成功的相關因素展開了分析探究：對問題進行足夠的理解、深入的調研、合適的用户研究。
在開始寫公眾號的前期，有很多小夥伴問關於項目管理的問題，因此寫了篇關於項目的文章。從整體的項目流程到項目研發執行的細節分兩篇來介紹，項目管理及產品研發流程。
01在過去幾年中，包括我在帶創新部的時候，做了大大小小上百款產品。也做了不少成功的產品，為了總結一套成功的經驗進行復刻，我一直在對自己的工作方式、時間分配做大量的反思和總結。
正好前兩天在知識星球更新了「好的產品經理與差的產品經理」的區別，有一條也談及於此。
通常情況下，我們的產品項目預研及產品實現過程的標準流程是這樣。
詳細的產品研發實現標準流程是這樣。
以上流程均較為詳細，為了方便我們今天的討論，將其簡化壓縮為一般流程。
02我們一個產品項目，一般是市場調研，分析需求，羅列問題，明確問題，設計方案，研發，測試，生產，上市。
將一個泛化的問題逐步明確，縮小範圍，然後設計方案解決它。
實際項目過程中，產品經理、研發工程師、測試工程師、市場人員會拆分出各自的任務項。
並且從方案設計到系統性測試，期間我們會遇到很多問題，避免不掉回過頭去修改、重新再來，具體表現是這樣的。
在項目管理的舊文中，整個流程是從項目導入開始的，整個週期約 110 天。
如果包含前期的調研、需求分析、定義問題，這個週期可能還需要更長，根據具體的情況而定，比如公司和我本有有資源的情況下，進度會比較。
越是項目靠前的階段耗費的時間越長，因為問題不明確，我們需要調研、蒐集數據、需求問題驗證。
如果想要快速的切入到項目前期的工作並取得相對的結果，需要產品經理完善相關的公司流程、制度。
比如建立市場信息收集制度和指導文檔，與忠實的消費者建立強力的鏈接等等。
項目前期的內容不是本文的重點，我們後期討論。
所以假設，一個產品項目從前期想法到最終落地時間為 100 份。我通常的時間分配是這樣的。
我所有的成功項目，基本都是這樣，將 30～40% （視項目情況動態調整）的時間精力放在開始方案設計之前。
因為只有對問題進行足夠的理解，深入的調研，合適的用户研究，所設計的解決方案才會滿足用户需求。
03但，即使是這樣，實際的研發過程中仍然會遇到許多相對細小以及未充分預計到的問題，並且我認為在咱們 AI 硬件類產品中會不可避免的發生。
因此，這個流程就會增加一個反覆的過程，類似這樣：
既然解決方案是在對問題足夠多的調研、研究和理解基礎上產生的。那麼，為什麼依然會這樣呢？
我認為有這麼三個主要原因：
1. 需求洞察的難度用户具有異質性、情境性、複雜性等特點，而用户羣又具備羣體性。需求探查的時候，需我們與大量的消費者接觸，進入消費的腦海中，洞察他們的行為以及背後的原理。
用户需求，在舊文“需求系列”中有詳細的闡述。
然而，洞察需求，找到問題的本質，是非常非常困難和複雜的。
我們產品經理通常有這麼兩種情況定義需求：按照自己的理解，按照用户的描述。
我們很多產品經理經常足不出户，全靠在網上搜集信息，拍腦袋，甚至數據分析都很少做，更甚至都沒有建立完善的數據收集制度和工具，來自運營、銷售、市場、商務等部門的數據全部原封不動的躺在各部門睡大覺。
產品經理其實是個非常苦的崗位，不僅要對內，還需要對外。比如我們做無人機的時候，經常跋山涉水跟蹤觀察/訪談用户，以及測試。
田間地頭蹲守看我們農民伯伯怎麼操作無人機，休息頻率，請教農作物蟲害特性等等。
那段時間，如果把我扔在煤堆裏，不拿枴棍捅一下，根本找不到我。
用户往往描述的問題的時候往往是他們想要解決問題的方案，而不是方案背後的問題本質。我們產品經理經常到這裏就止步不前了，以為找到了問題的本質。
洞察需求是非常消耗時間和耐力，非常痛苦的一個過程，我們需要不斷的問“為什麼”“為什麼”“為什麼”。
2. 管理層的任性我們產品經理一定遇到過不少這類情況：Boss 改、增需求。
這個原因有很多，以及我們產品人該怎麼應對，將在下一篇介紹。
多數情況下，我們都在頂着老闆的壓力被動接受這樣一個現實。
3. 研發過程中繼續需求求證以前在羣裏討論應該提過這個話題，我們產品經理並不是在產品立項進入研發階段就放手了，我們會繼續跟蹤用户，做持續的用户探求。並且持續探求用户問題的本質。
除此之外，我們研發過程中，會產生樣機，我們也會拿着樣機找到我們的中式用户進行體驗。
這其中，可能會修正之前的問題定義，也可能會修改現有的解決方案。
以上，是我覺得三種比較常見且重要的影響因素。我自己將這種稱之為「不可避免的研發行為」。
無論是研發過程中、從系統性測試回到方案設計，還是從小批量到研發的反覆。還算可以接受，因為基本上我們的產品項目還算跑在通往成功的路上。
04真正讓我們頭疼，且常常失敗的產品項目是這樣的：
這種從系統性測試或者小批量回到問題定義的研發產品項目流程，極其可怕。往往意味着我們前面所作的一切都是無用功，需要推到一切從頭再來。
這無論是對於產品經理，還是對研發工程師是致命的打擊。
可能有不少產品經理聽到過 RD 這麼抱怨過：“搞了一年，啥結果也沒有”。因為實現產品以及產品在市場上的成功是我們的資本，是職場的籌碼。
而這種情況經常發生在這樣的行為下：
更為極端的情況下，是這樣的：
在我所有的產品經歷中，基本上所有失敗產品都是在這種情況下產生的。
為此，藉助與不少公司老闆、高層聊天的機會，探究了一下他們的工作方式。得出的結論逃不過上面兩種時間分配。
第一種的時間是我做的大致統計，具體每家公司都有差異。
當然，我探訪的老闆們，他們也談市場調研、需求分析、用户研究，培養公司忠實的消費者用户羣。但也基本是停留在做一點兒或基本不做。
其實公司管理層也都意識到方案設計前期需求洞察的重要性，為什麼卻投入很少的精力甚至直接忽略呢？
除前文需求洞察艱難這一小節所講的原因外，還有如下幾個原因：
1. 需求洞察部分工作難以量化，可視性不佳需求洞察部分的工作難以量化，公司管理很難通過相對比較可行性的量化指標（KPI）。比如，敲代碼，ID 設計具有很強的視覺化的反饋，而需求洞察則很難。
而這就導致管理層認為這部分是浪費時間，特別是在「精益創業」「快速迭代」等思潮的影響下更加劇了這種情況的惡化。
需求洞察的結論又往往是比較短小的文字描述，其工作量領導無法直接感知出來，項目評審會上，無具象化的產出很難反映出產品經理的付出。描述性的、抽象性的東西顯得很空洞且簡單。
其實我們產品經理本身又何嘗不是如此呢？
舉個栗子：
為什麼很多產品經理到處找 PRD 文檔模板，其中有一個原因就是是希望豐富自己的輸出，顯得自己專業，工作可量化。
回想一下，每當自己輸出文檔的時候，是不是有一種總感覺缺點兒什麼的感覺。
2. 管理層的固有觀念管理層認為需求洞察其實很簡單，以及對需求獲取的流程產生認知偏差。
以為，出去跑一下供應鏈就可以獲取信息，走訪一下市場等等類似方式即可。
比如，我曾經有個領導，週四下的任務，下週的週三就來問，什麼時候可以出方案？什麼時候立項？
其實這種就是典型的將產品項目工作移到解決方案的實現上，直接跳過了需求洞察、需求評審、可行性分析，風險預案等產品前期工作。
這種行為我認為也是不可避免，一是個人工作經歷和對崗位內容認知的缺乏；二是，老闆也有老闆，他需要拿到具體、可視、可量化的東西向他的老闆回報。
我們產品經理需要對此有充分的認知，並努力做好溝通與數據分析，不是為了證明老闆錯了，而是用你具體的詳細，可量化的目標物與老闆溝通。
最後需求洞察是一項非常艱苦、非常艱難的工作，是一個通常被價值低估的產品工作內容。
我相信好的需求洞察是保證產品項目取得成功的重要因素之一。
並且，我相信花大量時間在產品方案前期的需求工作部門效果顯著並且降低我們無效用的研發投入。
作者：AI 產品觀，前實體行業「需求導向型產品經理」，現「AI 硬件產品經理」（AIPM），公眾號：AI 硬件產品官。
本文由 @AI 產品觀 發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。