伴生性需求在整個產品生命過程中占據(jù)極大的比重，如果說創(chuàng)造性需求是可以燎原的星星之火，伴生性需求便是為火焰燃燒提供的若干枯草。

什么是伴生性需求

在我們做產品時，存在許多沒有太大價值，但又必須具備的功能，這部分需求我統(tǒng)一定義為“伴生性需求”，屬于某些主干需求的衍生枝干。

• 當我們決定開發(fā)賬號系統(tǒng)后，除了注冊和登錄是必須的功能，與之相對應的還會包含修改密碼，找回密碼這些非常規(guī)功能，此時，修改密碼，找回密碼就屬于典型的伴生需求，
• 我們向用戶提供了上傳照片的功能，對應的就需要提供刪除照片，盡管用的人非常少，使用頻率也非常低。

伴生性需求必須存在，但卻不是非常的緊急，實際上，許多團隊，往往會將伴生性需求挑選出來，必要時將這部分需求舍棄，置入下個版本的迭代計劃。

正如他的定義一樣，伴生性需求必須存在，但缺少這部分需求，并不會造成多數(shù)用戶的不滿，損失非常有限。

產品經理加班的情況僅次于研發(fā)人員，實際上我們是一群和時間賽跑的人，與團隊中的其他成員一樣，我們也希望這個版本能夠盡快的上線，投入到市場使用，然后獲得非凡的成就。

而即使再多的資源，再多的人力，也沒有辦法同時開啟所有需求，這是伴生性需求的一個特點，他總是承擔著我們減負的第一個重擔。

伴生性需求的舍得特色

成熟的產品經理懂得砍需求，懂得對需求做減法，這個能力看上去很飄渺也很個性，可能大家聽了許多次也只能幻想，手握數(shù)千需求，談笑間，便砍去·五百，對于這中間如何少的，為什么有些需求能砍，為什么有些需求不能砍，想來會非常困惑。

需求有主次，我們做產品的過程中，在每個版本里都會體現(xiàn)出需求的主次，需求的順序，MVP 理念，需求優(yōu)先級乃至于 kano 模型的都可以體現(xiàn)出這個觀點。

我們會圍繞核心需求投入許多資源，這些核心需求也就是我們的主要需求，同樣的，我們會舍棄次要的需求，必要時，我們會舍棄一些看上去非常核心，但實際上他是僅次于主要需求的一個最大的次要需求。

現(xiàn)在告訴大家一個方法，能夠極大的增加大家砍需求的能力。

現(xiàn)在我們有5個需求，但我們的資源以及我們的時間只允許做3個需求，你會舍棄那些需求呢？

1. 為用戶上傳的照片增加貼紙功能
2. 做一個開放式的群聊，全平臺用戶可參與群聊進行互動
3. 開放上傳原圖，用戶可選擇上傳原始尺寸的照片
4. 允許單次上傳多張照片，即批量上傳
5. 開發(fā)斷點續(xù)傳的功能，用戶上傳照片失敗，可點擊繼續(xù)上傳，已上傳的照片不需要重新上傳

這個題目其實很難回答， 也缺少正確答案，在不同的環(huán)境下，我們會有不一樣的選擇，需求的取舍與很多因素有關，并不是單一因素造成的，但是，將問題稍加修改以后，我想你現(xiàn)在會進行取舍了。

現(xiàn)在我們有5個需求，但我們的資源以及我們的時間只允許做3個需求，你會舍棄那些需求呢？

1. 為用戶上傳的照片增加貼紙功能 [伴生需求]
2. 做一個開放式的群聊，全平臺用戶可參與群聊進行互動
3. 開放上傳原圖，用戶可選擇上傳原始尺寸的照片
4. 允許單次上傳多張照片，即批量上傳 [伴生需求]
5. 開發(fā)斷點續(xù)傳的功能，用戶上傳照片失敗，可點擊繼續(xù)上傳，已上傳的照片不需要重新上傳

是不是很容易識別出來，基本所有的伴生需求，在優(yōu)先級里都是可以被舍棄的，但并不是完全舍棄，只是在下一個階段或者未來的某個時機，再來做，也許到那時，該需求就已經不再是伴生性需求，而是創(chuàng)造性需求了。

只要我們能識別出需求性質，是被出伴生性需求，我們就能自己嘗試去砍功能。

伴生性需求的特征

作為減負的一個絕佳選擇，是伴生需求的應用特征， 而我們能夠如此應用還要歸功于伴生性需求本身的特色，即伴生需求無法單獨存在，對其他功能具備極強的依賴和從屬性質。

修改密碼的功能對于我們來講太常見了，這個功能便是典型的伴生性需求，若我們的賬號系統(tǒng)，僅支持第三方賬號登錄以及短信驗證碼登錄時，該功能便失去了存在的價值。

離開了自定義密碼這樣一個字段，修改密碼的功能在邏輯上就已經不成立了，換言之，修改密碼便是設置密碼的伴生性需求

同樣是設置密碼的伴生性需求還包括了”找回密碼“這個功能。

如果設置的功能都不存在，那么圍繞密碼展開的修改密碼以及找回密碼就不再具備任何意義了。

我們所認識的伴生性需求，最典型的特征便是依附于其他功能而存在，本身是無法單獨存在于產品內的。

作為一款圖片社交產品，允許用戶刪除照片以及對照片設置隱藏加密功能，也是一組鮮明的伴生性需求。

不論是對照片做任何形式的處理，或者業(yè)務，都需要建立在照片成功上傳的基礎之上，圍繞照片展開的一系列功能均屬于從屬且依賴于被上傳的照片而存在。

這些功能的操作主體便是被上傳的照片。

可如果這個主體不存在，這些功能還會發(fā)生 效應嗎？ 若用戶上傳照片的功能被阻塞，那么這個照片的本體就不復存在，也就無法再圍繞該主體展開功能型操作了。

現(xiàn)在，許多產品做的很重，而且這個問題的兩處重災區(qū)一個是從0到1的過程中，堆積了大量需求，1.0版本研發(fā)了一年多的時間上線，在這些問題的背后，便是我們將若干的伴生性需求當成了真正的用戶需求。

現(xiàn)在，你是否學會如何舍棄某些需求，以及如何辨識出伴生性需求呢？

伴生性需求”做功能“

伴生性需求本身是作為需求存在，可在做的時候，我們卻不能將他當做需求來理解，這部分需求更多的是以功能補充的形式存在，極少用戶反饋里會提及到這些。

因此，這也是最適合新人入門的一個領域，借助對伴生性需求的駕馭，會幫助我積累更多的功能庫，逐步的掌握功能的使用方法以及開發(fā)過程。

我們關注伴生性需求，不需要考慮他是否符合人性，是否存在需求，是否存在影響力，只需要去思考如何做會更好一點，這會逐漸的增加我對功能的駕馭能力。

許多新人會容易犯的一個錯誤，不太重視文案，過多的將精力花費到了功能設計以及看各種資料上， 這其實是舍本逐末的做法。

《精益至上》 這本書里提到了這樣一個案例：

某電商網(wǎng)站的用戶新增很難提升，在一次優(yōu)化嘗試下，數(shù)據(jù)呈現(xiàn)了客觀的增長，這個小小的優(yōu)化，只是將注冊按鈕的位置做了一些調整，可以說沒有進行任何功能的新增，只是調整了局部的布局。

與之同樣的，我們也能從文案中看到差異，我們以一句簡單的注釋來舉例：

1. 參與活動，有機會贏蘋果7
2. 贏蘋果7，參與活動，你也可以

兩句文案很難說誰好誰壞，但我們能清晰的從這兩句話感受到不同的信息，第一句，我們認為參與活動是主體，贏得東西是輔助的，第二句，則變成了贏蘋果7是主要的，而活動只是輔助的信息。

在做伴生性需求時，當盡善盡美，此時我不需要為整個產品的商業(yè)價值負責，不需要為用戶需求負責，但我們需要對功能負責，讓功能更容易被大家接受，不顯得粗糙，難用。

僅僅是將伴生性需求做出來，是無意義的，而且會極大的損害自己的成長，這個階段的我們更多的與功能貼近，嘗試更好的去表達功能，而布局和文案的使用反而是這個階段對我們的兩大挑戰(zhàn)。

#專欄作家#

枯葉，微信公眾號：枯葉咖啡館。人人都是產品經理專欄作家。近6年經驗的產品經理，擅長社交、社區(qū)、細分群體挖掘。

本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。