很多時候我們都會遇到一種“你就這么做”的需求，如果處理不好，很可能給自己挖一個大坑。作者總結了3個步驟，希望可以幫到你。

最近工作中總是接到一種需求：我要 XX功能，這么做就行！

也就是需求提出者直接帶著解決方案找過來，這種需求在產品的工作中十分常見，如果處理不好，很可能給自己挖一個大坑，這篇文章聊一下可以如何接這種需求。本文的描述是基于自己的 C端經歷。

從業務部門的一個需求說起

在家辦公期間突然接到業務線老大的一個語音，開門見山的和我說：現在我們做的直播，想要在直播過程中和用戶增加互動，需要在直播中加上答題功能。

具體方案：一次最多 5道題，主持人發起，(此處省略 500字)，甚至后臺怎么配合都給我說了，然后緊接著問我：什么時候能做完上線？

這種直接帶解決方案的需求在產品的工作中，經常會碰到，尤其是業務主導，業務方比較強勢的公司中更為常見。如果我們直接執行會怎樣呢？

產品經理直接從解決方案出發會碰到的問題

對于這種需求，有時可能習慣性的就跟著提出者的解決方案走，直接討論解決方案的邏輯及細節。

趟了幾次坑之后，我發現直接跟著解決方案走，很可能會遇到如下兩種情況：

（1）需求是合理的，但是提出者給的解決方案并不好，只是就問題解決問題

這種情況下，提出者的需求是合理的，但由于提出者可能并不具備產品的專業技能，導致方案有缺陷，無法解決問題。

比如，產品的活躍度很低，不健康，于是負責的同事 A找過來：我們產品的活躍太低了，要提升，我們要多給用戶增加推送，每天推送 10條，讓用戶想起我們，打開我們！

用戶活躍度低需要提升，這個沒問題，但是不分析原因，強行 push，打擾用戶，可能初期有一點點效果，但長期下來，只會讓產品的卸載率上升。

（2）需求是不合理的，是提出者想當然的結果

這種情況，提出者提出的需求是“錯誤”的，是自己想當然的，給出的解決方案必然也是錯誤的。

常見于不考慮產品的目標用戶，以及用戶的實際使用場景，只是單純的就功能自嗨。

以上兩種情況，無論是哪種，如果產品直接跟著解決方案走，最終的效果都不會很理想，甚至會導致項目反復，臨時變更，越做越復雜的情況。

對于這種“你就這么做”的需求如何接

首先我們要知道，解決方案并不等于需求！對于這種情況，我們要回到需求本身，從需求入手。

很重要的一點是：討論問題，以問題代替方案來和提出者討論。

可以分為以下幾個步驟：

1. 拒絕傳遞需求，盡可能找到“需求當事人”

在工作中，可能有很多時候，需求是由老大或者業務部門的老大直接提給產品經理的，也就是需求經過了其他人的傳遞，這種情況下，信息內容可能會失真，和開始的需求不一致，甚至可能“面目全非”。

我們在接收信息的時候會經過兩步：理解與加工；理解中可能會出現偏差，在不自主的加工后信息的失真會更嚴重。

在傳遞中，他人對信息的理解與加工，可能會影響我們的判斷，如果直接按照傳遞者的說法做，很有可能方向是錯的。

因此，在實際工作中，還是建議允許的情況下，盡可能的和“需求當事人”直接接觸，了解一線需求。

比如，筆者曾經負責的一個小程序，中間有一個步驟需要用戶授權昵稱以及手機號，但在開發的時候發現已經不允許同時獲取昵稱和手機號了，本來打算調整方案，分開獲取。結果一個同事說正好他需要找一下業務，可以幫忙溝通一下，給我返回的結果是他們不要昵稱了，但給到業務測試的時候，發現人家原本的意思是：可以在這一步不要昵稱授權，而不是可以完全不要昵稱。

2. 明確是業務需求還是用戶需求

對于提過來的需求，我們先大致分為兩個類型：業務需求和從用戶角度提出的需求。

之所以要先區分，是因為，這兩種需求的出發點是不一樣的。

對于 C端產品，業務需求通常來自于運營和市場同學，出發的角度是如何更好的運營用戶，是從“KPI”角度出發的；而從用戶視角出發的需求，則是認為用戶是有這個需求的，這么做是更好的幫助用戶。

因此，我們對接這兩種需求的方法也會有所不同。

（1）業務需求

這類需求是業務部門內部的，比如業務部門需要做個活動，或者要提升某個指標，需要產品端配合。

文章開頭的例子中，運營人員提的直播中答題的功能，就屬于這種。

配合業務方，更好的進行產品的推廣、運營，是十分重要的，但我們不能完全“聽從”于業務方，否則業務方不斷的來找配合各種活動，整個項目組的人員都會疲于應付。

對于這種需求，我們要明確兩個事情：

1）業務方的目的

對于業務方的需求，我們首先要和他們明確：這么做的目的是什么？

提出業務需求很合理，但在做之前，需要先溝通清楚業務方的目的，明確目的可以讓我們了解更多的信息，從產品的角度給出思考與建議，更好的配合業務方，也讓我們自己處于主動而非被動的位置。

2）要達到什么樣的目標？如何衡量？

對于需求，必然要有能夠衡量的標準。如果沒有衡量標準，各個業務團隊不斷的做活動、提需求，會讓產品和開發疲于應付運營需求，影響產品的正常進度。

因此，在溝通中，我們需要和業務方明確目標以及如何衡量，要能夠有明確的數據指標來衡量。

明確這兩點：

注：目的和目標是兩個不同的詞。目的更抽象一些，是我們的期望或終極的宗旨，目標則更具體一些，是階段性的追求。比如，運營同學提的紅包活動，目的是想要引導新用戶快速下單，具體的目標則是讓新用戶的下單率提升 10%。

（2）從用戶角度提出的需求

這種類型的需求，提出者通常是因為覺得用戶是需要的，能更好的滿足用戶需求，通常也會帶著“合理”的理由，但我們還是要謹慎。

對于這種需求，我們要明確：

1）需求是為了哪些用戶？

隨著產品不斷的發展，用戶不斷的增加，需求會越來越多，越來越多樣化，產品中不同的用戶，對功能的使用和需要程度都會存在不同，因此，我們需要明確：這個需求，是為了滿足哪一部分用戶？

2）這部分用戶在什么場景下因為什么而會用到她？

需求依附于某一個場景，以及這個場景下遇到的問題。

在明確了為了哪些用戶而做之后，我們還需要明確：這些用戶在什么情況下，會因為什么而需要她。

比如：人人都是產品經理上傳文章的時候，有一個功能：通過鏈接導入其他平臺的文章。這個功能就能夠減輕作者人群，在上傳文章時排版的工作量。3）目標用戶真的“需要解決”這個問題嗎？

有時候，確實有需求，但用戶真的“需要解決”嗎？是否已經有其他的解決方案且廣為人知？

比如筆者的一個朋友，曾經想要做一個大學校園的二手交易平臺。大學生二手交易這個需求和場景都是存在的，但目標用戶真的會有很強的意愿用一個新的方式來解決嗎？即使沒有這個平臺，大學的貼吧、BBS、朋友圈都是他們可以用來出售二手物品的地方。

3. 判斷需求的價值

明確需求后，我們要判斷需求的價值。

對于業務類的需求，可以通過面向的用戶、是否合理、預期投入產出比、是否會造成用戶的反感四個方面來考慮。

用戶角度的需求則可以從以下幾個方面來判斷：

（1）需求的覆蓋度

這個需求所能覆蓋到的用戶是多是少？能夠覆蓋的用戶是產品的核心用戶還是普通用戶？

（2）需求的類型

對于目標用戶來說，這個需求是基本型、期待型還是興奮型？

（3）需求與產品的規劃是否一致

需求對產品本身來講，是否與產品規劃一致，是否能夠幫助產品更好的服務目標用戶？

判斷不同需求的價值，主要是為了明確：

是否要做？優先級如何？

資源總是有限的，我們無法滿足所有用戶的所有需求，因此，我們需要通過對需求價值的判斷，決定哪些需求是需要做的，哪些需求是我們放棄的，以及做的需求中，應該優先做哪些？

注：這里的放棄指的是當前階段，而不是完全舍棄，隨著產品和業務的不斷發展，有一些某個階段不做的需求，可能會在下一階段就值得去做了。

總結

對于帶解決方案的“需求”，核心的一點是：不要跟著解決方案走，解決方案不等于需求！我們要通過對需求類型的區分，用不同的方法來明確真正的需求，并通過對需求價值的判斷，明確是否要做。

作者：海先生，公眾號：慢言錄

本文由 @海先生 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議