一文讀懂:硬件最小化可行產品(MVP)中的那些坑
在上一篇文章我對“產品系統設計”的思考中我提到最小化可行產品(MVP),有個朋友看完留言,讓我可以試一試講清楚“MVP有哪些坑?”回想起來,這幾年我一直從事硬件產品開發相關的產品管理工作,有面向企業的,也有直接面向消費者的,有的產品歷時一年多,短的可能幾個月。在這方面踩過的坑確實比較多,倒是有一些慘痛的經歷可以說一說。
一
我記得幾年前朋友介紹加入一家創業公司,不到十個人。團隊創始人都是技術出身,在行業內也都算小有名望,做的是一款面向公安、交管使用的硬件設備,客戶群以集成商為主。
當時那款產品業界能做出來的廠家也不多,國內大概五六家,如果在一個合適的時間能夠推出性價比不錯的硬件產品,以當地城市每年10000臺進行估算,只要能夠占據1/4的市場容量,那公司的銷售額和利潤都會取得一個不錯的結果。
為了走一個差異化的道路,我們當時選擇了一款非市場主流的sony芯片,這款芯片比主流的便宜,但性能表現不錯。于是我們在憧憬中快馬加鞭,幾個人5+2,白加黑地投入到產品開發中。
幾個月后,當我們滿懷信心地把產品交付出來后,市場給了我們狠狠的一擊。
我們和當地一個比較有代表性的集成商合作,給了他們一個非常有誘惑力的市場價格,但最關鍵的圖像清晰度指標(特別是晚上)卻無法滿足最終用戶的要求。雖然集成商肯定我們的技術能力,但經過幾次試驗和對比測試后,最終卻不得不更換了其他廠家的設備。
最小化可行產品(MVP),指的是快速地構建出符合產品預期功能的最小功能集合,這個最小集合所包含的功能足以滿足產品部署的要求并能夠檢驗有關客戶與產品交互的關鍵假設。該概念由埃里克·萊斯在其著作《精益創業》中提出,用最快、最簡明的方式建立一個可用的產品原型,這個原型要表達出你產品最終想要的效果,然后通過迭代來完善細節。
很不幸,我們當時的做法,幾乎犯了所有的錯。
首先,手頭上確實有一個值得解決的問題(集成商之前用的產品價格高也有一些問題),但最核心的是對于“符合產品預期功能”這一點走在了錯誤的道路上。產品對應的解決方案,并不能滿足最終用戶的要求。所以在這個階段,需要問自己三個問題:
- 你的解決方案是否是客戶想要的?(必要性)
- 他們是否愿意為你的解決方案掏錢?如果不愿意,那么誰來買單?(發展性)
- 你的解決方案是否能夠真正解決問題?(可行性)
Ash Maurya在他的《精益創業實戰》中,給我們提供了另外一種方法——精益畫布,一款制作迅速、內容緊湊、方便攜帶的工具,基本上可以解決前期的一些問題。如下所示:
其次,我們當時是有機會在半路調整方向的。
開發進行了兩個月左右,產品第一版(我們自己定義為MVP)出來后,在測試的過程中發現了夜晚清晰度問題(相比業界最較好的兩家公司產品)。
這個時間點,本來應該是我們拿著原型去客戶處進行假設驗證的絕佳時機,如果此時有幾個客戶的真實反饋數據,我們可能會推翻之前的假設,這會決定我們下一輪的行動方向。
但我們當時的做法沒有遵循這個原則,我們反而花了大量的時間去選擇周邊配套的補光設備,企圖通過算法優化、補光增強來達到效果,這再次讓我們在錯誤的方向上越行越遠。
雖然我們帶著強烈的信念,但硬件產品的字典中沒有“信念”二字,一切都必須通過科學方法的驗證。
二
從上面的例子可以看出,做產品過程中,我們無法完全避免犯局部的錯誤,但是若能從一開始就愿意并嘗試去探索甚至同時測試多種模式,總能增加找到更好方案的幾率。
這里面“探索”是關鍵,拋開那些極為困難的技術問題,其實只要有足夠的時間、資金和人力,做出個產品應該不是什么難事。怕只怕做出的東西根本沒人想要。
Steven Gary Blank博士在他的《四步創業法》中提到,“客戶探索”是用事實去檢驗設想,而檢驗假設都必須走出舒適的辦公環境,去到客戶中間,虛心了解他們的需求。這個過程的目標不是說服潛在的客戶接納你的想法和假設,而是設法了解客戶的真實意見,他們在使用類似產品過程中的痛點,然后如實地記錄下來即可。
三
2015年的時候,我負責公司的一款物聯網產品開發管理工作。那時候我已經讀了一些精益管理的文章和書籍,總想著通過快速迭代來打造一款有價值的產品,所以我制定了比較激進的產品發布策略。
我把過程分為三個階段,第一步是快速出一個原型機,第二步是增加我計劃中的幾個功能模塊,第三步是完善并兼容幾個物聯網平臺。
但是,第一階段就遇到了一些問題,我當時和開發人員一起選的MCU到程序設計時發現32KB的FLASH不太夠用了(可以滿足基本的功能),一旦程序滿負荷運轉,內存就比較吃緊。
當時的情況一是有項目在等著用這款產品,二是考慮沉沒成本,我們決定犧牲掉一部分功能來達到產品上線的目標。
這個案例也比較有代表性。
首先,肯定是前期的需求工作沒有做完整,產品的使用場景并沒有明確到極值。此款物聯網設備既可以單獨使用,也可以組成集群,在集群工作環境中,當設備容量達到一定規模時其程序處理復雜度上升較多,導致MCU的FLASH即將到達極限。
其次,最小化可行產品(MVP),有兩個形容詞,其一是“最小化”,另外一個關鍵詞是“可行”。而我犯了一個典型錯誤,將重點放在了“最小化”出產品,而忽視了“可行性”的部分。
舉一個例子:一款硬件產品,其MCU支持串口、網絡、USB等,如果沒有強制要求,可以先用最簡單的串口實現通訊,形成一個最小化可行產品去驗證數據傳輸以及功能,驗證了可行性后可以再慢慢完善底層網絡協議、USB驅動等。
四
做硬件產品開發,要求短時間內囊括需求、設計、測試、生產等步驟, 迭代不如軟件那么容易,所以硬件產品如果出了問題往往比較麻煩,改進的周期會比較長,這容易導致產品無法按時上市或者不得不忍受一些缺陷。
以上兩款硬件產品都有各自的問題,在復盤過程中,除了上面提到的外,還有一些需要注意的點。
典型問題一:硬件產品基本上遵循摩爾定律。
當價格不變時,集成電路上可容納的元器件的數目,約每隔18-24個月便會增加一倍,性能也將提升一倍。所以在設計方案的時候,需要對行業及產品的發展方向有一個預估,涉及核心芯片的選型留一些余量。
典型問題二:不要期待一次就把產品做到完美,但關鍵步驟不能少。
硬件產品一般建議走一輪樣機評審和測試,樣機評審的主要目是驗證一下設計的指標,同時在此階段盡早進行單元測試,看看關鍵性能指標是否滿足市場及客戶需求。
典型問題三:不要糾結于沉沒成本。
很多時候,我們已經投入這么多人力、物力和資金,因為不甘于這個投入,限制了我們做出下一步有效的決策,從而在錯誤的道路上越走越遠。最好的做法,仍然是以絕對的事實為基礎,充分調研和溝通,一旦發現設計指標無法滿足最終市場的要求,盡快調整方案或方向。
典型問題四:迭代的方向沒有遵循一致性。
常見的一種情況是,迭代過程中設計的兩代產品,其結構、構思完全不一樣,根本沒有傳承性,這相當于把所有的過程再來一遍。比較好的做法是,技術選型、硬件框架、結構設計盡量模塊化和標準化,在此基礎上的芯片升級、功能升級、程序代碼就可以復用,以減少重復勞動。
典型問題五:為了追求快速,所選器件來自非正規渠道。
經常有一些做法,從正規渠道購買某個器件周期太長,所以選擇從淘寶、阿里巴巴購買一些器件。
這種方式存在幾個風險,其一是器件可能是高仿,批次存在不一致性,你驗證的結論就存在不確定性;其二是存在不穩定性,這臺可以,下一臺就不行,導致投入過多精力去解決器件本身的問題;其三從知識版權來考慮,也應該購買正規的器件和物料。
目前,硬件物料有很多渠道和代理,前期成本可以稍微放松一些,除了原廠溝通外通過這些渠道和代理,一般也能找到合適的供貨方式。
五
當然,最小可行性產品(MVP)也有其局限性,比如在一些創新性產品中,其應用就受到一些限制。
類似于蘋果iPhone,其技術標準、工藝標準都是非常高的,和普通的原型機比較丑有天壤之別,而且直接引領市場。即使如小米手機、錘子手機,其迭代的也多是軟件系統(小米的MIUI是每周迭代,錘子Smartisan OS其迭代周期也比較快)。
在喬克·布蘇蒂爾的《產品經理方法論》這本書中有一個例子也說明了這個問題。
美國鞋類品牌REEBOK構思了一款新型的籃球鞋,做市場調研的時候反響平平,差點停止了新鞋的開發,但當一款早期“試驗款”運動鞋真正穿上時,籃球隊員們覺得鞋不但合腳且非???,最關鍵的是他們更自信而不必擔心會受傷。這款泵鞋后來取得了可觀的市場份額。
所以,看看你自己的產品領域,不用拘泥于惟一定式,MVP也只是為我們提供了一種思路和方式。
參考:
《精益創業》,埃里克·萊斯,中信出版社
《精益創業實戰》,Ash Maurya,圖靈文化發展有限公司
《四步創業法》,Steven Gary Blank,華中科技大學出版社
《產品經理方法論》,喬克·布蘇蒂爾,中信出版社
作者:qc精靈鼠,微信公眾號:鋒言冷語
本文由 @qc精靈鼠 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Pexels ,基于 CC0 協議
- 目前還沒評論,等你發揮!