每個人都知道產品有一大堆功能其實不是什么好事，也有幾百篇文章在討論產品管理，告訴我們?yōu)槭裁幢苊夤δ苡纺[如此重要。

你的公司也可能像我的公司（HubSpot）一樣，有著一支優(yōu)秀的產品團隊，由一群智商過人、目標明確的同事組成，他們關心用戶體驗，對產品管理中的取舍問題有自己的見解。

那么，為什么還有這么多的產品會出現(xiàn)功能臃腫的情況？我們又該如何降低自己陷入這種情況之中的可能性？

我們可以分析一下關于臃腫功能的五個“為什么”，看看它到底是如何將我們帶入死胡同的。

1. 我們?yōu)槭裁磿杏纺[功能？

因為我們一直在添加新功能，卻很少刪除舊功能。隨著時間的增長，產品累積了越來越多的功能。這是個很簡單的數(shù)學問題：我們只做加法，不做減法。

2. 為什么我們一直在添加新功能，卻很少刪除舊功能？

因為添加新功能比較容易。作為產品部門，我們的任務是創(chuàng)造一個優(yōu)秀的產品，吸引一批愉快的用戶。給產品添加新功能是改善產品的一個普遍辦法。我們之中大多數(shù)人都有一個單子，上面寫滿了來自用戶、潛在用戶、銷售團隊、營銷團隊、客戶團隊還有創(chuàng)始人的各種改進建議。

大部分時間里，我們都在思考單子上的哪一個功能能夠帶來更多的影響和資源，接著就把它添加進去。產品部門總是在受到各種批評，批評我們采用了這個創(chuàng)意卻沒有采用那個。我們的使命似乎就是不斷完善產品、添加功能，好讓我們滿足用戶的期待。

但似乎沒有哪個產品團隊會因為添加了太多新功能而受到批評。因此，我們不斷地、勻速地添加新功能。但更有趣的問題是，我們?yōu)槭裁床粍h除功能呢？

因為刪除功能比添加功能要難太多了。

3. 為什么刪除功能這么困難？

因為我們很難判斷哪個功能該被刪除。通常沒有人會要求我們把功能刪除，但總是有人在推薦某些特定的功能。他們表達支持、不斷游說，還往辦公室送來蛋糕和餅干。

但我敢打賭，沒有人會送你點心來勸你刪除一個功能。如果你正打算刪除一個大限將至的功能，你更可能會像是一個為榮譽奮戰(zhàn)的孤膽英雄。和其它那些孤膽英雄一樣，英勇的戰(zhàn)斗并不會給你帶來名聲、榮譽和餅干。事實上，你還可能不得不和公司內部的成員（比如銷售團隊）決斗，出于對不良影響的考慮，他們是斷然不會讓你輕輕松松刪除功能的。

4. 為什么判斷哪個功能該被刪除這么困難？

因為你很難判斷刪除這個功能是否值得。

有些用戶可能還在用著這個功能，有些可能還特別喜歡這個功能，有些甚至是沖著這個功能才買了這個產品。如果你要刪除這個功能，有些人可能會揚言不再購買你的產品。

這就是產品管理如此困難的原因。你得試著在不同的時期中平衡不同群體的不同需求。有些決定從長期來看是完全合理的，但從短期來看就很難解釋。

5. 為什么你很難判斷刪除這個功能是否值得？

因為刪除一個功能帶來的好處需要過段時間才會顯現(xiàn)，但這個行為帶來的痛苦則是立等可取的。

況且，這個功能也不能說是“不好”。畢竟這個功能背后的理念是從一長串備選中脫穎而出的。既然添加了這個功能，就有添加它的理由，它也確實能給一些人帶來好處。

為了能被實施，理念們必須經歷殘酷的競爭來爭奪資源，可謂是千軍萬馬過獨木橋。

同時，我們也會認為添加這個功能所用的資源已經是沉沒成本了。我們也認為沉沒成本既然已經“沉沒”，就應該把它清除出我們的腦子。

那么，既然我們已經得出了這樣一套理論，我們要如何解決臃腫功能的問題？

以下是我的一些看法：

作為產品部門，我們手中的數(shù)據是不完整的。我們努力工作，為的是所謂的“驚嘆率”（利用最少的資源獲得了最多用戶影響的工作比率）。我們憑借著當下手頭的數(shù)據和資源做出選擇。但我們的選擇不一定總是正確的，也不應該苛求它永遠正確。

因此，我們首先該做的，是接受這個事實：我們都會犯錯，我們添加的某些功能到最后其實是臃腫無用的。

另外，既然我們無法預知哪個功能會淪為臃腫功能，我們要如何在之后的實施中發(fā)現(xiàn)這個事實呢？

答案當然是利用數(shù)據！在這個時代，我們擁有無數(shù)的數(shù)據來分析用戶行為，我們應該跟蹤產品中的各個功能（特別是新功能），并且分析它們的實際使用率。

舉個例子。我們都知道“設置”的作用。當我們無法決定一個功能應該這樣操作還是那樣實施時，我們放棄無謂的爭吵，把決定權交到用戶手里，這就是“設置”的作用。

且不評論設置的這種“妥協(xié)”性質。就假設我們已經為產品添加了一個新的設置值來供用戶選擇。這個設置值通常有一個“默認”屬性，還有一些其它不同于默認的可調整項目。

你應該判斷的標準就在于：在一個統(tǒng)一的前提下（新設定已經添加），有多少用戶會將它從默認值調整為其它數(shù)值？撐死了也只有10%。當然并不會真的有10%，但我們姑且就算它是10%。這意味著，為了方便一個想要改變設定的用戶，我們讓其它9個用戶的生活都復雜了一些。更別說在你的團隊里，還有一大批人需要記錄、支持、修正這一設定。

從長期來看，這個行為是否值得？有可能值，更可能不值。

但是我們就這樣把它放著，想著“這是沉沒成本啦，別管它了……”

這其實是一個巨大的謬論。一個功能的大多數(shù)成本并非在于其開發(fā)早期，而是在于發(fā)布后那段長長的時光里。

我認為，你應該做的有這些：

確定一個“使用率／價值最小值”作為門檻，所有功能都必須超過這個門檻才能留下來，那些在一定時期內沒能達到要求的新功能？刪掉。

只要刪除合理，就要支持這個舉動。要清楚雖然刪除功能會帶來短期的疼痛，但從長遠來看是完全值得的。

創(chuàng)造一個文化，鼓勵“英雄”們像添加功能時一樣奮斗于刪除功能的戰(zhàn)役之中。