需求DNA檢測:如何判斷一個功能是否值得做
面對來自客服、運營、競品、市場、用戶調研等各個渠道的海量需求,哪些應該放到產品會議中PK、哪些應該直接pass,產品經理該如何抉擇?完成“需求采集”后,在召開產品會議進行“需求篩選”前,“需求分析”是這中間很重要的一個步驟。
關于“需求分析”,蘇杰先生在所著的《人人都是產品經理》中提出了一個方法論——需求的DNA檢測,如圖1所示。
圖1 需求的DNA檢測過程
按照蘇杰先生的方法論去操作,當然是再好不過的,不過在一些創業公司中,負責產品的人員數量不多,而產品的迭代速度很快,對于每一個需求都規范地完成“需求轉化-確定基本屬性-分析商業價值-初評實現難度-計算性價比”的一系列流程不太現實。因此,對于一些性價比明顯不高的需求,產品經理在經過定性評估和分析后就可以直接pass。本文以某產品手機端“輕審批”主頁面改版為例,談談這個需求為什么不做。
圖2是某產品目前的手機端“輕審批”的主頁面,某用戶提出將主頁面改為圖3的形式。
圖2 目前的“輕審批”主頁面
圖3 建議改版后的“輕審批”主頁面
為了便于分析問題,首先列出了審批功能的主要使用場景,如表1所示。
表1 審批功能的主要使用場景
基于以上場景,結合蘇杰先生的方法論,從以下4個方面進行了分析和考慮:
1、面向未來規劃產品
目前,該產品的核心模塊——IM模塊和任務模塊尚不夠成熟和穩定,仍有一些bug未修復、一些需求未滿足。因此,現階段某產品應集中主要資源完善核心模塊,審批這類非核心模塊的優先級并不高。并且,審批模塊目前并不存在影響用戶正常使用的問題,本需求并非為了解決影響用戶正常使用審批模塊的問題,因此緊急度不高。
并且,隨著某產品開放平臺的完善和商務合作的開展,未來包括審批在內的非核心應用將會逐步對接第三方。聞道有先后,術業有專攻,該產品在IM方面積累深厚,但在審批方面的積淀也肯定不如擁有多年經驗的專業審批軟件豐富。因此,在對接第三方之后,某產品自帶的審批功能的重要度將會更低。
2、高頻場景優先于低頻場景
根據經驗可知,發起審批功能和處理審批功能的使用頻率明顯高與審批記錄回溯。審批記錄回溯則主要針對兩種場景:一種是審批程序出現問題時需要查詢,這種情況發生的頻次較少,尤其是在審批制度推行一段時間后;另一種是周期性統計需要,一般為每月一次。因此,“發起審批” 、“審批進度查詢”、“處理審批”是高頻的場景,“審批記錄回溯”則是相對低頻的場景,產品設計時應優先滿足高頻場景的需求。
3、優先滿足核心用戶
決策者與使用者分離是企業級市場區別于個人市場的一大特點。對于To B產品而言,企業愿不愿意買單取決于企業決策者(老板)對產品的滿意度,而產品能不能順利地在企業用起來取決于產品直接使用者(廣大員工)對產品的接受度。因此,To B產品最應該關注的是老板,接著是廣大員工。
而審批的回溯工作主要由人事部門、財務部門等職能部門完成,而這類人員既不是企業決策者,不能在IM產品選型中起決策作用;在產品直接使用者中占比也不高,因此他們的需求并不具備代表性。因此,人事部門、財務部門等職能部門員工并不是To B產品關注的核心,“審批記錄回溯”這個場景的重要度并不高。
4、分類導航層級不宜過多
圖3的方式下,用戶要想查看審批項,進入“輕審批”后需要首先選擇一級導航“我發起的”、“我收到的”或“抄送我的”,然后再選擇二級導航“已審批”或“待審批”,才能到達審批項列表,這種方式相當于分類導航層數越多,分類更精確,但用戶使用路徑也會更長,使用成本會增加。 而目前的方式(圖2),用戶進入“輕審批”后直接選擇“已審批”或“待審批”,即可到達審批項列表,導航層級更少、用戶使用路徑更短。
基于以上分析可知,該產品手機端“輕審批”主頁面改版這一需求的重要度和緊急度均很低,而且改版會使導航層級變多、增加用戶的使用成本,因此本需求不做。
作者:劉增明(微信號lzm479364262),浙江大學研究生,研究方向是IE/IT,有志于成為一名互聯網產品經理。博客地址:http://www.cnblogs.com/liuzengming/。
本文由 @劉增明 原創發布于人人都是產品經理。未經許可,禁止轉載。
- 目前還沒評論,等你發揮!