產品思考:是否MVP要為試錯而生?
成功的理由只有一個:在合適的時間做對的事情。
越來越多的團隊開發最小可行性產品(Minimum Viable Product,簡寫MVP),快速推向市場試錯。不過在快速的同時,忽略了試錯的本質,最后淪為了快速開發的代名詞:
- 缺乏試錯目標,MVP的沒有上線標準,更有甚者推出MVP1.0,MVP2.0……
- 我們容易把MVP等同于粗糙的版本,有些重要的細節被忽略了;
- 把MVP推向市場后效果不佳,把問題歸結到這個“產品”做開發產品
- 的不夠好。
在精益思潮的影響下,越來越多的人拋棄早期調研,把產品盲目投放到市場中,期待理想中的答案。但是“期待”和“驗證”區別在于,驗證需要建立在明確的假設之上。期待則意味著你對結果是沒有預期的,投放到市場后,有可能意外的成功,但大多數情況下都會死的不明不白。
定義問題比解決問題更重要
不要用戰術的勤奮去掩蓋戰略的懶惰,是什么造成了我們戰略上的懶惰?主要的因素是“抽象性”。通常在團隊協作中,我們習慣把抽象的東西放到一邊,埋身于具體的戰術?!岸x問題”就屬于戰略層面,也是比較抽象的過程。不同背景的人看待問題的角度也不盡相同,更加深了定義問題的難度。
還有一種將虛榮指標作為團隊目標,例如“半年內實現盈利”,“日活200萬”這類KPI,把真正的問題掩蓋在了結果驅動的假相下。基于這類虛榮指標,不同職能部門往往專注于不同的戰術,戰術與戰術之間缺乏協同,有的時候還會出現前后矛盾的情況。那么“問題”和“指標”之間的區別在那里?什么樣的目標更具協同性?
- 指標是主觀視角,問題是客觀視角,對于產品或服務來說,客觀視角就是客戶視角。
- 戰略層的用戶問題并不是易用性一類問題,通常是指我們需要解決什么樣的用戶,什么情況下的痛點。
- 多花點時間去認識和定義問題,問題之間的差異甚至體現在用詞上。例如解決用戶“閑聊”和“商務咨詢”需求,都可以歸納為解決“溝通”需求。但如果把問題定義為“解決用戶的溝通需求”,意味著產品的邊界和微信一樣。
- 基于用戶問題去拆分職能KPI,例如目標要解決的問題是“提升協作效率”,那么市場部門的KPI就不是簡單的“XXX萬新增用戶”,而是“XX萬有效協作項目”。
來自DesignThinking的原型啟發
MVP的概念來自原型(Prototype),《精益創業》的作者EricRies有提到來自于設計思維(DesignThinking)的影響。1999年IDEO創始人大衛凱利接受ABC專訪,拍攝了的一期名為《the Deep Dive》的紀錄短片,短片中他和團隊一起花一周的時間創建了一個手推車原型,通過一周建造的原型,在基本能夠反映主要功能和創新之處的情況下,放置到真實的環境中測試真實的使用體驗,這也是另一種形式的MVP。
對于互聯網產品,我們驗證一個問題,并不意味著非要開發一款App或網站。把MVP鎖定為launch的第一個版本,是另一個常見的認知誤區?。試想Dropbox通過演示視頻獲得了種子用戶的經典案例,如果創始人在一開始將App直接呈現給用戶,除了需要花費更長的開發周期之外,恐怕得到的結果也是失真的。因為對于沒有文件同步這個概念的用戶來說,僅僅看到一個帶有同步標示的文件夾很難感知到最終的使用價值。
所以,我們要跳出軟件工程的視角,根據驗證的目標去選擇合適的MVP形態:
- 有價值的MVP直指運營層面的假設,例如“前100個種子用戶可以在CBD周邊獲取“?
- 有效的MVP是對使用價值的模擬,將使用者置身于足夠真實的環境,才能觸及用戶足夠真實的選擇;
- MVP的形態并不是單一的,有很多現成的工具和方法可以使用。Uxpin創始人ChristopherBank歸納了15種常見的MVP形態( 參考《mvp(最小化可行產品)驗證的15種方法》from?36氪?),例如眾籌,演示視頻,預售頁等,這些形式的特征是運營前置,觸及客戶的真實需求。
勘測和修建合二為一
GoogleVenture下的設計團隊是代表投資者利益的設計批判者,他們并不會為初創公司提供設計服務,而是通過一套名為《設計沖刺》的設計迭代,去檢驗初創項目的商業模式。在進入迭代前,他們會事先預約好真實的用戶,并承諾在5天內打造一款產品原型給他們進行測試。在高強度的壓力下,GV的設計師會從理解用戶開始到定義問題,通過低保真的原型傳達核心的產品形態。5天后向用戶展示可感知的“外觀”,檢驗真實的用戶需求。這個過程并沒有設計一款產品,而是通過設計的方式做了一次早期的用戶調研。
還有一個將調研和創建過程融合的案例是近年來風靡硅谷的黑客增長(Growth Hacking),原本隸屬于不同職能體系的市場人員,運營人員,工程師,設計師被融合到了一個增長團隊中。通過這樣跨職能的融合,打破了以往調研部門和研發部門之間的,可以讓團隊具備更多元化的視角和可能性,而任何的可能性都可以被”灰度”發布給用戶,進行反復的調研和優化。
10年前,我們寄望于調研來消除商業中的不確定性,就像修建高速公路,在真正動工之前需要做大量的勘測工作。而今天,唯有將勘測能力與修建能力合二為一,才能應對更為復雜多變的商業環境。何為合二為一,簡單來說就是顛倒勘測和修建的順序,以往勘測是為了修建,而如今修建是為了勘測。
總結
互聯網唯“快”不破的思想影響了一大批創業者,在某些特定的時間段,快的確能夠幫助我們追上某些時間窗口和紅利期,但“快”并不是成功的理由。成功的理由只有一個:在合適的時間做對的事情。相比不停的追趕時間,更為重要的是我們是否在”如何把事做對“這個問題上投入大量的思考??偨Y為一句話,MVP要為試錯而生。
本文由@點融設計中心 原創發布于人人都是產品經理。未經許可,禁止轉載。
- 目前還沒評論,等你發揮!