起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理的“元需求”：如何提出對需求本身的需求？
對于需求，我們更應慢思考、快執行。
心理學上有個術語叫“元認知”，即：人對自我認知過程的認知。是人類對自我認知監控的一種極其重要能力，這種能力在個體間差異也是很大。優秀的元認知能力可影響人的一生。
同樣，對于產品經理來講，每天會和大量的各種需求打交道。有的來自不同用戶，有的來自跨部門或管理層甚至老板。當面對這些需求時，我們如何高效、準確地把握和解決需求，提出對需求本身的需求，即“元需求”。下面就談談自己對于需求本身的理解。
通常作為產品從業者，可能會遇到以下場景：
路人甲：這里有個XX需求，你就按照XX方法，幫我加個XX的功能（或XX的流程）。
路人乙：用戶A反映有XX問題，覺得要加個XX按鈕（功能）解決。請給個排期。
是不是有種熟悉的配方？熟悉的味道的感覺？特別是類似需求從高層下達，更是讓很多產品人感覺壓力山大。那么這里我并不推崇“大干快上”的趕緊解決的思路。產品的快速迭代不代表思想上的偷懶。
我的經驗是，首先得對需求本身進行“過濾”和“加工提煉”。分成三大步驟：需求反思、需求定義、需求解決策略。下面我將就此三點分開來談：
PS：本階段思考分析的“慢”是為了后面執行解決的“快”，這步急不得。
一、需求反思
首先，需要對各種管道收集上來的需求進行反思（注：這里的反思是指對于思維本身的思考，而不是“反省”的含義），需要從如下幾個方面進行分析。
1.需求的合理性
需求本身是否合理。這是一切需求發生的原點，如果需求本身的合理性遭到質疑，那么后面的一切針對此問題的構建都是毫無意義。所以最開始需要花點時間對需求本身進行批判性思考。
實際情況中，可能會有種特例。即：該需求是來自你的直屬上司，或者VP、老板。那么思考需求合理性有意義嗎？我認為有兩點。第一，思考事務本身的行為是中性的，結論是不會以對象是誰而發生改變。其次，來自高層的需求本身也是需求管理一部分。
換句話說，產品經理也得懂得管理上級的需求。如果管理需求這種需求本身是不能執行的，那么參見“需求擱置”處理方式，后面會具體談到。
具體從哪幾個可執行點上來思考合理性問題。這里我給出相關建議，如果補充或爭議歡迎提出。
是否符合法律法規要求
這點原因不需要做具體說明。所有可能實現的需求都須在現行法律法規框架下運行。對于互金行業的企業尤為重要，在這一點上產品經理需多和公司法律顧問及風控部門進行溝通確認，此點尤為重要。
是否符合用戶利
一切產品都是以用戶利益為依歸。這里需強調是，在作分析時候需要回歸到用戶通過使用產品達到什么樣的目標這個問題的本質上，而不是以BAT是這么做的為背書來評判需求。
至于如何知道是否符合用戶利益，業內也有許多方（tao）法（lu）如：MVP、灰度發布等技巧來驗證假設需求。這一點展開內容很多，限于篇幅讀者可自行網上搜索。
是否符合企業目標
此需求對于企業是否能實現商業目標，或者在盈利模式比較模糊的情況下，能否帶給企業正向價值，甚至創造良好社會價值。例如，摩拜單車。前不久CEO接收采訪坦言尚未找到盈利模式。雖然高昂的維護、教育市場成本，及面臨亂停亂放等問題。
但作為創始人在杭州租單車不便的個人痛點所衍生出來的一個創新解決方案，給人們最后5公里出行帶來了巨大的社會價值。這為企業帶來巨大正向價值。從最新一輪融資可見。
是否超出目前企業資源
很多需求本身出發點很好，并且符合以上三點。但超出企業當前的資源約束。通常情況下，需考慮幾點資源約束：人力、資金成本、時間成本、技術條件等。特別對于創業企業，以上約束尤為明顯。所以需要對問題做優先級分類。以MVP作為衡量標準，確定最核心需求邊界。在邊界以外的需求在商業模式驗證成功后，后期快速迭代補上。
是否符合相關利益者目標
這一點對于B2B模式，或者B2B2C模式極為重要。因為利益相關者和企業為聯盟。比如在大多數O2O項目中，B端是企業間接觸達C端的通道。如果這個通路的利益或訴求得不到很好滿足，就會極大影響終端用戶的轉化率，達成率，甚至帶來負面影響。在消費金融行業，初創企業往往非常關注審核時效性，但忽略商戶本金及時發放。導致商戶以后將優質客戶介紹給競爭對手，形成一個信譽漏斗，最終使企業得到次級信譽的客戶。
2.需求的負面性
需求之所有稱之為需求，即為現有模式不能滿足的但又期望得到滿足的痛點。本質上是一種對現有狀況的改變或補充。那么一定會涉及到對存量的影響，這種影響往往最初帶來的效應的負面的。
對改變的恐懼
既然涉及到對現狀的改變、那么即為對現有習慣的挑戰。更多的是心理上人們對于不確定性結果的消極預期。這樣的負面效果會有多大，需要謹慎評估。有些現狀雖然理性分析上不合理，但長期已經培養起的用戶習慣導致難以輕易改變。
舉個栗子，我們現在使用的鍵盤布局為QWERTY型。當時為了減慢打字速度防止打字機卡死。顯然當今已不存在技術障礙，但由于人們長久習慣的慣性導致保持舊有規則即為最合理。
存量利益的反抗
由于需求帶來的改變也會對存量利益關系的改變，導致需求本身遇到反（si）抗(bi)。比如在互金行業，有時為了更好的防范風控增加信審安全級別，就會導致申請步驟增加，間接影響到銷售團隊的業績。這時提前預估阻力，做好相應的應對措施是很有必要的。
新需求的風險
一言以蔽之，沒有風險的新需求都是耍牛氓。
是否能承受相應風險，愿意付出創新成本都是需要提前做好準備。
3.需求擱置
有些需求不解決可能是最好的解決。因為由于許多特殊原因，擱置需求本身是一種明智選擇。
例如前面提到的特例，關于管理上級的需求。如果你改變上級原有需求的這個需求本身無法實現，那么請擱置自己這個需求。執行上級安排的需求。
二、需求定義
1.需求類型
完成上一大步后，需要知道需求本身的屬性。首先做一個歸納。把不同需求標記為不同屬性和優先級、以便更好管理。這里優先級從高到低分為“IT技術問題”、“業務邏輯需求”、“用戶體驗需求”以及“用戶認知問題需求”。
IT技術問題
狹義定義來講，此類型不能算作需求。但此處是從廣義定義上來理解。具體類型細分為：Bug型、代碼質量型、服務器性能型。優先級從高到低。
業務邏輯需求
業務本身的變化需求。大致為對存量業務邏輯的改變，“邏輯自洽型”、“流程通暢性型”、“流程冗余性型”。以及對增量業務邏輯的添加，“功能點完備性型”。
用戶體驗需求
用戶體驗主要細分為：“人機交互效率型”、“用戶心理預期型”、“界面布局合理型”、“操作習慣符合型”、“外觀美學型”、“教育文化符合型”。
解釋下“用戶心理預期型”和“教育文化符合型”。前者指的產品在某個場景下或流程中的操作反饋或產生的結果要符合用戶當時的預期。不然用戶就會有被打擾感和失控感。后者指產品需符合國家或地域文化。比如歐美的線下party、中國的線上社交、日本的御宅文化都催生出不同的產品形態。
用戶認知問題需求
主流用戶的認知是有一個門檻的。雖然多數情況下，普通人都在此門檻之上，但還是不能排除在我們熟知的圈子之外或者一些小眾群體是低于這個認知門檻的。導致產品本身不被這部分用戶理解，需要先要教育這部分用戶，培養起認知習慣。
2.需求制造方
需求是由誰制造的，或者稱為需求產生的源頭方。弄清誰是真正的源頭才能回溯到需求的本質去解決。這里想強調，需求的提出方（需求從哪來）不一定是需求的制造方。這一點會在后面需求的渠道具體展開。
例如，表面上需求是由運營提出的，但實際可能是一部分用戶制造的需求。有些看似是用戶的需求，但本質上可能是內部管理問題所反映。
需求的制造方細分如下：
- 終端用戶
- 利益相關者
- 內部管理層
- 產品設計者
- 程序開發者
可能會覺得程序開發者也會制造需求嗎？確實在某些情況下，開發者處于自身工作便捷性考慮，會主動對某些邏輯流程提出需求。這時候產品也需要綜合考慮分析。
3.需求核心內容
需求到底是什么？他的核心內容是什么。理解和描述之前是否有歧義或二義性，這是需要溝通分析中注意的。
三、需求解決策略
1.需求解決方
做完前兩大步（需求反思、需求定義）后，需要設計需求的解決策略。在解決方案擬定之前，還需要知道誰能解決這個需求。對于產品來講，這些解決方可能會是如下：
- 產品經理
- 交互設計
- 視覺設計
- 前端開發
- 后臺開發
2.需求的渠道
需求渠道區別于需求的制造方在于，需求制造方是需求的真正源頭，而需求的渠道只是需求的轉述或反映。有時候一個需求源頭會在多個需求渠道中反應出來。
簡單的講，需求制造方就是“從哪來”，需求的渠道是“通過什么來”
當然需求的制造方可以和需求的渠道為同一方。
總結
三大步驟：需求反思、需求定義、需求解決策略
- 需求反思：需求合理性、需求負面性、需求擱置
- 需求定義：需求類型、需求制造方、需求核心內容
- 需求解決策略：需求解決方、需求的渠道
以上為在提出具體解決需求方案前，所做的處理工作。對比拿到需求就馬上拿出應對方案；而是慢思考、快執行。防止了因為考慮不到位導致解決了某個問題產生新問題，反復來回不停硬試錯的狀況。
老話說得好：磨刀不誤砍柴工。希望各位產品經理都是“親媽”，而不是“奶媽”。
作者：雨山薪，微信公眾號：山語錄（sumitalk）
本文由 @雨山薪 原創發布于人人都是產品經理。未經許可，禁止轉載。
非常的棒~