面對來自客服、運營、競品、市場、用戶調研等各個渠道的海量需求，哪些應該放到產品會議中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/。

本文由 @劉增明 原創發布于人人都是產品經理。未經許可，禁止轉載。