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

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

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

圖一

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

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

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

一、構(gòu)想

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

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

關(guān)于假設，我們又該怎么做呢？

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

我們可以這樣提出假設，比如我們?yōu)橛凶⒁饬Σ患小⒖偸遣荒馨磿r完成作業(yè)的學生開發(fā)一款帶有獎勵與懲罰機制的作業(yè)日程表，可以讓學生每天都能按時完成作業(yè)，通過觀察目標人群是否提高了每天完成的作業(yè)量來驗證。

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

二、打造

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

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

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

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

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

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

圖二

三、測試

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

圖三

在測試階段，我們已經(jīng)有了一個最小可行產(chǎn)品。我們應該：

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

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

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

四、迭代

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

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

作者：米小可，公眾號：產(chǎn)品萌新米小可

本文由 @米小可 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。