用戶需要不等于產(chǎn)品需求
編輯導(dǎo)讀:需要和需求雖然只是一字之差,但是狀態(tài)是完全不同的。通常情況下,用戶只會告訴我們他需要什么,而需求則是要將用戶所說和用戶所做相匹配,再去明確真正的需求。本文作者結(jié)合案例,對用戶需要和用戶需求這兩個概念展開了分析說明,與大家分享。
業(yè)務(wù)方總會從四面八方提出各種各樣的需求,多問一個為什么,或許能得到真實(shí)需求。
上個月一個例子:
業(yè)務(wù)方:能否在現(xiàn)在邀請中心的頁面增加一個入口,可以保留上一個月的頁面。
我:為什么要保留上一個月的頁面?
業(yè)務(wù)方:不然用戶等到8月份之后,怎么領(lǐng)取7月份的獎勵呢?
我:7月份的獎勵會在什么情況下,需要等到8月份才能領(lǐng)取呢?
業(yè)務(wù)方:就比如用戶邀請好友報(bào)名正式課,但是我們的規(guī)則是限定要消課滿一定數(shù)量才能獲得獎勵,所以就會出現(xiàn)這種情況。
我:那就應(yīng)該是有一個領(lǐng)取歷史獎勵的入口,查看哪些獎勵是還沒有領(lǐng)取過什么、領(lǐng)取過什么,對吧?
業(yè)務(wù)方:對的。
一、需要和需求
從上面那個例子可以發(fā)現(xiàn),需要和需求是兩種不同的狀態(tài)。通常情況下,用戶只會告訴我們他需要什么,而需求則是要將用戶所說和用戶所做相匹配,再去明確真正的需求是什么。
需要集中體現(xiàn)為用戶對于產(chǎn)品的不滿。不滿的原因有很多,通常是業(yè)務(wù)方覺得系統(tǒng)功能不能滿足他們的使用場景、不方便不高效;家長覺得APP功能相較其他產(chǎn)品不夠便捷,對比之下發(fā)現(xiàn)的不滿。需要大部分都是自我感知,所以總是會聽到“我覺得”、“我感覺”、“我認(rèn)為”等開頭語。
和需要不同,產(chǎn)品需求是針對一個具體的產(chǎn)品的具體行為下產(chǎn)生了可衡量的需要。需要是需求的前提,但是需求要將用戶行為來衡量,現(xiàn)有的資源和需求達(dá)到效果之間是否匹配。
之前做過一個關(guān)于批量綁定的功能。當(dāng)時聽到業(yè)務(wù)方說“一個一個綁定太麻煩了,為什么不出一個批量綁定的操作呢”,只是想到業(yè)務(wù)方需要這個,ta的感知就是覺得“誒重復(fù)操作好多,一個一個操作好浪費(fèi)時間”,所以就策劃了這個功能。
但是等到功能真正上線后,并沒有人去使用批量綁定。原因在于在綁定前,業(yè)務(wù)方都會仔細(xì)核對綁定信息,確保綁定正確,因此都會使用到單個綁定中的“查詢功能”,所以也就沒人去使用批量綁定功能了。
因此從這個功能后,凡是業(yè)務(wù)方提出的反饋,我會多問一個為什么:為什么現(xiàn)在的不行,、這個是用來做什么的,你一般會怎么用它,對現(xiàn)在工作有什么影響…
通過不斷追問用戶行為,獲得真實(shí)需求。
二、追問用戶行為,獲得真實(shí)需求
在開始成為產(chǎn)品經(jīng)理前,接觸過黃金圈法則。這個法則幫助我從用戶那里獲取到需求。從外到內(nèi)依次是what、how、why。
- what:是用戶告訴我的需要。通??梢詮娜粘=涣?、問卷收集、功能反饋中得到這些信息。
- how:是用戶對某個具體產(chǎn)品的具體行為。也就是從這里開始,可以去衡量這是否是用戶真實(shí)的需求。
- why:是用戶內(nèi)心真正的需求。用戶行為背后的原因。為什么使用這個產(chǎn)品而不用別的產(chǎn)品。
用上個月的一個“采購數(shù)據(jù)”例子說明 使用黃金圈法則來練習(xí)獲得需求的過程:
1. what
采購方希望將訂單管理頁面的班主任和CC信息刪除。原因是他們覺得這4列數(shù)據(jù)(包括2列團(tuán)隊(duì)數(shù)據(jù))都不怎么使用了,所以基本上可以去掉。
2. how
用戶說要把數(shù)據(jù)去掉,通常都會詢問為什么要這么做。這時候是了解用戶使用場景的“好時候”。
采購方說他們通常用這個頁面導(dǎo)出訂單安排發(fā)貨等事宜,所以只需要具備學(xué)員信息、收貨人信息等關(guān)鍵信息即可(他們認(rèn)為班主任信息是多余的)。當(dāng)用戶描述的行為和之前的功能相違背時,或許要更深入去求證。
繼續(xù)詢問后發(fā)現(xiàn),班主任信息是在少部分家長因發(fā)貨時遇到地址錯誤或收貨信息不匹配等情況才需要去找對應(yīng)班主任,聯(lián)系家長確認(rèn)才會使用到這些信息。但是現(xiàn)在采購不負(fù)責(zé)這一塊了,加上之前采購都會導(dǎo)出Excel表交給對應(yīng)負(fù)責(zé)人溝通,因此采購方覺得這項(xiàng)可以去掉。
3. why
溝通下來之后發(fā)現(xiàn),采購方感知到“去掉這4列信息”的原因在于自己不對接這塊了+使用頻率變少了。但其實(shí)班主任信息是必要但不是主要。
因此真正的需求占頁面篇幅需減少并置后,才能夠讓采購一打開頁面就能在列表最主要位置看到想要的信息。
4. 方案
畫好原型輸出方案后,可以詢問需求方對方案的意見,這樣可以更好確認(rèn)方案是不是符合需求方的使用場景。
三、告訴開發(fā)這是真實(shí)需求
在明確了業(yè)務(wù)方的真實(shí)需求后,同樣也是需要告訴開發(fā)的。對于目前接觸到C端產(chǎn)品來說,特別是做用戶增長,開發(fā)和測試不僅僅是研發(fā)技術(shù)人員,更是需要他們?nèi)チ私猱a(chǎn)品為什么做,怎么來的這個需求。
所以在寫需求文檔的第一步,要明確告知開發(fā)需求的背景、用戶場景、需求分析、競品調(diào)研。
- 背景:說明現(xiàn)在的問題是什么,現(xiàn)狀與用戶使用之間產(chǎn)生了什么(矛盾),會帶來什么影響。因此需要開發(fā)什么需求,達(dá)到什么目標(biāo)(盡量是具體的數(shù)值)
- 用戶場景:描述在什么時候,什么人做什么事,達(dá)到了什么結(jié)果/產(chǎn)生了什么影響。這一部分也是在給產(chǎn)品開始寫需求文檔前的一次準(zhǔn)備:這個需求的方案是否真的符合用戶在這類場景的訴求
- 需求分析:是怎么發(fā)現(xiàn)這個需求的(角色提出、競品參考、場景經(jīng)歷…)
- 競品調(diào)研:針對需求方案,尋找競品或者非競品中能滿足同樣場景的功能參考。一來是可以看看別人的設(shè)計(jì)交互,能夠結(jié)合到自身產(chǎn)品使用;二來也是能幫助自己判斷這個需求的真?zhèn)涡浴?/li>
業(yè)務(wù)方每天都會將自己對產(chǎn)品的使用體驗(yàn)、家長反饋告訴我們,在接收到反饋的同時,需要從中提取需求、規(guī)整需求,多一步思考、多問用戶行為。
本文由 @莫琳 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
- 目前還沒評論,等你發(fā)揮!