怎樣在已經足夠精簡的設計流程中盡量降低產品風險呢？文章將會為你解析。

在創業公司中，在開發一個產品前往往并沒有充裕的時間和人力做商業價值分析和市場分析。小的創業團隊需要快速的開發，讓用戶使用產品并驗證產品是否是用戶想要的。但這并不意味著，腦袋里靈光一閃的“絕妙的點子”就要立馬投入開發。怎樣在已經足夠精簡的設計流程中盡量降低產品風險呢？

簡單的來看一下精益產品設計的流程，下圖是Henrik Kniberg在《How?Spotify?builds?products》文章中的一個圖表。

圖一

上圖，藍色曲線代表運作成本；紅色曲線代表產品風險。

橫坐標把產品設計流程分成4個階段。借用網易云課堂中“精益產品設計”中的思想，我們可以把它翻譯為構想、打造、測試、迭代。

這個圖表在下文中我會多次提到，由于作者在文獻中并沒有對它特別命名，我們先簡單的先命名它為“產品風險與成本圖”方便指代。接下來我們逐個階段來看，如何能降低產品風險。

一、構想

通過產品風險與成本圖，我們可以看到，在構想階段的運作成本較低，在這一階段一般只需要產品和設計動動腦筋，在此期間進行初步假設和推敲是可以降低產品風險的。但假如在這個階段馬上投入設計和開發，相當于把產品推向一個高風險高成本的狀態中。

硅谷創業家Eric Rise在《精益創業》中提出了“精益創業”（Lean Startup）和最小化可行產品（Minimum Viable Product, MVP）的概念，許多產品經理對這些概念的理解容易沉浸在“精益”和“最小”中。而在本書的前言，作者對本書內容的概括介紹“你會了解從一個極需嚴格檢測的大膽假設開始，到如何開發最小化可行產品來驗證這些假設”，本書也專門有一節叫“概念基于假設”。我們應該把更多的目光投向假設和檢驗。

關于假設，我們又該怎么做呢？

• 定義產品，并想清楚這個產品解決什么問題；
• 提出假設。你的目標人群通過使用你的產品功能，達成了一個怎樣的結果；
• 驗證假設。跟用戶充分溝通；建立用戶畫像（Persona），描繪具體場景（Scenario），找出痛點（Pain），把以上三個要點代入到你的解決方案（Solution），是否能夠滿足用戶需求。即PSPS模型（從網易課堂接觸到，作者沒有查到有關此模型的其他確切來源）。

我們可以這樣提出假設，比如我們為有注意力不集中、總是不能按時完成作業的學生開發一款帶有獎勵與懲罰機制的作業日程表，可以讓學生每天都能按時完成作業，通過觀察目標人群是否提高了每天完成的作業量來驗證。

而驗證假設，我們需要YY自己是那個注意力不集中的學生，在晚上開著小臺燈做作業一邊看電視劇，通過使用帶有某種獎勵和懲罰機制的應用，關掉了電視劇一心一意做作業并完成了當天的作業。

二、打造

在打造階段，我們需要打造出一個MVP，那什么是MVP呢？

MVP是Eric Rise在《精益創業》提出的一個概念，“精益創業”的核心思想是“開發-測量-認知”（Build – Measure – Learn），先做出一個最小可行產品MVP（Minimum Viable Product, MVP），發放給用戶測試并收集用戶的反饋，然后快速迭代，不斷改進產品，最終適應市場需求。

在這里需要注意的是，許多產品經理過于關注“最?。∕inimum）”而忽略了“可用性（Viable）”，這是很可怕的。一來最小可行產品對用戶而言是需要有他的核心價值的，二來最基本的功能也是用戶能使用通暢的。

在產品與風險圖中，我們看到在打造階段，運作成本是非常高的，而產品風險在這一階段線條平穩，也沒有降低的可能。我們當然要想方設法的去縮短打造階段所需要的時間。由于有了構想階段“產品定義-提出假設-驗證假設”的準備，這一階段只要盡快去打造MVP就可以了。

我們見到很多產品經理喜歡隨意改需求，在構想階段沒想清楚、打造階段繼續想，隨時要設計師和開發改并稱“改需求是常態”?？蛇@么做會拉長打造階段的時間，占用設計和開發的資源，也增加了不少溝通成本。往往導致設計反復修改，開發也不能按時完成任務，產品經理自己也會在反反復復修改的過程中影響最小可用產品的“可用性”。那什么時候可以改？如何有依據的跟設計和開發溝通？在測試階段我會提到。

關于“可用性”，相信了解MVP產品經理應該都聽說過“輪子、自行車、摩托車”的例子。下圖中，MVP是一輛自行車，摩托車是自行車的升級版，完整但成本較高，而輪子是簡化到根本不可用的。而某些產品經理在對摩托車的矯枉過正中把自行車打造成了一個輪子，欺騙自己“這是一輛自行車”并用這個輪子進行下一階段的測試，然后告訴整個團隊自行車是不行的。

圖二

三、測試

我在打造階段留下的問題在這里說明，“那什么時候可以改改改呢？”能讓設計和開發信服的改動至少也應該是有依據的，而不是腦袋里隨意想想就要設計改十幾個版本。產品經理應通過用戶反饋和數據來優雅的跟設計和開發溝通。

圖三

在測試階段，我們已經有了一個最小可行產品。我們應該：

• 把這個產品發布給少數用戶，觀察用戶反饋，查看用戶數據；
• 通過反饋和數據進行分析改進，再判斷這個產品是否能夠符合市場需求，能否擴大測試用戶規模；
• 如果可以，擴大測試用戶規模，并重復以上步驟，觀察用戶反饋和數據并不斷改進，然后擴大用戶規模；如果不可以則繼續優化產品；
• 通過以上步驟不斷擴大測試用戶的規模，完善產品。

如果過程中存在設計難以解決或比較猶豫的問題，針對這些功能對用戶進行A/B test。

注意：在前期的階段，驗證功能符合市場需求后，需要繼續對核心功能進行優化。這一點往往容易被忽略。隨著擴大用戶測試規模，核心功能會遇到各種各樣的挑戰。比如做一個IM軟件，你的軟件在現在這個時代還不能發短視頻，又或者加好友功能可用，但模糊搜索非常糟糕。此時去做一個自定義個人資料皮膚的功能就是非常不理智的。需要產品經理判斷好各種需求的開發時機。

四、迭代

基于之前構想，打造、測試的三個階段，我們證實了這個產品是符合市場需求的。接下來就可以再一次的通過構想、打造、測試的方法對產品進行優化并開發新的功能了。

注：圖1，圖2，圖3來源于Henrik Kniberg的《How?Spotify?builds?products》

作者：米小可，公眾號：產品萌新米小可

本文由 @米小可 原創發布于人人都是產品經理。未經許可，禁止轉載。