做産品有很多指導方法論，從很多角度解讀了如何做一個更好的産品。但是，理論和實踐總是隔着一定的距離，将理論落地需要有一套詳盡的方法論。筆者針對這個問題構建了一套評估指标，幫助大家更好落地。

對于我們做産品的人來說，最痛苦的點，可能就是産品做出來之後，被客戶噴“使用繁瑣，體驗太差”，被老闆DISS“你的産品切不到痛點”。

誠然，一個産品好不好，不能憑産品經理的個人喜好，也不能由于極個别的用戶反饋，而對産品當前的狀況進行全盤否定。

我們從産品入行的時候，就被行内大咖教育，做産品要做“剛需、高頻、痛點”。但是卻從沒有人去告訴我們，如何通過觀測數據去驗證我們做的東西是否是滿足這三個核心要點。

本文旨在幫助産品經理們建立較為完善的數據指标評估體系，更好地幫助産品功能的優化和叠代。

首先，請容許我按照自己的理解，重新對“剛需、高頻、痛點”做些定義：

• 剛需是相對于“彈性需求”而言的，從字面意思就可以理解為是硬性，人們需要的東西或者必須要做的事；
• 高頻是指需求欲望在一定周期内産生的頻次；
• 痛點則是指用戶在滿足自己需求的過程中，遇到的最大障礙。

那麼評估指标怎麼定？

主要就是下面這一句話：剛需看滲透、高頻看人次、痛點看能耗。

一、剛需看滲透

滲透率原本是市場營銷中的一個概念，指企業的實際銷售量在市場潛量中的百分率。但是，我們可以将使用範圍進行衍生，大到行業覆蓋度，小到産品中的某個功能特性。

比如，互聯網滲透率是指使用互聯網的網民與總人口數之比，用于表達互聯網滲透到普通民衆生活的程度。

而對于某個APP産品來說，我們提出一個新的概念叫做“功能滲透率”，是指當前使用該功能的人數占整體使用産品的人數比例。這個指标可以較為客觀地反應出當前功能對于使用産品的人群的覆蓋度，功能滲透率越高，則說明該功能是當前用戶使用産品的核心功能，即當前産品形态下的大部分用戶剛需。

以一款教育APP為例，這個産品中主要包括看資訊、聽課程、做題庫等産品特性，相關的産品功能滲透率如下：

從數據中我們就不難發現：10個人來使用該産品，7個人看資訊，2個人聽課程，1個人做題庫——看資訊這個功能點能覆蓋到大部分的用戶。

而對于一款教育産品來講，其最終目标是幫助用戶拿證過題考試的，所以這個數據結果乍一看是反常識的。我們大部分人會認為結構化的課程才應該是用戶最需要的内容及功能，有些颠覆我們的認知。

然而，是什麼原因導緻的，我們就需要進一步做些反思了。有可能是功能剛上線，知悉的用戶數量不多；也有可能是上線運營乏力，還有可能是内容不夠給力；又或者是産品交互體驗不行，技術老是出BUG等，這些都需要進行具體的下鑽分析。

同時我們還需要注意以下幾點：

• 滲透率的數據，可以幫助你驗證需求解決方案是否被大多數用戶所認可，而不能判定滲透高的就是剛需，滲透低的就是普通需求。剛需與否還是需要通過産品經理對業務的洞察去判斷，滲透率更多的是作為“後驗性”指标而存在。
• 剛需是根據用戶完成的業務目标所達成的任務而定的，離終點越近的越是剛需，我們可以根據用戶的需求層次畫一個同心圓，從裡到外由強變弱。

還是以教育類APP為例，可以得到以下的圖解：

總之。如果數據展示出來，發現理想和現實中有落差，那我們就要不斷找原因，不斷調優，持續逼近理想的最優解。

二、高頻看人次

人次是指用戶在一定時間、一定範圍内重複出現的行為次數。

普通人可能一輩子就買一次房，十年去換一部車，他們在人生的尺度上其實是個低頻的。但是，在你要買車的前三個月的時候，你選車的需求被激發，每天看各類購車資訊的行為又變成了短時間的高頻需求了。

所以，它是一個相對的概念，我們不能脫離場景去說這個。

我們來看一個支付寶的經典案例：

• 2003年的時候，支付寶僅僅隻是淘寶的一個子功能，作為網上交易的信用擔保工具；
• 2004年末，支付寶開始逐步從淘寶體系中分拆，成為了一個的獨立的第三方網絡支付平台；
• 2008年，支付寶發布移動電子商務戰略，從PC端業務開始往移動端遷移，推出手機支付業務；同年公共事業繳費正式上線，支持水、電、煤、通訊等繳費。

時至今日，支付寶已經不斷擴寬它的使用場景，支付寶及其本地錢包合作夥伴已經服務超12億的全球用戶，俨然成為我們手機裡面的超級工具APP。就算我們不是每天都去淘寶網購物，生活中的線下支付每天也必然會使用1次或多次支付寶，可能是點外賣，可能是便利店的結算，又或者是公交車刷碼。

支付寶的發展史就是低頻工具型APP最好的逆襲，不斷滲透到各個可以使用支付的場景中。網上購物也許是個低頻的場景，但是線上線下的各類交易中的支付就是一個高頻的場景；每天，全世界各地都在發生着各種交易，小到在學校門口買2元錢的汽水，大到購買萬元的筆記本電腦。

這些一旦全部聚集在一個平台上進行操作，那将是一個非常海量的數字。

那麼關于人次的指标一般都有哪些呢？

以剛才的那款教育APP為例：

需要注意的是，不同功能在相同的時間區間裡面，它們的頻次是不一樣。同樣一個功能在不同的時間區間裡面，按天看、按周看、按月度看，頻次也都是不一樣的。

這款APP主要提供看資訊、聽課程、做題庫等産品特性，相關數據如下：

所以，我們從上面數據中會發現，資訊是個高頻的功能點，而課程和題庫是低頻的。同時，還會發現一個有意思的趨勢：一般而言，越是高頻的功能點，随着時間跨度變大，它的人均頻次的增幅越快；越是低頻的功能點，它的人均頻次的增幅越慢，當然也有一些特例。

所以，如果希望提高課程和題庫的人次的話，可以考慮把冗長的課程，拆分成一個個小的知識點-短視頻進行播放，把動則百八十道題目的題庫，拆解成每日一題的低門檻任務。

總之，如果你的産品切中剛需但低頻的話，可以考慮以下2種方案去提高使用人次：

1. 集低頻場景為高頻場景；
2. 低頻場景前置或拆分轉為高頻場景。

三、痛點看能耗（步數和時長）

開篇已經提到，痛點是指“需求被滿足過程中，行為路徑上的最大阻礙”。而在這條達成任務目标的道路上，我們一般都會付出3樣東西“體力”，“腦力”，“心力”，這三者的付出加在一起就是我們完成任務的一個整體能耗了。

• 體力指用戶完成目标付出的實際行動，諸如在APP中完成注冊操作，要輸入手機号、驗證碼等，做飯時要先洗菜，切菜，炒菜等過程，，這些每一步的完成，最後才指向用戶最終完成任務的通路。
• 腦力指用戶對達成目标的思考，思考是要花費能量的，思考的時間越長，花費的能量就越多。所以，我們可以通過檢測用戶完成任務時在一些頁面的停留時長來判斷，我們的産品是否給用戶造成了困擾。
• 心力指用戶調動和控制情緒所耗費的能力，正向的情緒基本不耗費能量，使人感到輕松；而負面的情緒，則使人感到不适，諸如郁悶、疑惑、焦慮、憤怒等情緒。

所以，無論是體力、腦力、心力，歸于本質來說，都是在消耗我們自身的能量。人的一切動作其實都符合最小作用力原則，也即“能不動手就不動手，能不用腦就不用腦，做人最重要的就是開心囖”，這個是人性所緻。

所以，如何解決痛點，其實就是讓用戶消耗較少的自身能量。

下面再來說說如何用數據去評估三力的消耗，依然以APP為例：

1. 體力的消耗

我們一般可以記錄用戶在APP中完成任務的交互步數，跳轉的頁面個數等。

如果想做到更加精細化，甚至可以統計用戶點擊任務中每個按鈕之間的鍵程長度以及點擊的次數等，這個取決于公司用研的投入産出比。

舉一個大部分APP的通用案例-登錄注冊：

用戶進入APP之後，跳轉到引導頁，然後注冊頁面，輸入手機号，獲取驗證碼等等。其中，用戶還會碰到各種問題，比如手機号輸錯，驗證碼獲取延遲，驗證碼輸入錯誤，密碼設置不符合平台規則，手機号被注冊過等，無形中會增加用戶完成任務的步數，體驗下滑。

操作步數一般受産品設計以及業務本身屬性影響，所以在交互路徑優化時，需要在用戶走彎路時及時給予提示，或者将問題直接化解。比如在注冊某些APP時，直接獲取手機的本地手機号，這樣就避免了手機号輸入錯誤的尴尬。

一般來講，用戶不會全部按照我們的理想化行為路徑去進行操作，中途會遇到很多用戶的跳失。

所以，大部分情況會是像下面這樣：

任務達成的用戶的平均交互深度>平台設計的最短交互路徑深度>流失用戶的平均交互深度

這基本是一個恒定的不等式，我們隻能努力通過産品的優化，讓兩端的“>”都無限趨近于“=”，才能達到較好的用戶體驗。

2. 腦力的消耗

通常可以通過完成任務的時長來進行判斷,更準确的說是用戶的業務處理時長，這個要把用戶完成操作之後系統的響應時長給排除。

業務處理時長因人而異、因事而異，有些人業務熟練，就能很快達成；有些事較為複雜，就需要花費更多的時間。這更多被主觀因素影響。

所以，我們大部分時候看人均時長，看新老用戶的人均時長，然後再看時長的整體人群分布比，來評估任務整體完成耗時水平的差異，從而做進一步的優化。

比如進入一些APP産品之後，新手會看到一層半透明的蒙闆層，去引導你怎麼去玩轉裡面的功能，這個就是在幫助用戶快速上手，不會滿屏幕找入口。

不要讓用戶想，不要讓用戶想，不要讓用戶想。

重要的事情說三遍，讓他跟着你設計的洋流漂洋就好。

3. 心力的消耗

目前我們很難有直接的定量指标，大部分隻能通過用戶對每個功能點的定性反饋來評判；我也很期待未來手機APP可以記錄用戶的表情變化，對臉部表情進行識别和打分。實時同步情緒變化，來判斷用戶是否遇到了困難或者不開心，進而可以進行定向優化。

當然，未來技術成熟，可能法律法規依舊是不容許的。所以，大部分時候，這類檢查隻能做一對一的焦點小組訪談了，很難進行大數據的采集分析。

但是，我們依然可以通過一些常識性的體驗，找到評判的方法。比如我們使用APP時閃退，打開一個頁面時等了10多秒，購買産品付款時提示我餘額不足等，這些都會給我們在完成任務時帶來糟糕的體驗。

我們可以把這幾個大緻分為3類：

1. 錯誤類：包括網絡報錯，加載失敗，APP端閃退崩潰等；我們可以把的各類錯誤的影響人數，以及影響次數作為核心指标進行衡量，比如報錯的接口名稱、操作系統、網絡狀态等都是常見的下鑽維度。
2. 時效類：比如加載時長，審核時長，後端的接口返回時長等；我們可以把一些關鍵頁面的平均加載時長，重要接口（被頻繁調用）的返回平均時長作為核心指标進行衡量。
3. 業務類：比如驗證碼輸入有誤、手機号被注冊、優惠券不能使用等；我們可以把用戶在完成任務時，統計返回的各類業務提示進行分析，來看看通常用戶在走到那一步給卡殼了。

總結

産品能不能做起來，取決的因素有很多，戰略方向、競争格局、服務質量、産品體驗、運營活動等都會影響産品的成敗。

希望本文能夠幫助各位産品經理建立自己的數據體系，帶上度量标尺，更好前行。

最後，如果看完後啥也不記得，請記住這張表，期待大家能做出讓用戶、公司、自己滿意的三赢産品。

#專欄作家#

囧囧有神（個人jspvision，囧神産品觀），人人都是産品經理【2018年度最受歡迎】專欄作家，起點學院導師，成均館大學企業講師，混沌大學創新翰林。10年互聯網經驗，産品運營專家，Team Leader。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部