怎么利用抽象和具象做后臺產品-業務需求篇
在大部分后臺產品工作中,我們都可以結合“抽象”和“具象”的思維方式或工具來達成需求提煉和實現。這篇文章里,作者便討論了怎么通過抽象具象來做業務需求,一起來看看吧。
一、抽象和具象的定義
引自百科https://baike.baidu.com/item/%E6%8A%BD%E8%B1%A1/9021828
抽象是從眾多的事物中抽取出共同的、本質性的特征,而舍棄其非本質的特征的過程。具體地說,抽象就是人們在實踐的基礎上,對于豐富的感性素材通過去粗取精、去偽存真、由此及彼、由表及里的加工制作,形成概念、判斷、推理等思維形式,以反映事物的本質和規律的方法。
實際上,抽象是與具體相對應的概念,具體是事物的多種屬性的總和,因而抽象亦可理解為由具體事物的多種屬性中舍棄了若干屬性而固定了另一些屬性的思維活動。
抽象和具象,是產品工作中達成需求提煉和實現的無往不利的工具,能夠運用在大部分后臺產品工作中。
產品工作的抽象和具象過程包括兩步:一、業務需求的抽象和具象;二、產品化的抽象和具象。前者決定了我們對于業務理解的透徹度;后者決定了我們實現方案的好壞。本文主要討論怎么通過抽象具象來做業務需求。
二、利用抽象理解需求本質
產品前輩們提出了KANO模型、馬斯洛、5W2H等方法做需求理解和分析。這些需求方法本質上就是抽象的過程和結果,達成對需求的理解。學會抽象,一招抵多招。
1. 抽象用戶群體
抽象用戶群體大致分為:用戶標簽化和群體分類、特定業務的群體提取。
1)用戶標簽化和群體分類
用戶標簽化和群體分類是一個通用性工作。在我們接手一塊業務時,就需要有意識的建立用戶畫像,在工作開展過程中逐步加深用戶理解并完善畫像。ps:這里的用戶畫像不是說搭建一套用戶畫像系統,只是簡單的用戶畫像建立,可以是你心中有數;也可以是沉淀為你的文檔資料庫。這也是地基性工作,會很大程度上提高我們承接需求的處理效率。
第一步:用戶畫像初步建立,從業務模式找用戶群體。
首先,對用戶分類。舉兩個簡單的例子:
例1:電商提供撮合商家和消費者的平臺。從交易達成角度,用戶分類包括商家、消費者。從業務流程角度,為了達成支付功能,衍生出對應群體是支付服務商;為了商品端到端的送達,衍生出物流服務商群體。從運營管理角度,有運營、客服、數據、管理層…而事實上,基于電商業務可以繼續衍生出倉管需求、推廣需求、商家的供應,而后衍生出更多用戶群體。
例2:快遞撮合收寄方,提供配送服務。從交易達成角度,用戶分類為收件方、寄件方。從業務流程角度,為了收件、送達,衍生出末端網點和快遞員;為了實現物品跨區域運轉,衍生出車隊、分撥。
其次,設定用戶標簽。
以快遞的寄件方舉例子,由于寄件需求不同,衍生寄件方的標簽,從規??梢苑郑捍笊碳?、小商家、個人..;從配送速度和品質的訴求上可以分:普通時效、普通時效、貴重物、生鮮件等。
第二步:用戶畫像的迭代。通過你對業務加深,校正群體分類和標簽;在業務不同階段,用戶畫像也需要不斷迭代。
2)特定用戶群體的提取
在開展具體業務需求的用戶定位時,其實就是從用戶群體庫中,抽取當下業務場景的客群。當用戶向你提需求時,如果你不了解你所負責產品的用戶畫像或者判斷錯用戶群體,你很容易偏離本質。
需要明確定義:需求提出方 ≠ 產品使用者,產品使用者 ≠ 目標用戶。
1. 需求提出方 ≠ 產品使用者:管理者提出做一套oa系統管理員工。需求提出方=管理者,產品使用方=員工。
2. 產品使用者 ≠ 目標用戶:運營人員通過優惠券活動管理實現配置化活動運營。產品使用者=運營,目標用戶=參加活動的客戶。
后臺產品常常有個現象是,業務部門的下屬員工在上級要求的基礎上給我們提需求,或者下級提需求約束下級員工的使用行為。千萬不要進入直覺誤區,我們需要抽取需求提出方是在為誰提出需求,希望誰來使用,誰真正使用。
2. 抽象問題
后臺產品多著重于降本增效,存在實際的業務場景。因此需求理解分析,著重在抽象問題。抽象問題決定你挖掘需求的側重點以及優先級。
抽象問題是向上提煉的過程,通??梢愿爬椋?/p>
1. 做這個事情是為了解決/預防什么問題?業務方表達的需求可能和他背后的目的存在失調。抽象問題的過程是去偽存真的過程。
2. 這個問題產生的原因是什么?解決問題表象是一種糾正型方案。進一步抽象原因,解決原因,是預防性方案,我認為是更推薦產品經理們給出的方案。
舉個例子,我遇到過業務向我提出”對于一個自動化流程中間增加人工審核節點”需求。這是一個很典型既存在認知失調,又是一個糾正型方案的案例。
1. 業務做這個事情是為了解決/預防什么問題?通過調研,我了解到提出這個需求的背景是,大批量分公司向他反饋現有某自動獎懲機制薅羊毛行為損害他們利益,他們希望能夠停用這個機制或者支持申訴審核,所以業務向研發團隊提出增加人工審核流中斷獎懲的發放。從這里可以得出結論,業務核心訴求是為了避免薅羊毛行為,平撫分公司不滿。
2. 那么這個問題產生的原因是什么?進一步剖析薅羊毛行為的產生原因是什么?其一,利益點驅動薅羊毛。其二,活動判定獎勵規則存在漏洞導致薅羊毛。
如果采取業務提出的增加人工審核節點方案,存在幾個缺點:
- 開發審核流配套頁面功能,研發周期長。
- 業務既沒有想好怎么做審核,而且還有投入當前本就稀缺的審核人力做更多審核。那么也就意味著人工審核方案并不一定能夠安撫分公司,也不一定能夠人工判斷出薅羊毛的訂單,所以這是一個認知失調點。
- 也是更重要的一點,增加人工審核節點違背了當初獎懲活動的出發點,可能導致這個活動本身的失效。
再結合抽象出來的問題原因,相對于后置性解決風險的方案,我們還可以考慮通過前置性預防方案,通過完善獎懲規則來解決問題。最終我們通過增加1個規則,半天上線這個迭代,解決了90%以上的薅羊毛行為。
三、利用具象做需求驗證和場景補充
從現狀做抽象,是對特例做總結的過程;再從抽象回歸具象,是對總結通用性驗證過程。
需知,我們做產品時對口業務水平是參差的,他們對自己業務了解深淺是不同的;需知,人的考慮視角是有限的,我們抽象問題時會陷入思維繭房。所以從抽象回歸具象,是驗證需求的理解;基于抽象,延伸更多具象,可以補足可能場景。這是一個查漏補缺的步驟,也是設計出可拓展性產品方案的重要基石。
比如我們從制定指標規則來看怎么回歸具象反哺規則制定。物流有個常用考核指標“攬件及時率”,顧名思義即在約定時間內及時完成攬件的訂單占比,通過考核攬件及時率要求站點的攬件履約時效。為了更好達成對站點的考核要求,一般設定率值計算規則時,我們通常回歸具象,就是去窮盡攬件場景,找到非站點原因導致履約不及時訂單場景進行降噪。
回歸具象,最常用手段就是不斷推導業務流程下衍生的場景,構造樹一樣不斷建設既定會發生或假定會發生場景。我認為能夠覆蓋到大部分分支場景就能進入到產品化步驟。這種方式既可以用在0-1需求上,也可以用在1-n功能優化。
另一種回歸具象的手段是數據驗證,建立評價指標抽取過往數據分析驗證。這種方式對于小公司的后臺產品可適用場景較少,更多適用在后臺用戶較多、角色比較復雜,流程性功能或數據型功能優化上。
本文由 @我愛芋兒雞 原創發布于人人都是產品經理。未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!