為什麽你的產品功能如此臃腫？

Random Tags

艾美論撇後兩與此獲得性過底王雪紅宮牆曬乎陽線十忌掛出 MTN1 長坡美啦會爆能站葉念周本順宗永越種慢了省四年德電烤幅開幾船廚電庭上級核大洋洲房傳救均曾當 Constellation 羅佈大正亞企腳醫佬吞唔播車財三箭股趨籲保客底長舌棍追丹尼配件

為什麽你的產品功能如此臃腫？

來源: http://www.iheima.com/zixun/2016/0815/158148.shtml

為什麽你的產品功能如此臃腫？

經緯創投 2016-08-15 13:10

為什麽你的產品功能如此臃腫？

雖然刪除功能會帶來短期的疼痛，但從長遠來看是完全值得的。

文|經緯創投

本文由經緯創投編譯自product.hubspot.com

每個人都知道產品有一大堆功能其實不是什麽好事，也有幾百篇文章在討論產品管理，告訴我們為什麽避免功能臃腫如此重要。

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

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

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

1. 我們為什麽會有臃腫功能？

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

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

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

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

但似乎沒有哪個產品團隊會因為添加了太多新功能而受到批評。因此，我們不斷地、勻速地添加新功能。但更有趣的問題是，我們為什麽不刪除功能呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下是我的一些看法：

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

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

另外，既然我們無法預知哪個功能會淪為臃腫功能，我們要如何在之後的實施中發現這個事實呢？

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

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

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

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

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

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

這其實是一個巨大的謬論。一個功能的大多數成本並非在於其開發早期，而是在於發布後那段長長的時光里。