產品經理:三步到位,落地需求
這篇文章將筆者自身,和其它優秀的產品經理的經驗進行總結,在系統梳理的基礎上,將產品經理從接到需求到進行落地的全過程較為精簡的整理出來。
當老板提出增加開屏廣告,用戶卻很煩時,你要如何去做?當運營提出多點推送,用戶卻嫌騷擾時,你要如何取舍?當競品的迭代優化,成功搶走了一些用戶,你要如何應對?以上是我們很可能遇到的需求場景之一。
需求是產品的工作核心,一個優秀的產品經理是如何將這些需求進行落地的呢?
簡單來說,從產品經理接到(或者挖掘)一個需求,到需求落地,一般分三步:
- 接到需求后,對需求進行分析;
- 分析完成后,對需求進行取舍和優先級排序;
- 產品設計,也就是最終的需求落地。
第一步:接到需求后,分析需求
當接到一個需求時,我們首先搞明白這個需求的來源:是誰提出來的,它提出的背景是什么?核心點在哪里?
搞懂這塊后,我們就明白了這個需求是個什么樣的需求,誰來使用這個需求,它真正要解決的是什么問題。
以微信聊天語音舉例:我相信會有人抱怨微信語音沒有進度條,語音必須要從頭到尾聽一遍,而像聊天寶(原子彈短信)就提供了這個功能。
微信語音沒有進度條
這是比較典型的案例,用戶會根據自身認識直接提出想要的功能,但是我們需要進一步去挖掘用戶的本質需求,而這一般是通過目標用戶使用產品時的場景入手。
在實際的使用過程中,最主要會遇到兩種情況需要進度條:
- 語音被中斷播放后,重新再聽,想要進度條調整到當時播放的進度;
- 重復播放一段語音,但是并非聽取全段語音,而是聽自己只想聽的那部分。
那么,用戶的本質需求是什么呢?
在這些場景中,用戶選擇聽取這段語音,又想要進度條,是不想浪費時間去重新聽已經聽過的或者不需要的那部分語音。所以,本質問題是獲取它所需要的語音的效率問題。
現實的場景往往比較復雜,一個優秀的產品經理能夠提煉出核心的問題,不被表象所迷惑。對于核心問題的提煉至關重要,它是你判斷取舍和優先級的重要依據,也是你整個產品設計方案的基礎。
以用戶的角度進行場景化是準確把握需求的前提,所以切忌觀光式的體驗功能和場景,這樣是難以準確把握這個需求的。
第二步:分析完需求后,對需求進行取舍和優先級排序
1. 需求的取舍
當你真正摸清了這個需求要解決的問題后,我們需要進一步確定這個需求是否要做。
很多人會有一個誤區,那就是:將“需求”是否要做,變成“功能”是否要做。
還是以上文中的微信沒有語音進度條舉例,語音進度條是需求的其中一種解決方案,但是很多人直接想到的是語音進度條是否要做。造成的結果是:通過判斷語音進度條的好壞來決定這個需求是否要做,而不是通過需求本身。
從需求的本質出發,我們才能判斷這個需求是否要做。
其實絕大部分的需求都是要做的,只是優先級的問題而已,因為它們的底層邏輯都是一樣的——人們的訴求都是“更好”。之所以還需要對它們進行取舍,主要是因為在當前的客觀、主觀等環境下,無法提出比較好的解決方案,這也是我們會把一個常識性解決方案的好壞當成這個需求好壞的原因。
比如:文章開頭提到的開屏廣告,就會導致很多產品經理覺得,公司的盈利和用戶體驗是彼此矛盾的,要盈利必然要犧牲掉用戶體驗。
APP開屏廣告的核心需求是公司的盈利,我們能不能想到另一種方式是不犧牲用戶體驗的呢?
作為中國互聯網最成功的產品,微信就從來沒有使用開屏廣告,就算是迫于商業化的壓力,它的廣告也主要出現在朋友圈的信息流中。
且選擇的廣告和廣告策略也考慮到了用戶體驗,讓你甚至還想點贊這條廣告,極大程度的降低了廣告對于用戶體驗的傷害。而且,微信通過其它方式也能夠獲取利益,像游戲收入的提成、微信支付的手續費、給騰訊其它產品引流等,不一定要犧牲用戶的體驗。
從左至右:微博開屏、微信開屏
2. 優先級排序(需求管理)
一旦確定了要做一個需求,就要對需求的優先級進行判斷。
需求的優先級也就是需求的重要性,它非常考驗產品經理對于公司業務發展和行業市場的了解,以及對于產品的敏銳感等。
因為市場是不斷變化的,業務也不是一成不變的,需求的重要性也會跟著變化,產品經理需要在能夠調用的資源和有限的時間內做出盡量合理的判斷。需求的重要性是一個產品經理相對主觀、且綜合考量的判斷。
這里可以通過以下幾個方面來考慮(現實考慮中可能不只下面幾種):
1)市場
當市場發生了變化,需求的重要性也會發生變化,最常見的就是基于競爭的需求。
像過去10年的移動互聯網,一個行業火起來,必然有很多人一窩蜂的去做,為了搶占用戶,在激烈的競爭中活下來,當一家公司開始補貼用戶,其它的也不得不跟著補貼用戶。
2)業務
業務需求往往大于非業務需求,尤其是核心業務的需求。
3)產品階段
在產品的不同階段,同樣性質的需求,重要程度可能是不一樣的。比如:產品初期,往往以打磨核心功能為基礎,不斷調整以適應市場,贏取用戶;而產品成熟期,更多考慮的是如何為公司帶來更多利益。
4)其它
需求影響的范圍,使用的頻率,是痛點還是癢點等也會成為需求優先級的判斷條件。
像上文中微信語音沒有進度條的問題,雖然絕大部分的微信用戶可能都會遇到這個場景,但是頻率是否高呢?
更重要的是痛點不足,明顯是癢點,因為微信語音不超過60秒,一般很短,不怎么需要進度條來調整。另外,從需求本質出發,微信的另一個功能——語音轉文字,在一定程度上能夠更好的解決效率問題——看文字比聽語音更快,當然,語音轉文字當前要完全解決這個問題還并不完美。
3. 總結
需求的取舍和優先級的界定是沒有絕對的,它們之間的界限模糊且相互轉化。當前判斷不做的需求,哪天可能就會加入版本優化中。
微信之父張小龍說過,他們做產品的時候,實際上是沒有規劃的,可能臨時想到了一個好的點子,就加了進去。面對復雜多變的市場環境,產品經理需要根據實際情況去靈活的管理需求,小步快跑、敢于試錯、快速迭代。
在對需求進行分析、取舍和優先級排序時,產品經理腦子里面一定要有2個圖:一個是業務圖(業務圖是將整個業務囊括在里面,包括產品的和非產品的),一個是產品全局流程圖。
業務簡單的產品(眾多C端產品),可能只需要畫出產品全局圖就夠了,但是業務復雜的產品,最好是兩個圖都畫出來。
通過這兩個圖,可以幫助我們從整體去看待問題:從業務全局的角度進行考慮,可以知道哪些是我們系統要做的,哪些是系統不必要做或者說做不好的,系統和功能對于業務的影響如何;從產品全局角度考慮,可以知道需求處于哪個位置、涉及哪個流程、具體內容如何、會關聯到什么。在面臨具體需求的時候,如果有必要,還需要站在需求涉及的操作人員視角再畫一個基于操作人員的流程圖。
第三步:產品設計
經過了前面兩個步驟后,就是需要將產品方案設計出來,實現需求的最終落地。
產品方案要針對實質問題,深入使用人群的使用場景來設計,才能達到相應的產品(功能)目標。需要特別強調的是:將方案設計代入用戶實際的使用場景是非常重要的,它保證了我們的這個方案不僅僅是有用的,而且是好用的。
舉個例子:
幾乎全部的共享單車APP的主頁面都是差不多的,地圖顯示用戶當前的位置+附近共享單車的位置+掃碼用車主功能。因為當用戶要用車時,需要完成兩個動作,找到空車和掃碼用車,所以主功能是掃碼用車,而顯示附近共享單車的位置則是幫助用戶盡快找到共享單車。
我們基于這個場景再深入一點:當共享單車比較少且距離用戶比較遠,用戶需要搶占用車機會,產品是否要滿足呢?
比如說APP提供預先鎖定功能;當用戶附近沒有共享單車,產品是否提供其它更好的解決方案,比如說推薦其它出行方式;當用戶開鎖后又很快關鎖,系統是否能夠敏銳的感知到用戶最有可能遇到的問題,比如說遇到了壞車……
從左至右分別為:摩拜單車、小黃車、小鳴單車
需求往往是與場景分不開的,場景化也是很多產品經理挖掘用戶需求的一個很重要的方法。
另外,一份優秀的產品方案的設計盡量先從全局去考慮。
比如:共享單車的壞車問題,顯然是一個系統工程,從回收處理機制去考慮,大概流程為“發現壞車-回收壞車-處理壞車?!?/p>
單獨將這個流程中的一個環節拿出來都會涉及到很多功能,比如:發現壞車這個環節,就有用戶反饋和系統自查兩種,而用戶反饋和系統自查又可以貫穿在用戶整個用車過程中。
除了回收處理機制,更重要的是建立壞車的數據系統,幫助分析壞車原因、易壞零部件、壞車集中區域等,幫助不斷改進。還要考慮壞車對于用戶用車的影響,將它納入優化服務的一環等等……
很多功能的簡單優化,可能不會涉及到全局,但是當涉及到新的功能尤其是業務時,從全局的角度考慮才能提出更合理的產品方案,并根據實際情況,去分階段實現目標。
第四步:檢驗產品方案的效果
產品新版本上線后,做好相應的反饋,可以知道我們新方案的效果如何,是否達到預期,需要繼續優化的地方在哪里,此處就不過多展開了。
作者:狼和哈士奇,公眾號:頂尖產品思維
本文由 @狼和哈士奇 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
- 目前還沒評論,等你發揮!