起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求分析之辯證偽需求
一個偽需求帶給產品的傷害是災難級別的，不僅做出來一個沒人用的產品，還浪費了公司的資源。那么，如何分辨偽需求呢？本文作者從“iPad點菜”和“客戶自助式貸款信息提交H5頁面”這兩個需求案例進行了分析，一起來看一下吧。
產品經理主動發起一個需求或接受一個新需求時，非常重要的一個環節是需求分析，一般而言，這個階段花我們最多心思的是提煉需求、優化需求、權衡利弊，但往往忽略了對需求的真偽做一個辯證分析。
一個偽需求帶給產品的傷害是災難級別的，它不僅僅是做出來一個沒人用的產品，還浪費了公司的資金，更糟糕的是項目團隊所有成員的努力都白費了，十分打擊團隊的士氣。因此，需求分析時排除偽需求乃重中之重。
那分辨偽需求有什么比較好的辦法呢？本文將以“iPad點菜”和“客戶自助式貸款信息提交H5頁面”2個需求案例，分別使用Y模型分析方法、用戶場景流程分析方法與大家演示辯證的過程。
01
需求：iPad點菜；
背景：2016年，隨著互聯網各大軟件的層出不窮，電子化、無紙化大行其道。A公司是一家以提供高端定制化軟件為賣點的技術公司，主要客戶是國內高端的餐飲酒店。彼時餐飲酒店的菜單多為紙質菜單，單本價格不菲，而餐飲酒店的菜單隨著季節交替變更較為頻繁。于是，一些大客戶餐飲酒店提出在iPad上實現點菜。
目的：開發一款在iPad上點菜的APP，取代紙質菜單。
A公司拿到這個需求的時候，主要從以下幾個維度分析，并得出了開發iPad點菜的結論。
表1-iPad點菜對比紙質菜單的維度分析表
分析得出的結論都沒問題，但這是一個偽需求。為什么？讓我們用Y模型來分析一下。
圖1-Y模型圖示
Y模型需求分析的思路淺析：第一層：用戶提出的訴求，第二層：他訴求的目的，第三層：他的心理上的訴求。結合成一句話就是：收集到用戶的訴求時，我們要了解他訴求背后的目的，再確定他心理上想滿足的點，最終設計出一個可以滿足他心理訴求的功能。
那么，我們開始分析iPad點菜需求。
第一層（用戶提出的訴求）：大客戶餐飲酒店提出在iPad上實現點菜；
第二層（訴求的目的）：更低的成本、方便菜品維護、方便賬單維護、更高級的外觀、客人可以看見更多的菜品信息；
第三層（心理上的訴求）：分類歸納為，對酒店而言可以降低成本，對客人而言可以讓客戶感到更高級的服務。
由此我們發現iPad點菜實際上是滿足2B（酒店）和2C（來酒店吃飯的客人）兩類用戶的訴求，為酒店省錢，讓客人感到高級有面子。但是這里有一個很大的坑就是，對于提出需求的的酒店，更低的成本、方便菜品維護、方便賬單維護這幾個目的確實可以通過iPad點菜很好的實現。但是，客人真的能通過iPad點菜體驗到更高級的服務嗎？
圖2-iPad點菜系統界面
我們不能聽需求提出人的一面之詞，一定要站在用戶的角度想一想，我們再通過Y模型的第三層反推一下客人會不會想要iPad點菜。
第三層（心理上的訴求）：我要吃飯的時候體驗更高級的服務；
第二層（訴求的目的）：多樣化的服務體驗、貼心恭敬的服務員、優雅的就餐環境、很難吃到的美食……
第一層（用戶提出的訴求）：能享受按摩、美甲服務、全程服務員伺候、拍照美美的高級包廂、品嘗法國紅酒……
這么一想會發現，對于客戶而言，高級服務基本不會是iPad點菜。因為，對于普通人而言，有一個在身邊供自己使喚的人帶來的優越感遠比一臺貴重的機器多得多。
我們可以回憶一下近幾年去餐廳吃飯，基本沒有餐廳會在客戶落座后會遞上一個iPad。高級點的餐廳在客人點菜時，肯定會有一個服務員畢恭畢敬地站著，給你介紹菜品，給你記菜。
PS1：這也可以解釋為什么餐廳、酒店、美發等行業寧愿多花一些錢在雇傭員工、裝修上，以及一些花里胡哨的地方，也不會為了提高效率去落實電子化、數字化，因為那會減少他們的客流。
02
需求：客戶自助式貸款信息提交H5頁面；
背景：B公司是國內領先的金融助貸服務公司，有一個與銀行直連的CRM系統，每天有2000名坐席在該系統通過“電話銷售+文字溝通+系統錄單”的模式進行作業。而隨著國內的監管日益嚴格，公司的安全合規部門也提出更加嚴厲的規定：不允許銷售員工接觸任何的客戶敏感信息（手機號、身份證號、銀行卡號、家庭住址等）。為客戶辦理貸款期間，大概有100個字段需要客戶提供，如果完全按照規定執行會導致部分貸款業務無法開展。
目的：通過讓客戶自主完成貸款信息填寫，規避安全合規風險。
我當初想到自助式貸款信息提交H5頁面這個方案的時候，半夜激動的睡不著覺，但與富有經驗的銷售主管聊過之后，便徹底否定了這個方案。接下來，讓我們以用戶、場景、流程來的分析方法得出以上結論。
用戶：有貸款意向的白領、小微企業主，年齡段為40歲的正態分布。
場景：坐席端：上班時間，通過CRM系統呼叫客戶，此時除了知道客戶有意向辦理貸款和一個掩碼的手機號（132*****888）之外，其他信息均需客戶提供；客戶端：上班時間，收到一個標記為B公司的號碼。
流程：見以下流程圖。
圖3-坐席貸款銷售流程圖
通過以上分析我們可以比較簡單的得出：貸款的流程較為復雜，所需的信息較多，而主流的貸款客戶并不是移動互聯網的高端玩家，難以完成貸款信息的自主提交。
作為產品經理想到這么完美的一個解決方案，我當然不愿就此放棄。公司還有專業的坐席，如果不只是甩給客戶一個表單H5，而是給H5的同時，坐席給予操作引導，那么不就可以讓客戶完成貸款信息提交了嗎？這樣當客戶提交后，系統再自動同步表單數據至坐席端，坐席只要負責簡單的內容校驗即可。
如果真這么做了，那產品經理就是想當然的閉門造車了。實際上，在上述流程圖中，客戶流失率非常高，基本每一個客戶端的判斷都要損失50%的客戶。而將表單交給客戶填寫，意味著留給客戶思考的時間增加，客戶思考得越多，亂七八糟的想法就越多，流失率就越高！
圖4-貸款表單之聯系信息填寫界面
圖5-投保界面（如果客戶自助填寫，填寫量是該圖的4倍）
PS2：我國的金融貸款普及并不全面，民間借貸、高利貸、黑網貸仍是許多人心中的陰影，雖然B公司是正規的銀行貸款，坐席也完全按照行業標準話術向客戶說明貸款信息用途，客戶在電話中依然非常防備。
稍微設身處地就能體會收到H5的客戶腦海中的胡思亂想，一開始他們會覺得“咋那么多東西要填，真煩！”，然后在填寫征信時會想“他收集我的銀行卡、手機號，萬一是騙人的，我還這么傻在弄……”，填寫親屬聯系人信息會想“萬一他去騷擾我的家人……”，提交貸款證明材料時會想“要是搞了這么久還弄不到錢……還是找個靠譜點的銀行再問問”。于是就換了一家銀行去咨詢貸款。
PS3：大家可能會好奇，那最終如何解決安全合規的問題呢？其實最終的解決辦法并不是靠需求，而是與安全合規部門做了溝通，在合規允許的范圍內調整了規定，除非必要，才允許坐席向客戶在電話中索要客戶的敏感信息，且必須通過文字的形式發給坐席，這相當于客戶同意并主動提供。
補充說明：
Y模型需求分析的更多詳細介紹可參見《人人都是產品經理2.0》
通過用戶、場景、流程分析需求的更多詳細可參見《幕后產品》
本文由 @吳德馨 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
論證是否為偽需求，前期靠產品的經驗以及大局觀，后期取決于上市后是否還有企業應用， 海底撈還在使用ipad點餐
還要回歸到開發這款產品的企業
作者你好，我是否可以這樣理解。其實需求的真偽在很多時候不是用對錯來評判的，而是看這個需求與解決方案對于這個問題所處的場景等是否合適。比如ipad點餐這個案例，我的理解是它確實可以提高用戶體驗，節省成本。對于海底撈來說，有著品牌效益的加持下其實很多店鋪的流量并不稀缺，在無需擔心客流量的情況下用ipad顯然可以節省成本，對于那些沒經歷過的客戶來說也不失為一種新奇的體驗，能帶來高級感。但是對于那些以高級著稱的服務對象是老板的餐廳來說，用美女服務員貼身服務這個方案有更好的效果，以此能吸引更多的人，在這種時候人工成本顯然小于其能帶來的收益，所以不選擇ipad點餐的方案
你理解的太對了！
掃碼點餐就是節省了人工成本
對小餐飲店來說是節省的，對酒店和大餐廳并不會
沒太理解，菜單的這個明顯滿足了客戶的需求，難道需求必須同時滿足客戶和用戶才是真的么。。。
解決方案就是現在的掃碼點餐
他這個站的角度、分析角度其實是把業務也考慮進去了，如果我們作為技術開發部門或者外包方的話是不用考慮到酒店客人那一層的。
第二個銀行的案例其實是我們產品經理要考慮的，流程順暢、客戶使用便捷程度等等
產品對于企業自身以及客戶來說，都需要提高收入才能實現產品價值，而如果用戶不愿意買單，那么客戶也就不愿意買單，對開發這款產品的企業來說就沒有價值了
這個兩個需求其實都不算是偽需求，第二個需求我還真實的做過，只是這兩個需求的實施場景需要很多輔助功能來解決，不能單純的依靠產品本身來解決實際問。
你說的沒錯。類似案例中產品的解決方案不是軟件或系統，而在系統之外的服務流程設計。