4、再談MVP，最小可用性產品
之前關於MVP的基本概念在前面一篇博客裏面已經提到了，本次課程學習正好又提到了關於MVP，那麼就總結一下如何在工作中使用MVP思想。
快速使用MVP的幾點原則:
- 提前推演邏輯，不要盲目驗證
- 驗證長板，而非短板
- 創造性的低成本方案
MVP的另一面
1.快速使用MVP的幾點原則
1.1提前推演邏輯，不要盲目驗證
在設計最小可用產品之前，一定要想清楚自己想驗證的問題，要收集哪些數據項，還有這些數據項可能出現的結果，以及不同結果代表的結論。
類似軟件工程中的 TDD（測試驅動開發），先把想要得到的結果列出來，再反推設計，以免設計邏輯不清楚，或者漏掉數據打點，反倒浪費了資源。
1.2驗證長板，而非短板
儘量裁掉短板，把資源放到長板上
儘量去關注核心的、差異化的體驗。
比如，12306 的第一版產品就是個 MVP，整個產品體驗爛到爆，但長板還是完全體現了：它有票。
現在這個時代，各種產品形態基本都被人想到了或者實施過了，我們要在市場上立住腳，靠的不是平均分更高，而是在單一維度上做到現有方案的十倍好。所以做 MVP 更重要的是驗證這個長板，而不是做一個不犯錯但平庸的嘗試。
1.3 創造性的低成本方案
在設計最小可用產品時，我們需要創造性地想出低成本的解決方案，來驗證最關鍵的命題。
1.3.1 用人工替代系統
其實大可不必準備得如此完備再上路，很多時候可以先用人力頂住測試一下。如果服務真的很靠譜，再快速迭代用系統化的能力去解決問題就來得及。
1.3.2利用第三方系統
如今的互聯網基礎建設比那時高了不知道多少，從 SaaS 到 PaaS，從雲服務到建站、電商、支付、小程序，於是，對我們來說，構建 MVP 的門檻越來越低，我們應當去儘可能地利用第三方的服務來快速驗證自己的想法。
1.3.3利用規則縮小場景
假設我們打算投入資源做智能客服機器人，現在想要驗證用戶是否能夠接受用與機器對話的方式來解決問題。在沒有任何自然語言理解算法和數據之前，我們可以通過縮小場景去簡化提供對話的實現難度。比如，我們可以設置條件，當用戶確認收貨三天之內打開訂單詳情頁面，則很有可能是要退貨，這時出現一個退貨諮詢的入口，點進來之後，進入機器客服的流程。這個流程可以僅具備解決退貨問題的能力，甚至用簡單的 QA 對就可以完成，對實現難度的要求就會降低不少。
2.MVP的另一面
MVP 並不是唯一正確的方法論，很多人對 MVP 和精益思想提出過不同意見。
有很多的產品模式是要求一定的體量和複雜度才能完成驗證的，MVP 最多隻能驗證其中個別環節上的假設是否成立，千萬不要把寶全部押到一個 MVP 上。尤其對於領域相對成熟的產品，產品體驗細節的疊加才能構成核心競爭力，而在 MVP 中可能很難將它構建出來。
3.總結
結合自己最近在做的一款產品是一款面向B端用戶的產品，好的一點是合理的應用了第三方系統快速開發我們的產品，不好的一點在於業務過於複雜，構建出來的MVP難以驗證，產品開發週期過長，嚴重與行業發展脫節。
推薦書籍：
1.精益創業
2.豐田生產方式