聊聊我是如何評估產(chǎn)品優(yōu)先級的
在產(chǎn)品開發(fā)工作中,面多多重需求,產(chǎn)品經(jīng)理不知道先去做什么,該把什么需求放在前面,如此下來會造成工作多而混亂。作者結(jié)合相關(guān)案例,總結(jié)了如何評估產(chǎn)品工作優(yōu)先級的一些方法,希望對你有所幫助。
回想我第一次面試產(chǎn)品經(jīng)理職位時,被問到這個問題:
「你如何決定要開發(fā)什么功能?」
『如果不知道要開發(fā)什么功能的話,我會先了解客戶的需求,針對使用者做簡單的訪談,來決定接下來要開發(fā)什么功能?!?/p>
「嗯…你說的沒錯,但我們遇到的情況有點不同。我們每天從各種不同渠道,收到一堆來自客戶、使用者的反饋,希望我們盡快開發(fā)各式各樣的功能,同時客服、業(yè)務(wù)團隊也對產(chǎn)品功能有很多具體的想法,面對這樣的情況,你會怎么決定要先開發(fā)什么功能?」
面試當(dāng)時,我過往的經(jīng)驗比較項目導(dǎo)向,因此聽到這個問題時很直覺的反應(yīng)就是「不知道要做什么?問客戶、使用者、老板就對了!」秉持著來一個需求就做一個功能的心態(tài),F(xiàn)irst In, First Out!
但在開發(fā)自有產(chǎn)品的團隊內(nèi),事情卻復(fù)雜許多,問題在于有太多的需求,在持續(xù)優(yōu)化與產(chǎn)品迭代的過程中,資源有限欲望無窮時,排定優(yōu)先級成為非常重要的決策能力。
一、什么是優(yōu)先級
Prioritization,中文可以翻譯為優(yōu)先級、優(yōu)先序、優(yōu)先順序,亦即先做什么、后做什么,在互聯(lián)網(wǎng)產(chǎn)品領(lǐng)域中,即為決定先做A還是先做B、要優(yōu)化現(xiàn)有功能還是開發(fā)新功能等等。
排定優(yōu)先級背后隱含的意義,其實是「資源分配」與「機會成本」的概念,當(dāng)我把時間與工程資源花在A功能上,就無法同時花在B功能上。
在瀑布式(waterfall)開發(fā)流程中,產(chǎn)品經(jīng)理在早期就會跟相關(guān)部門討論好完整的功能,若分不同版本交付,就需要決定每個版本分別要開發(fā)哪些功能,也就是說在一開始就會定好產(chǎn)品開發(fā)的優(yōu)先順序。
而在敏捷式(agile)開發(fā)流程中,核心價值是快速產(chǎn)出、測試/學(xué)習(xí)、迭代/修正,因此會更頻繁與動態(tài)的調(diào)整優(yōu)先級,產(chǎn)品經(jīng)理要有根據(jù)實驗與回饋的成果來隨時調(diào)整優(yōu)先級的心理準(zhǔn)備,除此之外也難以避免緊急需求插入的產(chǎn)生,因此心里有一套排序優(yōu)先級的方法與邏輯是很重要的。
二、先排序問題,再排序解法
使用者、客戶、其他相關(guān)部門提出的反饋,以及用戶研究分析出的洞見,常常亂到不知道如何整理!其內(nèi)容可能包含現(xiàn)有功能優(yōu)化、新功能開發(fā)、 Bug,或是一個很大的問題(如何幫助我們吸引會員回來電商網(wǎng)站購物)等等,也就是說有些是明確的功能、有些則是模糊的問題。
在一些非常成熟的行業(yè)當(dāng)中,直接按照功能來分類需求、按照競品的樣子復(fù)制一個功能出去給使用者也許是沒問題的。
但在變動快速的行業(yè)中,了解使用者提出這個功能背后的問題、需求與使用場景,才能幫助我們想出更多的解法、更好地去服務(wù)使用者。
在缺乏使用場景的情況下,產(chǎn)品團隊很難滿足每個使用者的需求、也無法判斷該解決的核心問題是什么,因此多問使用者一個「為什么」總是不會錯,也能夠理清這是否一個值得解決的問題。
將使用者提出的功能反饋拆解成問題與需求后,可以先排定「問題」的優(yōu)先級,專注于我們想要解決的問題、能帶給公司的價值,而當(dāng)開始定義問題、想解決方案后,產(chǎn)出一堆功能的想法時再來排定「解法」的優(yōu)先級。排定優(yōu)先級這件事情,會不斷地在產(chǎn)品設(shè)計與開發(fā)的環(huán)節(jié)中發(fā)生。
三、三種常見的優(yōu)先級評估標(biāo)準(zhǔn)
1. 問題規(guī)模
溝通對象:用戶/客戶、業(yè)務(wù)、客服、社群、用戶研究員
對于「使用者中心」的產(chǎn)品設(shè)計團隊,從使用者需求出發(fā)來考慮排序的優(yōu)先級是常見的方法,問題規(guī)模可以包含:使用者針對該需求提出的數(shù)量與頻率、該問題影響到使用者數(shù)量、該問題發(fā)生的頻率/功能的使用頻率來判斷問題的規(guī)模有多大,以及是否值得優(yōu)先被處理。
2. 商業(yè)價值
溝通對象:業(yè)務(wù)、BD、商業(yè)相關(guān)部門、各種利益關(guān)系人
在很多公司中,會先處理商業(yè)價值最大的問題,可能是可以立即賺錢的、或是可以幫助團隊在未來打下更多市場的市場需求。
舉例來說 B2B 產(chǎn)品團隊接到與大型品牌客戶的合作、B2C 產(chǎn)品團隊與強大的第三方服務(wù)商合作,或是比競品更早推出新功能而有機會可以搶到更多客戶時,都有可能會將這類型的需求獨立拉出來提高優(yōu)先級。
商業(yè)價值也包含可以協(xié)助獲取新用戶、提高留存率、提高轉(zhuǎn)換率、提高營收等指標(biāo),保持與公司的目標(biāo)一致。
3. 資源考量
溝通對象:設(shè)計師、研發(fā)工程師、QA
資源考量常在排序解法時出現(xiàn),與技術(shù)團隊共同判斷技術(shù)可行性、所需資源、與其他功能之間的相依性,來決定現(xiàn)階段要用哪個解法來解決問題。
四、制定優(yōu)先級的策略
1. 團隊目標(biāo)
在有規(guī)模與制度的公司內(nèi),每年、每季都會制定公司的目標(biāo)與策略,例如營收成長、客戶成長、會員數(shù)成長、新市場拓展等等,而產(chǎn)品團隊也會因應(yīng)公司目標(biāo)而制定階段性的產(chǎn)品目標(biāo),產(chǎn)品目標(biāo)可以協(xié)助我做決策時定出不同的評估要點、權(quán)重并保持與商業(yè)目標(biāo)的一致性。
2. 風(fēng)險測試
在很早期的產(chǎn)品團隊,或是產(chǎn)品本身發(fā)展?jié)摿€很多元的時候,可以選擇將不確定性最高(亦即報酬很大但失敗性也可能最高)的功能推出去測試,先完成第一階段的最小可行性產(chǎn)品(MVP)來看看成效,從中學(xué)習(xí)并快速迭代,來快速取舍接下來的發(fā)展方向。
另外一個思考方式,則是先處理風(fēng)險低、信心程度高的問題,確保推出的解法是真正能夠解決現(xiàn)有使用者的問題,創(chuàng)造影響力。
但其實撇開風(fēng)險高低不說,早期花較少的資源透過小測試來快速得到反饋,每次收完反饋就重新調(diào)整優(yōu)先級,將反應(yīng)好的功能優(yōu)化也是一個很好的開發(fā)策略,對于資源的安排也會更有彈性。
五、排定優(yōu)先級的工作流程
在實際操作上并不會只參考一個方面,而是動態(tài)的考量不同因素來排定一個優(yōu)先級。有時候這些方法其實是互相沖突的,舉例來說商業(yè)價值最高的可能要花費的技術(shù)成本也最高,因此產(chǎn)品經(jīng)理最困難的工作就是找出平衡點并跟團隊一起討論出大家都認同的產(chǎn)品路線圖。
工作流程:
- 確立團隊目標(biāo)
- 收集使用者問題、商業(yè)問題
- 排序問題優(yōu)先級
- 依照資源多寡,選擇高優(yōu)先級的問題來進行使用者與市場研究
- 針對研究結(jié)果,制定不同的解法
- 排序解法優(yōu)先級
最后最重要的,是要跟內(nèi)外部團隊都充分討論與告知目前的優(yōu)先級,確保大家了解決策過程并且能夠安排相對應(yīng)的資源。以下分享兩個思考決策與解決問題的小案例:
六、案例解析
案例一:少數(shù)大客戶 v.s. 多數(shù)小客戶
以B2B產(chǎn)品為例,Key Accounts(KA)總是說話最大聲的人,但當(dāng)面對只有少數(shù)幾個 KA 提出某個問題,而大部分的小型客戶都沒提過,這個問題是否就不重要而應(yīng)該被排到比較低的優(yōu)先級呢?
這個問題困擾我的地方在于,不確定「問題規(guī)?!沟拇笮?。有鑒于使用者除了常常不知道自己要什么,幫助他們理清問題就是產(chǎn)品團隊的責(zé)任!
舉例來說,其中一位電商賣家 KA 每周上新品的數(shù)量達 100 件,因此要求優(yōu)化后臺大量新增、上架商品的功能。此時除了確認 KA 本身的使用情境與需求外(包含老板、小幫手等不同使用者),也可以透過市場研究、競品研究,并針對一般小型賣家發(fā)問卷、做訪談,了解他們目前的狀況:
– 如何上架商品、誰負責(zé)上架
– 是否曾經(jīng)有需要大量新增的需求、最大量是多少
– 上架商品過程中遇過哪些問題…等等
了解「未發(fā)聲」的中小型賣家是否也遭遇類似的問題,或是他們未來成長變大的過程中會不會遇到相同問題,來初步判斷這個問題是否值得優(yōu)先被排期。
案例二:目標(biāo)優(yōu)先級、問題優(yōu)先級、解法優(yōu)先級
有時候跟使用者聊得太開心,收集到一堆反饋,就會直接落到「該功能/需求被提出的次數(shù)」這個最直覺的方法來決定要優(yōu)先開發(fā)什么功能。
舉例來說,若設(shè)立的團隊目標(biāo)是幫助賣家提升顧客來到電商網(wǎng)站的轉(zhuǎn)化率,其中一個被放在高優(yōu)先級的問題是「許多顧客將商品加入購物車,但沒有完成結(jié)帳動作」,針對這個問題做使用者研究后,發(fā)現(xiàn)超多顧客提出的反饋是「我其實當(dāng)時還沒有要買,只是網(wǎng)站沒有那種可以收集我的最愛商品的地方,所以想說先放在購物車?yán)锩嬷舐簟埂?/p>
此時的團隊目標(biāo)是幫助賣家提升顧客來到電商網(wǎng)站的轉(zhuǎn)化率。也許顧客此時提出的功能看似需求量很高,但他反映的可能只是產(chǎn)品體驗的問題,比如通過收藏可以滿足?我們要分析的是,用戶從登錄、瀏覽、進入詳情頁、加入購物車、下單、付款的整個漏斗中,哪個環(huán)節(jié)流失最大,做針對性的優(yōu)化。
但同樣這個問題對于負責(zé)產(chǎn)品體驗的團隊來說,可能就是優(yōu)先級最高的事,因為你們的目標(biāo)不同,要提升的核心指標(biāo)不同。
七、綜合量化的排序架構(gòu)
在團隊眾多的產(chǎn)品公司里面,對于資源安排的方式更是斤斤計較,因此能夠用更有架構(gòu)的方式,甚至量化的數(shù)字來比較,會更有說服力。
分析一些我曾經(jīng)使用過的方法:
KANO:定義了三種不同層級的使用者需求 — — 基本型需求(Basic, Must-Be)、期望型需求(Performance)、興奮型需求(Excitement)
MoSCoW:定義了四種不同層級的使用者需求 — — 必須要有(Must Have)、應(yīng)該要有(Should Have)、能做(Could Have)、不能做(Won’t Have)
RICE:RICE score = (Reach*Impact*Confidence) / Effort
ICE:ICE score = Impact * Confidence * Ease
寫在最后
前面說了很多理想美好的排定優(yōu)先及方式,但產(chǎn)品線上發(fā)生的 BUG 永遠是第一優(yōu)先要處理的,因此在面對線上功能出問題的情況,也可以制定出一套處理流程和標(biāo)準(zhǔn)。
以電商產(chǎn)品舉例,與注冊、登入、購物車結(jié)帳、錢高度相關(guān)的地方出問題絕對是 P0等級,需要馬上被解決,這時候什么團隊目標(biāo)就放在一旁,先把最最核心的產(chǎn)品功能修好才是至關(guān)重要的。
1. 保持決策的一致性
優(yōu)先級會不斷的變動,高優(yōu)需求插入也難免會產(chǎn)生,有一套一致的邏輯與決策方式來說服設(shè)計與工程團隊內(nèi)部、以及與外部業(yè)務(wù)部門溝通,可以幫助產(chǎn)品經(jīng)理增進溝通效率。重點不只是方法,更是挑選這個排序方法背后的原因。
2. 從使用者反饋與測試中來調(diào)整優(yōu)先級
如同前面風(fēng)險測試提到的,將每次要驗證的問題切小,快速迭代和收集反饋來重新調(diào)整優(yōu)先級,對于資源的安排會更有彈性。
更重要的是,優(yōu)先級的重點不只在于順序,更在于資源的運用,如果能夠因此用市場反饋說服老板直接「增加資源」,很多事情似乎就更好解決了!
就聊這么多。
作者:駱齊;公眾號:產(chǎn)品經(jīng)理駱齊
本文由 @產(chǎn)品經(jīng)理駱齊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
- 目前還沒評論,等你發(fā)揮!