怎么區分真需求與偽需求？
大老板在下基層體察民情的時候說：“我覺得這里應該放一個飲水機”。那么很有可能“放一個飲水機”是偽需求，領導渴了是真需求。要滿足真需求，需要做的是隨身帶一瓶水。要滿足偽需求就必須滿屋子的放飲水機。
客戶說“我需要一個自動匯總每月銷售數據的報表”。那么很有可能“自動匯總”是偽需求，“數據真實、靈活的呈現”是真需求。要滿足真需求，需要首先做一個銷售明細的Excel導出，在線外靈活的篩選求和；要滿足偽需求就得準備好應付各種體位的“自動匯總”。
用戶說“我想有一個批量審批的功能，每天點OA太費勁”。那么很有可能“批量審批”是偽需求，“梳理出那些值得我審批”的是真需求。要滿足真需求，需要梳理一遍業務流程，不一定涉及系統的改造。要滿足偽需求就得準備在做好一個“一鍵審批”按鈕后再做一個“一鍵撤銷”。
當用戶直接提出解決方案的時候，往往意味著誕生了又一個“偽需求”。因為他們所指的方向并不一定能到他們所想去的地方。
用戶隨意指的方向和他們真的想去哪兒，就是偽需求和真需求的區別。
我覺得在需求之前，應該是產品短期和長期的價值體現和變量（這個產品的引爆點，一般我們都考慮用戶量和日活等因素…）
第二個在需求之前的是框架
產品邏輯搭建需要的產品框架體系，使得產品能夠按照既定邏輯進行，不至于引起偏差……（創意期產品直面客戶大多談模式，就算你拿原型去討論他們也不會有太多問題存在）
在此基礎下，在用戶應用和頭腦風暴中的問題，我把這些問題稱之為需求，而需求的真偽我覺得應該這樣劃分（個人習慣）。一個周期內驗證一套框架邏輯即可，在框架邏輯內的，是真需求，這些需求可以分為易用性、應用性、流程性三類。易用性決定了產品的難易使用度（我把這個稱之為周期內的客戶的腦容量），應用性則是產品測試期既定邏輯的錯誤、用戶限制（也就是我們管的太寬）等問題的發生，流程性則是在整個產品鏈條上的既定、預估問題發生變化（這個不太好看出來，需要綜合分析）
在產品邏輯、設計中，易用性最簡單搞定，數據埋點和支撐可以讓你看到你的客戶在哪里跳出高或者點擊強烈，客服也能收集到不少的類似問題，規劃和更改著重在前端。（如果是B端的部分產品經理，已經可以進行用戶思維模擬化的話，就自己去走原型流程，進行更改－慎用，很多問題不是你想當然的）
而第二個應用性是后端的功能性問題發生，一般這些問題發生，大多是我們腦洞太大，場景和客戶要的有偏差（如果你是直接項目負責，那么恭喜你，想太多…憋著笑，改吧）這種便差的發生一個是數據分析得出（需要些基礎和對產品全局的了解，不會分析數據的趕緊學），第二個就是客戶通過客服，營銷指導的次數呈指數級增加（史上最難操作：）），應用性會改變部分框架，嚴重的應用性問題會改變整個產品邏輯。
第三個就是我們的既定核心價值沒有體現出來
客戶誤解，或者客戶不關注這個價值。這類問題是數據整個的綜合分析，（騷年，事情已經不是你能搞定的了，開大會吧…）這種場景蠻少見，小一點的公司看不到。
現在我們來說說辯識真偽需求～（這個難度很大，腦袋里有東西，但是沒怎么總結過呢，我嘗試下，大家表罵我…）
第一，偽需求后面藏著真需求；
第二，部分偽需求可以通過已有產品模塊解決，只是客戶沒發現（這里反思流程和易用）；
第三個最難，客戶說的直接需求不是他想要的或者表達的，我還是建議你直接問細致的，我幫你琢磨下…
沒法舉例，因為我做saas+B電商的，語言服務類，俗稱翻譯電商，產品及其產品構成以人的智慧和學識構成…
這里有些劃水，遲到+上班，這兩天我再更新一個。。。。
繼續，仔細想了下，發現在上面架構中，辯識真偽需求已經不是很難的事情，難的是場景的多樣性：
首先，不管是真需求還是偽需求，都是在一個量級用戶下的需求反饋統合，我們在分析歸類后進行的深度挖掘的結果，然后根據量級用戶來選擇具有偏向性的一方，選擇的偏向性為最快到達你階段性目標的…猜測或邏輯。（在初期邏輯和價值確認后，我們不在考慮產品大架構和大框架的問題，那么我們的思維角度就要從P的角度轉向為C的角度，主要做的工作就是歸類、分析、反思）
我做B端（客戶拜訪和溝通中的需求）
舉例1：
我在上上個月和營銷去拜訪一個客戶，為了傳播產品的理念和模式，那么我主要介紹給他的是我們貼合行業特性的協同平臺和只為公司服務的封閉式訂單平臺，而我帶去的目的性是他用我的產品并感興趣，我們互加了微信和QQ，在過程中，我期望產品的討論主要在當前模式下的產品應用，那么這個東西涵蓋了易用和應用性（這些是當時就可以分辨出來的），而邏輯性卻是比較難的。
那么這里我開始編：
1. 用戶提出，二級域名這個東西接受起來很麻煩，每次總是分不清楚；（不確認需求）
2. 用戶提出，在訂單平臺其實可以有更多種服務，能不能把訂單外的X種服務增加出來；（假需求，這需要另一套邏輯兌現和落地）
3. 用戶提出 ，產品在某個模塊點擊不進去；（真需求）
4. 用戶提出，X個模塊在邏輯上應該是這樣的…（不確認需求）
…
那么現在開始分析：
第三個需求可以馬上判定為真需求，因為我們經常進入一個誤區，就是客戶理解能力和部分模塊的穩定性；
第二個需求判定為暫時性假需求，其實這并不是一個假需求，而是在當前周期內，我需要驗證的并不包含這條邏輯；
不確認需求中的第一個，是因為這是個個體現象還是一個群體現象？需要收集驗證。
不確認需求中的第四個，分幾種情況，你足夠了解這個市場，或者你有做過調研，那么這個是假需求，是訂制需求；而你剛進入這個行業，那么先判定成為不確認需求；
數據需求收集：
這個中間分為全埋點和只使用工具+部分埋點的，那么如果是第二種，你看數據的時候，就要貼合你的核心需求來看（這問題好大，MD，掉坑的趕腳啊）。
舉例：
我們直接略過渠道驗證，純粹認為來源用戶都是需求用戶。
那么我要看的數據是：
注冊轉化率（7-15天周期內的變化）：我的核心是不是被清晰表達，邏輯被認可；
細節中間可以看（如果有的話）：
從注冊步驟1-3，用戶在哪個步驟退出率較高或者停留時間較長。
（前者說明此模塊有問題，后者說明你給用戶造成了麻煩，需要優化）
留存率（次日、周、月-這個數值在你了解行業的前提下可調，和活躍一樣）：整個產品模塊和邏輯是否吸引用戶，癢點是否有效；
留存率分為刺激性和非刺激性（如果想深入知道這些理論，最原始的應該是斯金納的書）。
…常規數據的略過好不，最多你從熱力圖，點擊分布，點擊數據等，能看出在你框架下用戶最期望用的產品和用戶的疑難點，這玩意不難理解，多看看多將心比心下就好。
那么其實重要的是部分埋點數據，關鍵數據的埋點可以讓我們看到客戶的大致使用范圍，比如：
我想要看到客戶登陸后，是先進Saas協同，還是先去訂單中心查看下有沒有適合的訂單；
我想要看到客戶登陸后，點擊統計和設置的情況；
我想要看到客戶登陸后，點擊幫助和退出的情況；
我想要看到多少客戶只用saas；
我想要看到多少客戶只在意訂單和收入；
繼續細分，我想要看到客戶在哪個頁面退出率最高等…
這些都可以幫助我們找到客戶的需求點，同時還有一個~
按照客戶分級，單一客戶應用的潛在需求可能是你平臺上的其他需求，那么，做一個刺激性、單一流程性的活動是比較不錯的…
以上：你已經根據這些內容開始修改你的前端、完善你的產品、幫助系統；并且從中區分出了客戶主體，對客戶的掌控性開始建立…
額，我忘記說數據需求中，數據偶爾會說謊這個事兒了，不過這個不太難，電話反饋、有將反饋或者問卷調研什么的，如果愿意，直接出一個新產品模塊來看看是不是當初的問題引起的A/B版就好~
需求沒有真偽，只有你對需求的把握是否準確到位。對某種需求有需要的人群，是否是必要即時去開發新功能的。需求分先后，產品的完善是一步一步的，先解決大部分人群的需求，再慢慢去完善解決部分人的需求。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）