在我寫這篇文章的時候在聽汪峰老師的新單曲「流年啊 你奈我何」,恰巧我又在寫自己做產品的「失敗」經歷,頓時感覺秋風四起,落恭弘=叶 恭弘飄飄,一副冰冷凄慘的畫面浮現在我的腦海中。說心理話,當宣布自己的產品轉維護不再繼續投入開發的時候,我心裏真的很難受,似乎失去了什麼,似乎又得到了什麼,但那一刻我的內心更多的是「不甘心」。

「不甘心」是想再爭取一些資源做更多的嘗試,證明產品走到今天這一步是正確的,所做的一切是對用戶來說有價值的,想給產品保留一絲希望;「不甘心」是作為產品經理的自尊,總覺得做過的事可以做的更好,而且還有很多事自己沒有做;「不甘心」是內心一種無力的吶喊,心有不甘,力未用完,可是,結束了就是結束了。

這段做產品的「失敗」經歷,對我來講是一筆寶貴的財富,今天我做一次復盤,與大家分享。

「低頻」需求確實很難做大

我們以前總會聽到關於「高頻需求」的說法,就是產品上的功能是可以解決用戶「經常」遇到的問題,這個「經常」就是「高頻」,相反「偶爾」就是「低頻」。我之前心裏對這個事有着深刻的認識,但似乎一直停留在認識上,再加上之前都是做的相對「高頻」的需求,所以一直都只是覺得,應該是這樣,直到這次才真正明白。

或許選擇「低頻」需求的開始就是一個錯誤,我在做產品前期規劃的時候,會分析需求的發生場景及發生頻率,說白了就是對用戶來說有多「痛」。如果一開始的漏斗選擇的太小,場景也會越來越少,越收越窄,相反如果選擇了大一些的漏斗,那麼就會好做很多,很多時候,產品經理在規劃時候的判斷,基本就就決定了產品的成敗。

「關鍵路徑」上的門檻要足夠低

我想不少產品經理都是這麼想的,也包括我,但是真正做起來的時候卻總是感覺有點距離或者說太過於理想化了。總想讓用戶多填寫一些信息,多選擇一個條件,多做一點操作,這在產品的關鍵路徑上對於用戶來說就是層層阻礙,是非常致命的。

產品流程要足夠簡單,簡單不意味着簡陋,只是想讓用戶能否更加輕鬆的走到你的產品套路中來。

「場景」要考慮完整

「場景」這個詞兒對產品經理來說非常重要,我自己也非常認可這一點。只是需要在考慮「場景」的時候要更加細緻,通過流程圖將這些場景串起來,這是我試過最好用的方法,不管是主流程還是分支流程,都要想清楚,然後串起來就可以將其場景化了。

「迭代節奏」很重要

我當時兩個節奏都沒有踩好,狀態非常彆扭,所以如何在資源有限的前提下,產品經理可以控制好「迭代節奏」就顯得很重要了,雖然當時自己做了很多嘗試,但是覺得還是有不足的地方。

這裏的「迭代節奏」包括:「版本節奏」和「運營節奏」。舉個例子,V1.0版本發布在7月10日,V1.1由於開發資源不足,評估完需求複雜程度后預計在9月10日發布;V1.0的運營由於排期問題,在7月30日開始運營,軟廣才能開始對外投放。

所以產品經理需要對現狀有個「預判」,解決這個問題需要做兩件事,一個是「提前啟動運營策劃」,讓推廣和產品發布的時間點能配合起來;另外一個是「簡化下一個版本的需求」,讓有限的開發資源投在優先級較高的功能上,保證產品能夠繼續小步快跑起來。

先「能用」再「好用」,先「小而精」再「大而全」

產品存在的價值一定是「解決用戶在某個場景下的某個問題」, 所以在產品剛開始的時候需要對很小的一個功能進行「精雕細琢」專心解決好一個問題,而非「平台化思維」,什麼都想做,但似乎什麼都做不好,搭建好骨架后才能做大做強。

當時自己有一種很明顯的感覺,就是應該按照1+1的思路來做,但是卻在按照0.9+0.1的思路做,體驗扣的有點過於細了,應該是提供「有損體驗」,但是功能可用,後續不斷完善。有種什麼都想做的「平台化思維」一直在干擾我。

很多錯誤在親身經歷了之後才會有着深刻的感悟,後知后覺的痛楚似乎不那麼好受,不過我想這也是在產品道路上需要面對的困難,有經歷才會有成長。我將這些內容分享出來,希望可以幫助大家拋磚引玉,希望我們可以共同進步。

啊,多麼痛的領悟…

 

來源:微信公眾號: PMColour