編輯導讀：一個存在影響用戶，並且有條件解決的問題，產品經理就一定需要對此進行功能迭代嗎？這或許是許多產品一直以來的想法，但你可能忽略了背後的平均成本，本文作者對此展開詳細說明，與大家分享。
如果功能所解決的問題，不存在被影響的用戶，那麼這個問題就不需要解決，功能也就不應該做。
如果問題存在被影響的用戶，但是功能不具備解決問題所需要的條件，那麼，這是一個產品暫時無法解決的問題，功能也就不應該做。
問題分析與條件分析可以過濾掉大部分不應該做的功能，但對於產品從業者而言，這樣還不夠。
在剩下的看似正確的功能當中，那些存在被影響用戶的，並且具備解決條件的功能當中，仍然存在一種影響很嚴重的錯誤功能。
已經有非常多的產品，尤其是創業階段的產品，因為這些錯誤功能，失去了寶貴的機會。
所以，作為產品行業的從業人員，我們還需要使用第三種功能分析法，將這類型錯誤的功能辨別出來，這樣可以有更高的功能正確率。
麥子生鮮是一款基於LBS的生鮮電商產品，平臺為用戶提供了50種生鮮商品，用戶可以通過麥子生鮮APP購買水果，蔬菜，肉類等滿足日常飲食需求的商品。
平臺為用戶提供了「兩小時速達」與「定時送」兩項特殊的服務，配送人員將會在用戶在下單後的兩小時內，將商品送到用戶的手裡，用戶也可以選擇一個指定的配送時間點，配送人員將會在指定時間點，送貨上門。
這兩項特殊的功能，準確命中了用戶的痛點，產品一上線，用戶數量以較快的速度增長，半年後，已經有100萬註冊用戶，日活用戶達到了10萬，其中有4萬用戶會產生下單行為。
為了更好地推動產品更新迭代，公司特別重視用戶的反饋，每個月都會組織用戶調研，詢問用戶在產品使用過程中存在哪些問題。
這個舉動確實為產品團隊帶來了寶貴的真實使用者的建議，產品也在修復打磨中越來越受用戶喜愛，訂單量每個月都會有所突破。
在最近一次的調研中，有很多用戶共同提出了一個問題：希望產品能在搜索時，兼容錯別字。
在搜索某些商品時，常常會輸入一些錯別字，像菠菜（bocai）和博彩(bochai)，杏子（xingzi）和信子(xinzi)。
用戶反饋，家裡的長輩本身文化程度較低，在下單時，輸入錯別字就會找不到商品，沒幾次就不想用了，還是老樣子上街買菜。
產品團隊通過數據分析的方式，對錯別字問題進行了為期一個月的觀察分析。
這一個月裡，一共有20萬用戶使用過產品，有5萬用戶產生了搜索行為，在用戶的搜索記錄當中，有2萬名用戶產生過錯別字搜索的行為，一共有4萬次錯別字搜索的記錄。
為了評估功能的開發成本，產品團隊也和研發團隊進行了可行性探討，確定「搜索兼容錯別字」是可以實現的，但需要10萬的研發成本（工時折算），此時，公司的現金流還剩100萬。
這是一個存在被影響用戶，並且有條件解決的問題。
如果解決了錯別字兼容問題，可以減少部分中老年用戶的流失，並且提升每天的訂單量。
新功能上線以後，每天的訂單量確實增加了，從40000筆，增加到41000筆。
後續迭代中，又做了幾個類似「搜索兼容錯別字」的功能，每天的訂單量越來越多了。
然而，當訂單量突破到每日5000單以後，麥子生鮮資金斷鏈了，一方面是融資不順利，一方面公司原有的100萬現金流，在功能迭代過程中耗盡了。
儘管擁有上百萬用戶，儘管日活用戶達到了20萬，儘管每天都有5000筆訂單，公司仍然走向了倒閉，團隊解散了，產品也停止了面向用戶的服務。
不存在影響用戶的問題，不需要解決，沒有條件解決的問題，解決不了，儘管這兩類問題會給產品帶來很大的負面影響，但卻是很好判斷，也很好規避的問題。
另一種問題，隱藏在正確問題當中，既存在被影響的用戶，也具備解決問題的條件，就像是隱藏起來的使用慢性毒藥的殺手，不容易被發現，即使中毒了，也不會被察覺，等到毒性發作時，產品也就生死一線了。
這種隱藏起來的問題，才是產品經理所遭遇的高危險問題，常常在不知不覺中讓產品死亡，表面上來看，每一個功能都帶來了數據的增長，實際上，卻是在不斷地接近死亡。
並且，負責該產品的產品經理即使在產品死亡後，也不會察覺到自己犯下的錯誤。
這個問題就是使用了錯誤的刻度單位。
麥子生鮮也是因為使用了錯誤的刻度單位，走向了死亡。
假如有兩把尺子A和B，A的長度是100米，最小刻度是1米，B的長度是1米，最小刻度是1釐米。
我們將兩把尺子並排擺放，起始位置相同，並且在起始位置處，放上一隻蝸牛，就像下圖一樣。
當蝸牛發生位移時，以A尺子為參照的情況下，我們很難感知到蝸牛發生了位移，也無法判斷出蝸牛位移的距離，當尺子的刻度單位繼續增加時，這種感知將會接近於無。
刻度單位過大時，移動的物體會呈現出相對靜止的狀態。
而B尺子，刻度單位較小，能夠清晰感知到蝸牛的位移，以及蝸牛位移的距離，當尺子的刻度單位繼續縮小時，這種感知將會極為明顯。
刻度單位極小時，任何細微的變化，都會如同行駛中的列車一樣明顯。
尺子，就是我們用來衡量功能成本的工具，刻度單位較大時，就無法對功能做出正確的判斷，有太多信息，相對大刻度而言呈現出靜止，無法被感知的狀態。
一些很嚴重的問題，隱藏在大刻度背後，難以被察覺。
麥子生鮮用來評估「搜索兼容錯別字」功能時，所使用的10萬開發成本，就是大刻度單位，適合用來與現金存量進行對比，但作為功能分析而言，就不太適用了。
從業人員需要換一種衡量功能成本的刻度單位。
一種更小，更精細的刻度單位：平均成本。
我們嘗試換一把「尺子」，用一把刻度單位極小的尺子，不去衡量開發成本，而是衡量功能的平均使用成本。
這需要增加一個輔助條件，我們假設有效計算周期為功能上線後的一個月使用時間。
在上線該功能之前，麥子生鮮的產品團隊對用戶一個月內的使用行為進行了觀察分析，得到了一些數據情報，計算平均成本時，需要使用到這些數據。
為了方便閱讀，將這些數據從案例中進行了提取：
「觀察的一個月時間裡，一共有20萬用戶使用過產品，有5萬用戶產生了搜索行為，在用戶的搜索記錄當中，有2萬名用戶產生過錯別字搜索的行為，一共有4萬次錯別字搜索的記錄。」
現在，以一個月為計算周期，嘗試計算一下，「搜索兼容錯別字」功能的平均成本。
以用戶為計算單位，計算每位用戶的平均成本，10萬的研發費用，為2萬名產生錯別字搜索行為的用戶提供服務，為4萬次錯別字搜索行為提供服務，似乎是一個可以接受的成本。
但，當我們嘗試計算功能的平均成本時，隱藏的問題就暴露出來了。
10萬的費用，為2萬名用戶提供服務，人均成本5元；相當於每一位產生錯別字搜索行為的用戶，公司都需要為其支付5元成本；
10萬的費用，為4萬次行為提供服務，次均成本2.5元，相當於每次用戶產生錯別字搜索行為，公司都需要為此支付2.5元成本。
這樣的平均成本，就難以接受了。
網際網路產品通常為大規模的用戶提供服務，因此，功能的人均成本，以及基於使用次數的次均成本都是一個極低的值。
2020年，騰訊雲提供的雲簡訊10萬條套餐包售價是3400元，平均0.034元/條。
同年，擁有4億日活用戶的抖音，公開的廣告收費標準，CPC的計費標準是0.2元一次，CPM的計費標準是4元千次，相當於0.004元一次。
術語註解：
CPC：廣告的計費方式之一，按照用戶的點擊行為計費，用戶每點擊一次廣告，廣告主需要向平臺支付廣告費用，若是用戶沒有點擊，則無需支付費用。
CPM：廣告的計費方式之一，按照曝光數計費，通常以千次曝光進行計費，不考慮用戶是否點擊，只要廣告被呈現出來，廣告主就需要向平臺支付廣告費用。
我們在衡量功能的平均成本時，會以一個極低的值做為標準進行判斷，且用戶規模越大，標準值越低，計算周期越長，標準值越低。
通常情況，按用戶人數計算，人均成本極少超過1元每人，按照使用次數計算，次均成本極少超過0.01元。
當我們嘗試用平均成本的方式對功能進行分析時，原本能夠接受的成本，也變得難以接受。
現在，如果你是麥子生鮮的產品經理，面對人均成本5元，次均成本2.5元的「搜索兼容錯別字」功能。
你認為，應該做嗎？
功能的平均使用成品疊加起來就是產品的平均使用成本，一些產品在上線初期堆砌了許多功能，但用戶規模，使用規模都不足，導致這些功能都平均使用成本極高，缺少注資的情況下，產品死亡率就極高。
那些什麼都做，什麼都是核心的產品，已經被時間淘汰掉了，並且留下了一個名詞：大而全。
相對應的，活下來的，成功的產品，現在依然存續，也留下了另一個名詞：小而精。
所以，草根創業產品初期只做兩件事，其一是為大面積用戶提供的核心功能，如同微信的通訊，淘寶的購物，其二則是吸引新用戶的功能，能夠拉新的功能。
新用戶的加入，可以降低產品被使用的平均成本，功能的增加則會增加產品被使用的平均成本，兩者構成了一個奇妙的關係，用降低的平均成本減去增加的平均成本可以得到一個淨值。
淨值為正，表示降低的值減去增加的值若是大於0，意味著產品的平均使用成本在降低，產品就進入到一個良好的發展軌跡，兩者的差值，可以將產品的平均使用成本向0推進，淨值越大，產品的發展速度越快。
淨值為負，表示降低的值減去增加的值若是小於0，意味著產品的平均使用成本在增加，產品就進入到一個負重成長的發展軌跡，兩者的差值，會持續將產品的平均使用成本推高，淨值越低，產品的負重越大，越快耗盡公司所持有的可使用資金。
淨值可以有效評估產品迭代過程中的健康度變化，對於產品的發展方向也能起到極好的支撐作用，是一種很有效的，也是產品經理所能掌握的產品評估方法。
但這是一個比較後期的產品評估分析方法，未來有機會，再為大家展開講述，現在，我們還是回到功能的平均成本當中。
評估功能的平均使用成本包含了六個步驟：
成本刻度就是指平均成本的單位，可以是每人，可以是每百人，也可以是每千人，每萬人。產品規模不同，適合使用的成本刻度也需要進行調整。
刻度過小時，得到的數值會過小，且無限接近於0，不容易觀察和分析。
刻度過大時，得到的數值會過大，影響評估的精細度，不容易發現問題。
標準值是一個我們所期望的值，反映出了我們希望為用戶的某個行為支付多少成本，這是一個很少會思考的問題，但卻是一個有效的問題。
標準值是動態調整的，當我們發現功能的測算成本始終低於標準值或者始終高於標準值，並且偏差幅度較大時，就意味著標準值的設置可能是錯誤的，需要進行調整。
理論情況下，功能被實現以後，可以永久性為用戶提供服務，但實際情況卻存在許多變動，像是產品停止運營，功能變動，乃至一些外部因素都會影響功能的服務周期。
因此，我們希望在一個可控的時間段內對功能進行評估，這樣的評估才是有效，且有用的。
計算周期需要根據功能的特性定製設計，一些功能見效較快，覆蓋的用戶群體較為集中，就會設計一個比較短的計算周期，一些功能見效慢，是長期投入，需要培養用戶習慣，就會設計一個比較長的計算周期。
通常情況，短的計算周期會被設計為1個月，或者2個月，長的計算周期則是6個月，或者12個月，極少有超過12個月的計算周期。
平均成本是一種評估方法，使用到的數據也是以推測數據為主，在評估人均使用成本時，就需要從業者推測出會使用該項功能的用戶數量。
推測方法有兩種：存量推測與增量推測
存量推測是基於現有用戶進行推測，在現有用戶當中，有多少用戶存在該功能的使用傾向，被功能所對應的問題困擾，並以此為基礎增加一個浮動範圍。
增量推測是以一個月為單位，觀察過去多個月的用戶新增趨勢以及新增規模，推測功能上線後的一個月或者多個月裡，每個月會有少用戶新增，並以此為基礎增加浮動範圍。
在選擇推測方法時，主要是判斷功能所面向的對象，判斷該功能是為老用戶服務，又或者是為新用戶服務。
在評估功能的次均使用成本時，需要推測用戶對功能的使用頻率。
功能是問題的解決方案，問題的出現次數就等同於功能的潛在使用次數，所以，常常用替代的方式，將對功能的測算轉變為對問題的測算。
需要以月或者周為單位，分析某些相關問題出現的次數，並且觀察問題擴散的速度以及擴散的趨勢。
問題的次數，對應的就是功能的潛在使用次數，問題擴散的速度及趨勢對應的就是功能潛在使用次數的增長趨勢。
最後一步，就是將推測出的平均成本與標準成本進行對比了，低於標準成本，功能的正確性會更高，且，差值越大，正確性越高，極有可能是一個很出色的功能。
如果推測平均成本高於標準成本，功能的錯誤性就越大，且，差值越大，錯誤性越大，極有可能會成為產品的一個負擔，耗損公司的現金，需要我們慎重對待。
在實際工作中，標準值有可能是一個錯誤的值，需要我們在數次迭代驗證的過程中，對標準值進行調整。
當然，比對結果，以及完整的測算過程，均是功能分析的過程，所使用到的，以及所得到的，均是分析材料，並不能直接等同於決策。
對功能的分析，是為了讓從業者更好的做決策，而不是替代決策。
一些平均成本極高的功能，在其他條件的支撐下，也可能是必須要做的功能，而一些平均成本極低的功能，在其他條件的支撐下，也可能表示一定不能做的功能。
嘗試將本節講述的方法，運用在實際的產品當中吧。
這是一款創業階段的電商產品，為喜歡戶外旅遊的用戶提供專業的戶外商品，包括帳篷，登山杖，登山鞋等。
已知該團隊可使用的資金還剩100萬，且產品早期實現了多元化的優惠券功能，可以向用戶發放單品優惠券，滿減券，無門檻優惠券等多種形式的優惠券。
目前，產品的部分數據如下：
累計用戶10萬，日活1萬，月活躍用戶4萬人，其中包含每天新增加的用戶100人，每月新增加的用戶累計3000人。
創始人有兩個基於優惠券的想法，準備從中選擇一個，投入開發資源將其實現出來，為此，向你提出了諮詢，希望你能給到一個合理的建議，而你是這款產品的負責人。
這是一款創業階段的產品，且用戶規模較小， 我們可以為每一位用戶支付更多的成本，也是為了更好地幫助你掌握這種分析方法，所以，我們補充一些假設信息：
成本刻度設置為每人，標準成本設置為2元，有效計算周期設置為一個月。
現在，嘗試用平均成本的分析方法，對兩個功能進行分析，並給出你的分析意見，你認為，哪個功能應該做，哪個功能不應該做。
想法A：新人優惠券
為產品的新用戶提供新人優惠券，這樣可以促進新用戶的首次下單行為，也能帶動訂單的增長，但客單價較低，且老用戶無法參與。
該功能的開發成本需要投入20000研發經費，並且會一直持續下去。
想法B：滿減券
設計一場基於滿減券的活動，向所有用戶派發滿減券，活動有效期內，滿減券都可以使用，這樣可以促進用戶下單，並且提升客單價。
該功能開發成本需要投入40000研發經費，活動持續時間為一個月。
結合這款產品的基礎信息以及補充的假設信息，用平均成本的分析方法，對這兩個功能進行分析吧。
做產品與做「好」產品
隱藏任務：預判功能的正確性
功能所解決的問題，真的有那麼嚴重嗎？
我們的功能，一定能解決問題嗎？
枯葉，微信公眾號：枯葉咖啡館。人人都是產品經理專欄作家。9年經驗產品經理，3年產品總監經驗。擅長數據增長，商業模式。曾孵化過千萬級用戶規模的創業產品
本文原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於CCO協議。