快速搞定B端需求,看這篇就夠了
編輯導語:在產品設計過程中,了解需求是產品落地的基礎之一,而在B端產品中,需求可能會涉及到業務需求、用戶需求及管理需求三個方面,具體該如何保障B端需求的快速洞察、快速實現呢?不妨看看作者的總結和梳理。
一、需求的定義
需求是產品存在的基礎,貫穿整個產品的整個生命周期。本文聊聊需求的管理方法論。需求管理方法論概念包含了,需求調研和挖掘、需求分析、需求管理(輸出需求文檔),也可以用一句話來說明,就是收集客戶想要什么,最終確定實際做什么。
本文會涉及到面試過程中問到的需求相關內容,可以先收藏后細品。
二、B端需求的分類
在我看來,B端需求主要分為業務需求、用戶需求和管理需求。
- 業務需求,就是B端行業的業務流程中產生的需求,業務流程是行業知識體系的一部分。
- 管理需求,在B端行業為實現業務目標而進行的決策、計劃、控制等的過程產生的需求。
- 用戶需求,用戶在系統使用過程中產生的其他需求。
在下文中會用這三類需求進行詳細說明。
三、需求的調研和挖掘,需求收集
1)調研的8大科學方法已經前面寫過,這邊介紹一下調研時的幾個小技巧。
① 用圖形作為調研助手
用圖形會引導大家的討論方向一致,收斂,不易跑題。圖形會引起參與者的視覺共鳴,從而加速、加深理解的程度。圖形的邏輯清晰,可以避免討論結果似是而非的現象,為后續需求變動提供證據(甩鍋)。
② 找到調研的合適顆粒度
對于顆粒度的把握,是沒有一個定數,但如果調研結束后,不需要再向客戶進行咨詢就可以進行設計工作了,那么這個調研就做到位了。第一次調研現場,顆粒度盡量越細越好,因為后續的調研會增加更多成本。
2)業務流程優化的一個方法-ESEIA方法ESEIA流程優化方法是由五個首字母組成,包括E(Eliminate)清除、S(Simplify)簡化、E(Establish)增加、I(Integrate)整合和A(Automate)自動化,用來減少流程中的非增值活動,增加流程中的增值活動,然后進行整合和自動化,如圖所示。
- E:清除,找出并清除不增值的活動;
- S:簡化,清除不必要的活動后,對必要的活動進行簡化;
- E:增加,根據需要增加增值的活動;
- I:整合,對簡化后的活動進行整合,使流程連貫;
- A:自動化,充分利用信息技術自動化功能,提高流程處理速度和質量。
案例:藍湖SaaS,是一款針對產品設計到開發階段的流程優化工具,從產品原型設計——原型上傳——UI設計師打開——根據原型設計——設計稿切圖——打包上傳——程序員下載——打開設計稿并查找相應切圖——開發時不定時查詢,一系列流程中找到可清除的不增值的活動,簡化相應活動,增加增值的活動(在線編輯和設計),整合后使流程連貫,數據上云,讓整個上傳下載自動化,提高流程處理速度和質量。
四、篩選,如何對需求的判斷
1. 擺正需求方的位置
需求的來源會有各種不同的渠道,有內部同事、領導、自己產生的需求。也有外部市場、用戶、競品分析、行業規范等產生的需求。我們需要先把他們產生的需求分類,擺正位置,才能對癥下藥。不管是哪個渠道來的需求,在上文有說到,可分為三類,業務需求、管理需求、用戶需求。業務需求和管理需求分別來自于業務流程優化和管理流程方面,如圖(房產營銷部分業務流程)。
1)業務需求,那需要從直接相關方和上下游的間接相關方來看,比如房產營銷中的客戶鎖定期和解鎖期,就會可能影響到銷售、財務、采購、管理者等各個相關方,需要每個相關方都接觸了解后才能設計。
2)管理需求,主要在上層管理的需求,一般只需要針對相關領導的需求就行,但需要知道需求方真實的需求,和該需求是否能夠實現。由于管理流程是附加于業務流程之上的,所以如果業務流程沒有能夠產生這個管理需求的能力,那就需要從業務流程中去重新審視這個管理需求的真實性和可行性。
3)用戶需求,這個就比較簡單了,主要就是使用習慣,交互等事宜??梢詮耐粚蛹壍闹苯酉嚓P方了解后進行分析。
2. 判斷真實的需求
1)方法一:邏輯演繹
當產品經理不清楚客戶的業務但又感到有問題時,可以用邏輯推演來判斷,通過邏輯推演可判斷客戶的需求是不是合理的、正確的。
例如:為什么需要做這個功能?缺少這個功能會如何?這個功能與其上游的工作流的關系,與下游的工作流的關系?思考新需求對現有業務邏輯的影響,會不會影響現有業務功能,當然也同樣要考慮到一些潛在的影響,這同樣是你對需求評估的一個重要標準。
2)多維度觀察
產品經理與客戶在專業知識方面是不對等的,客戶并不知道他提的需求將來在系統中會帶來什么后果,產品經理也未必聽懂了客戶的真實需求,因此對客戶提的“表面需求”要經過側面的判斷才能確定為“真實需求”。為了解決這個問題,可以參考使用5W1H分析法幫助做好判斷工作:
- 對象(what):什么事情。
- 場所(where):什么地點&場景。
- 時間(when):什么時候、順序。
- 人員(who):相關方、責任人。
- 為什么(why):原因。
- 方式(how):如何。
在需求調研中使用5W1H方法,首先要理解的是What、How,而作為判斷的重要依據的是Why,其他Where、When、Who是附屬信息,沒有經驗的產品經理只會從正面進行調研,即詢問“做什么”“怎么做”,但是最為重要的“為什么做(Why)”卻往往不問,這樣就會失去多維度觀察需求的機會,也同時失去了識別需求的虛實的機會。
3)價值判斷
對于復雜的、規模較大的需求,用簡單的、操作層面的能夠做評估的依據難以確定是否是真實的需求,可以用“目的、價值和功能”三要素來分析和判斷。目標,客戶的需求目標是什么?價值,確認該目標達成后,客戶可以獲得什么價值?功能,做什么功能可支持該價值的實現?
如果針對某個需求的判斷符合下述條件,那么它就可能不是真實的需求。
- 確定不了這個需求的目標是什么?
- 雖然知道目標,但是看不出目標達成后會給客戶帶來什么價值(回報)。
- 提出的功能需求實現后,并不能給客戶帶來預期的價值等。
五、搭建需求池&需求的優先級
從各個渠道來的需求,經過上述的分析后,可以放入到需求池中。需求池里的需求主要有:
- 真實的需求,還未進行過價值評估;
- 可能轉化為需求的一些思考、想法、靈感。也可能是從競品那分析所得。
過濾了一些偽需求,通過挖掘知道了用戶的真實目的,確定了需求方意愿度,明確了需求價值點,根據需求價值來提供解決方案,整理出了需求池,接下來就是對需求的優先級排序:
1)從需求分類的層級來排序,在B端產品中,因為業務需求是所有需求的底層,所有業務需求是第一位的,然后才是管理需求,最后才是用戶需求。這就是為什么很多B端產品不講究交互設計,而在業務流程上做了很大的投入。
2)可以從兩個緯度四個象限進行劃分,一個是緊急程度,一個是重要程度。按照優先級劃分為重要緊急、不重要緊急、重要不緊急、不重要不緊急。
如果產品在0-1階段,那根據KANO模型的基本型需求>期望型需求>興奮型需求來判斷,如果產品在1-N的迭代期,根據,產品價值大實現成本低>產品價值大實現成本高>產品價值小實現成本低>產品價值小實現成本高來判斷(圖來自網絡)。
六、需求文檔的輸出
功能需求整理輸出產品方案,做需求文檔輸出時,為了全面考慮產品方案的邏輯完整性和流程的完整性,可用以下三個點來自查自檢。
1. 功能觸發的前提
1)前置條件:觸發該流程的前提條件,如領取優惠券的前置條件為“注冊且登錄賬號”,甚至還有其他比如是否是新用戶等等。
2)數據來源:流程中數據來源,如審核功能中:審核人員審批下級發起的審核單。審核人員的操作流程中,下部發起審核產生審批單就是審核人員的操作流程中的數據來源;數據來源通常是在發生數據流轉的場景下需要進行說明。
3)角色及權限:即用戶在系統中承擔的作用的抽象,是否已經把功能抽象到權限中去,這樣可針對權限的設置來分配某些角色可以用,某些角色不可以用。
2. 操作流程
1)事件:主要是指功能的交互規則及邏輯判斷。
這個模塊用來說明用戶和系統之間發生的交互。交互規則是泛指的交互規則,包含功能的頁面布局、觸發功能的動作及觸發后的交互效果;邏輯判斷則是指當用戶在前端發生行為,系統對用戶行為進行識別、判斷并返回相應的動作的過程。
2)觸發反饋:指用戶與系統完成交互后,用戶和系統會得到什么樣的反饋及產生什么樣的數據和結果。
3)異常處理:是對主流程補充,我們盡可能全的羅列并寫清楚異常流程時,可以有效避免在產品設計時的場景遺漏。異常流程的梳理建議是參考測試同事的正反例原則。
3. 通用說明
1)數據埋點:埋點就不多進行贅述,但不管是采用第三方系統還是自己的埋點體系,都要做好數據分類,后續提取數據時能減少很多功夫。
2)數據需求:主要為業務方和產品經理在使用和運營提供決策依據,在設計產品方案時一定要規劃相對的監控數據指標,以便于后續運營和迭代時有數據進行支撐。
3)數據字典:不要出現這個數據在這是姓名,到另外一個頁面成為了用戶名這樣的事情。以上,是我對B端產品(項目)的理解,后續會對業務需求、管理需求、用戶需求分別分析一下。
本文由 @pm老潘 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unsplash,基于 CC0 協議
受益匪淺