MVP模型實戰(zhàn):以導出功能為例
精益創(chuàng)業(yè)術語“最小可用產(chǎn)品”或MVP,這個詞匯我們常常聽到。筆者基于工作實踐,結合設計案例,推導了MVP模型的數(shù)據(jù)導出功能。
MVP模型是最小可行產(chǎn)品(Minimum Viabe Product)的簡稱,由Eric Ries在《精益創(chuàng)業(yè)實戰(zhàn)》中提出,指的是用最快、最簡明的方式建立一個可用的產(chǎn)品模型,推向市場,測試用戶是否喜歡這個產(chǎn)品,進而迭代完善細節(jié)。
功能背景
本人任職于一家CRM公司,負責的是BI產(chǎn)品線,本文舉例的導出需求是大客戶的需求。之前的導出能力只支持到了10000條,而大客戶的數(shù)據(jù)量普遍在10萬條以上,因此決定增加『大批量跨對象數(shù)據(jù)導出』的能力。
雖然客戶只提了把導出數(shù)量加上去,但是從產(chǎn)品角度出發(fā),這肯定是不夠的,長遠看,這必然得做成一個完整的功能。把功能一步做到位不現(xiàn)實,而且,客戶要求的實施交付期限也不允許。
這個時候,就需要有一個既能敏捷的滿足客戶需求,又可以滿足后期擴展的MVP方案。
開始設計一個MVP方案
1. 會議前
首先,先對系統(tǒng)現(xiàn)有的導出能力進行調(diào)研,明確我們的導出功能最終目標是做到什么程度;
然后,對當前正在實施的客戶進行調(diào)研,清楚知道客戶想要用導出實現(xiàn)什么,它的使用場景是什么;
最后,上面問題有結論之后,開始預訂日程、會議室,召集相關的同事進行討論,并準備便簽紙、筆、白板等。
2. 會議中
會上,首先確定一個主講人,先對背景、會議目的進行闡述。
然后,將調(diào)研結果分享給大家,目的是畫出用戶畫像,這個過程里,需要其他的人提問或者補充,以防漏掉一些信息,逐步完善用戶畫像。
這里的用戶畫像并不是標準意義上的,更多的目的是讓所有人了解什么樣的公司、什么樣的職位、什么樣的場景對該功能有需求
隨后,在用戶畫像完成之后,開始用便簽紙頭腦風暴,寫下『如果你是客戶,你想要用導出實現(xiàn)什么功能』,目的是發(fā)現(xiàn)客戶沒提但不排除以后提的點,這也是后續(xù)版本迭代的方案來源之一。
一張便簽紙只記錄一個觀點,便于后續(xù)的分類與整理。
之后,收集所有卡片,討論出『用戶使用導出功能必須經(jīng)歷的大步驟』,寫在白板上,并把所有卡片貼在相應的步驟下。然后,挨個卡片進行討論,選出哪些點是『如果不做,就沒辦法滿足客戶這版本的需求』,選出來的這些點就是MVP。
在對卡片進行分類的過程中,以下情況是正常的:
- 不是所有的卡片都有效。參會人員崗位不同,頭腦風暴的時候可能會帶一些各自的職業(yè)習慣,還有可能會有一些主觀性太強的想法,是否有效,需要斟酌;
- 不是所有卡片都能進行歸類。有些不屬于本功能承擔的能力等,也有可能出現(xiàn)在記錄的卡片上,需要判斷是步驟劃分不合理,還是卡片上的想法不合理。
3. 會議后
及時整理會議記錄,在電腦端上選一個軟件進行輸出,我用的是axure,這比紙上記錄更容易進行整理和分類,control+F不要太好用。還有一個目的是功能實現(xiàn)是分多個版本迭代的,哪些功能點在哪個版本實現(xiàn)了,軟件里記錄更容易。我在輸出的時候是模仿項目管理的那種卡片式記錄的,拖拽排列是很方便。
到此為止,產(chǎn)品設計階段的MVP方案基本確定了,剩下的就出原型、出視覺稿、技術評審……
前期的調(diào)研、收集反饋所耗費的時間都是碎片進行的,MVP方案的討論不到兩個半小時完成,然后半小時內(nèi)完成了原型……
總結這樣做的好處
- 加深對項目的理解。在無法面見客戶、了解客戶需求的時候,產(chǎn)品設計進行輸出時要么按客戶成功的反饋做,要么自我感覺良好,自嗨型輸出,最后的結果是要的你沒有,給的不想用;
- 節(jié)省溝通成本。在參與的過程中,會有各種各樣的問題拋出,然后得到回答、討論等,這比看PRD印象更深刻,也會大大節(jié)省溝通和信息傳遞所耗費的時間成本;
- 更多的成功參與感。推導MVP的過程可以讓一些非核心崗位的同事有更深的參與感,任何產(chǎn)品的成功都是團隊的成功,只有大家覺得這個產(chǎn)品值得我付出,并且一起努力了,才會有好的結果。
寫在最后
MVP方案確定了之后,在產(chǎn)品后續(xù)迭代的時候,只考慮會上討論出的功能點還是不夠的,還需要綜合產(chǎn)品、技術層面輸出一些內(nèi)容才能進行下一步的設計。
比如:會上無人提到編碼格式,但技術上有限制,這是用戶在填寫表單時必須填的。
最后說點小廢話,MVP是產(chǎn)品設計中非常好用的一個方法,但是如果你的團隊中有人對你的方案持懷疑態(tài)度的時候,不妨挑選一些業(yè)務邏輯沒那么復雜的需求,來進行一次MVP的推導,成本不大,還會有意向不到的效果,比如,信任感、認同感~~
本文由 @瓶子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉載。
題圖來自Unsplash,基于CC0協(xié)議。
請問在完成MVP版本后,是先小范圍的進行了一輪用戶測試進行方案的驗證;還是直接在MVP版本上進行豐富然后直接交付了呢?
PM學習重點
思維:提前思考,比顧客想的再遠一點,包括用戶需求的實現(xiàn)程度、應用場景、想要達到的目的
方法:MVP方法,一人牽頭,進行頭腦風暴,明晰用戶的需求;討論/判斷需求優(yōu)先級;確認MVP方案;畫原型,準備評審
其他:由于參會人員的復雜性,或許可以考慮提前出一個流程圖,讓大家再框架下發(fā)散思維,避免疏漏
感謝輸出,Thanks?(?ω?)?
?? ??
哈哈哈
此文,不明所以?
很有意義的方法