有評論人員認為HubSpot已經有一定功能蔓延（feature creep，指在發展過程中產品或設計的需求增加大大超過他們原來預期的趨勢，導致其功能不是原本計劃的）的趨勢。

但是，其產品的魯棒性很強，它承諾為你的營銷和銷售需求提供一站式服務。

產品的復雜并不是它的缺點，也不是它在隨大流。

恰恰相反，HubSpot的產品向客戶傳遞的就是當初承諾的價值。

在產品管理領域， “功能蔓延”已經成為一個大家最討厭的詞匯。

不少公司給產品添加了越來越多的功能，最后它們不禁思考，自己是否也成了“功能蔓延”的受害者。

有時候，產品的復雜化完全沒有必要。

但如果你懷疑自己的公司已經深陷“功能蔓延”的泥潭，那么你要明白：功能蔓延并不是根本問題，它只是一種表象。

一大堆功能并沒有提升你的產品價值，那你一定要在功能蔓延的概念之外去思考。

功能蔓延的神秘性掩蓋了真實的問題：你的產品并沒有傳達核心價值。

透過表象看問題一種簡單的產品并不能一直傳遞你的價值。

從另一方面看，修復一項復雜的產品，并不是要你簡單地去掉大量的功能。

你要看清楚哪些功能在推動著公司，然后把那些沒用的刪掉。

為什么公司最初打造的產品都會有一些多余的功能呢？隨著產品團隊和其他團隊以及股東慢慢地打交道，產品管理的難度也會漸漸上升。

這個過程中還會關系到你的客戶，這意味著你必須經常思考應該如何向客戶傳遞價值。

如果你認為公司正在經歷“功能蔓延”，那么一些根本問題已經開始對你產生影響了：一支團隊無法向目標市場傳遞核心價值，或者客戶需求的價值并沒能被滿足。

那么他們就不能明白客戶真正需要什么，只會開發一大堆沒用的功能。

當然有些團隊的產品開發是由多個人完成的。

每個人都會給出自己的建議，但開發團隊和用戶的真實需求并沒有合拍。

那么他們開發出的功能其實也不能很好的實現用戶的目的。

我們來仔細觀察一下那些會引起功能蔓延的問題——以及一些解決方案。

我們會探索應該如何向不同的客戶群傳遞產品的核心價值，以及你應該如何根據客戶激勵來組織團隊。

在表達產品愿景時，應該考慮不同的客戶群體如果公司設計了一堆不必要的功能，那么可能你不了解你的市場需求。

產品愿景應該能幫助你的客戶實現自己的目標。

但問題是，隨著你的發展，公司客戶越來越多——創企、中小型企業、大企業——每一類客戶都有不同的需求。

你應該針對不同類的客戶建立不同的團隊。

為每類客戶設計一些通用的、但不關系產品愿景的實用功能也很簡單。

例如添加一些簡單的ad hoc（點對點）功能能豐富你的產品。

但是，如果你想要戰略性地針對不同類客戶，讓他們都能從產品的核心價值中受益，那你一定要刻意地讓產品的功能符合他們的需求。

如果許多類客戶都對你的核心價值有需求，那么謹慎的擴張能幫助你實現發展。

對許多公司而言，不為新客戶提供支持，那么就百害而無一利。

通過比較Trello和JIRA，我們就能更好地理解。

JIRA最初只是一款簡單的針對開發者的漏洞追蹤工具。

在過去的15年里，JIRA已經發展成了一個一體化的產品管理套件。

這家公司打造了一系列功能，為不同類的客戶帶來價值，但這些最終都關系著產品的愿景——團隊協作的記錄和管理。

JIRA開發出的產品關系緊密，針對不同的團隊都有特定的計劃。

例如，它的功能包括：分發特定任務，記錄每個人的工作，這對于小團隊而言非常有用。

災難恢復功能和全新的安全授權，對于大企業的團隊來說，這很關鍵。

另外還能制定工作流程，這對任何規模的團隊都很有價值。

而Trello的發展就恰恰相反。

Trello最初也是一些輕量化的功能。

但它并沒能針對不同的使用案例進行開發，也沒有為不同的客戶開發出一個統一的產品。

它的發展速度遠沒有預期的那沒快，最終被收購。

和簡單的Trello相比，復雜的JIRA更像是落入了“功能蔓延”的陷阱。

但實際上恰恰相反，這支團隊分辨了哪些使用案例能實現盈利，同時也為不同的客戶傳遞了同樣的產品愿景。

為避免無關的功能，你一定要清晰地明白你的產品是什么，以及如何最好地將它帶給某一類客戶。

這里有三種途徑：1.對功能進行經驗測試。

這種測試應該具備一個流程來確定某種功能的相關性，以及它會如何在特定的客戶群體中幫助他們實現產品愿景。

谷歌的HEART測試就是個很好的例子。

它鼓勵你去檢測用戶的幸福度、參與度、采用度、保留度和任務成功率，這些測試能迫使你去思考這項功能是否和你的目標客戶相符，是否對他們有幫助。

2.拒絕功能請求。

并不是所有的功能都拒絕，但要拒絕其中一部分。

例如，Basecamp公開拒絕在產品中添加甘特圖，哪怕有一位用戶在博客上發表了不滿言論，因為創始人Jason Fried相信，他和這位用戶只是在“優秀的項目管理需要什么”這個問題上存在分歧。

專注于產品的愿景，意味著你要仔細思考每一個功能請求（包括內部和外部的），以決定是否要將它加入到公司的產品開發理念中。

3.如果你承諾了一些強大的功能，那么就不要去擔心功能蔓延。

想想Clearbit和ipinfo這兩家API公司，它們對客戶做出了不同的承諾，最終他們提供的產品相差也很大。

ipinfo承諾用戶能夠“快速、簡單地將IP地址寫入腳本或網頁中”。

最終它提供了一個簡單的API，實現了這個功能。

Clearbit則承諾“打造企業智能API”。

如今它針對市場、銷售人員和開發人員推出的API系列并不是什么功能蔓延，而是變相地實現了當初的承諾。

這種設計過程可能會附帶著開發出很多功能——也有可能開發出的功能不多。

數量并不重要，但針對不同客戶和整個客戶群的相關性和效果如何才是關鍵。

圍繞著客戶激勵來打造你的團隊如果你發現自己的產品無用的功能太多，那么你一定要想象這是誰導致的。

每個人都有發言權，在產品設計中往往弊大于利。

在任何規模的團隊中，我們常常容易看到，對于產品的發展方向，大家都有自己的看法。

這些壓力可能來自投資人，他們認為增加某些功能可以幫助公司盈利；有些則來自營銷和銷售團隊，他們需要實現自己的季度目標；設計人員和開發人員會聽取客戶反饋，并試圖打造一種解決方案以滿足每一位客戶的請求和抱怨。

那些高度關注產品愿景的人，并不一定對你的大部分客戶最有幫助。

各種不同的意見很快會把團隊逼瘋。

你在忙活文件編輯器，因為股東想要它。

他在設計搜索功能，因為客戶需要它。

然后彼此都不知道對方在干什么，以及為什么這么干。

最后，產品開發的速度也會被拖慢，甚至停滯，因為大家都不協調。

筆者個人也經歷過這種“群體設計”帶來的危害。

我和另一位Crazy Egg的聯合創始人Neil Patel，就因為這個問題損失了100萬美元。

在Crazy Egg之后，我們試著去打造一個類似Grid System共享主機平臺，我們管它叫Vision Web Hosting。

每個人都有不同的動機，只會在一開始就模糊了產品開發的方向。

每個人都有話要講，這導致我們的開發進程很慢，產品發布也被推遲了。

我們打造了一大堆功能，但它們并沒有讓客戶之間的主機共享變得更加容易。

最終，它毀掉了產品和團隊。

我們的產品根本沒有問世，兩年后整個項目也被迫關門，這個過程中，我們的損失達到了100萬美元。

加上我和Neil，Vision Web Hosting的團隊只有五個人。

我發現，相互矛盾的意見哪怕只有幾個，也足夠讓人頭疼了。

在更大的組織里，產品意見的協調就更加困難，而且容易缺乏組織紀律性。

這里有幾個方法能幫助你協調團隊（不論你的團隊規模如何）：1.給目標設定不同的登記，確保這些目標都與產品的總體愿景相關。

谷歌擁有一個內部的評級系統，團隊的每個成員都可以在里面設定自己的OKR（目標和關鍵成果），而首席執政官則為整個團隊設定OKR。

接著每個成員的完成結果都會被評估，并根據整支團隊的業績評價管理層。

2.確保團隊每個成員都知道你要打造什么。

哪怕你設定了團隊的總體目標，你也要讓他們明白為什么要這么做，以及每個人應該如何讓產品變得更好。

這就需要每個人都了解產品的運作原理（正如Intercom設計的消息傳遞系統）——因為你不能假設每個人都同步。

3.讓你規劃的路徑透明公開。

整個團隊應該都能看到未來前進的路線，并以此來指導自己的工作。

同時，你要有一個具體且透明的計劃來應對開發進程的延緩。

Asanato和Airtable這些工具就能幫上你。

當然你也不可能完全摒除外界的干擾。

但你可以在團隊內部控制產品的開發動機，確保每個人都有具體的且彼此相關的任務。

你構建的團隊需要每個人都有相同的動機，同時還要評估每個人以及整個團隊的進度。

強大的愿景和執行結構為用戶打造一款相關度高的產品，并不需要你急著去管理“功能蔓延”。

因為這相當于治感冒的時候就治流鼻涕。

背后的問題確實存在，功能蔓延只是表象，你需要深入到根源，了解公司可能發生的問題。

首先你要確保產品的確給目標客戶群傳遞了價值——也就是常說的“市場匹配模型”。

我最近對Slack的市場匹配模型進行了分析，告訴公司們如何尋找自己的目標客戶。

這個過程基于Sean Ellis對市場匹配模型的定義，它是很好的出發點，能幫助你確定自己的產品是否給客戶提供了他們需要的價值。

在Slack的案例中，人們用于描述Slack價值最常用的詞匯就是“交流”和“團隊”。

這恰恰符合Slack最初向客戶承諾的價值——“你所有你需要的資源和利群集中起來，幫助你完成任務”。

總結下來，產品價值的實現主要分為以下幾個步驟：1.了解哪些客戶群體能從你產品的核心價值中受益，他們的需求是如何與產品的總體目標相符合的。

2.采用一種統一嚴格的框架來為所有客戶評價你的新功能。

這能防止你弄出一堆沒用的功能。

3.確保你的團隊擁有共同的目標，并且它的結構能夠激勵那些能對產品開發產生直接作用的群體。

4.你的產品規劃能夠被團隊的每一個成員知曉，讓他們明白為什么要朝著這個目標前進。

總是擔心功能蔓延并不能讓你獲得成功，解決背后的問題才是根本。

只要你集中精力去做好每一件傳遞價值所必須的事，那么你就不用擔心創造出來的產品是否跑題或者太過臃腫。