上班能免費聽歌好開心，原來Spotify 是這樣設計產品的！

產品開發並不簡單。事實上，大多數產品開發努力到最後都失敗了，並且最常見的失敗原因就是開發了錯誤的產品。

 

Spotify 是一個瑞典的精實創業專案，它同時保持著一個很棒的產品交付記錄。他們的產品廣為使用者和藝術家喜愛，並且像病毒一樣傳播開來：他們有超過 2000 萬活躍使用者，500 萬付費使用者，並且使用者數量增速迅猛。舉一組數字說明問題，Spotify 在美國這樣一個已經充斥著不少音樂軟體提供商的海外市場，只用了 1 年時間，就把付費使用者數從 0 上升至 100 萬。

 

Spotify 的願景是在任何時候給你帶來對的音樂。這意味著它將無限地接入全世界的音樂，並且在 Spotify 中分享音樂會十分容易；並且音樂被分享和播放得越多，那麼音樂的創作藝術家們就可以獲得越多的錢。幾年前，Spotify 以一個音樂播放器的身份誕生，如今，他們的產品演變成一個發現新音樂和在藝術家和粉絲間建立直連的廣大平台。

 

這個產品的設計理念是簡單、個性、有趣。甚至連 Metallica（美國樂隊名），這支長期以來被認為是音樂串流服務的死對頭的樂隊，現在都稱 Spotify 是「目前最好的串流服務」並且「被它的方便所震驚。」

 

但仍舊存在一個悖論：就是像 Spotify 這樣成功的公司當然只希望產出人們喜愛的產品，但是只有在產品上線之後，他們才知道人們到底喜不喜歡這個產品。那麼他們是怎麼做的呢？這篇文章的目的就是給 Spotify 的產品開發方法做一個高度的概括總結。

 

概要

我們的核心理念是：

• 我們創造革命性的產品，同時通過早期低成本的原型設計來控制風險。
• 我們直到品質過關才會發表產品，即便已經錯過了發表日期。
• 我們通過產品發表後虐心地一次次 tweak（可理解為「調整優化」）產品，來確保我們的產品從發表起就表現優異，並且到後來驚艷得令人稱奇。

 

所有主要的產品計劃都經歷 4 個階段——「Think It（思考）」，「Build It（構建）」，「Ship It（發表）」，「Tweak It（優化）」。下方為一個關於從產生靈感到形成產品的整個流程，以及過程中的各個階段會產出什麼成品的圖示。

 

 

• Think It（思考）= 整明白我們在打造何種產品，為什麼。
• Build It（構建）= 開發出最小可行性產品 (MVP)
• Ship It（發表）= 將產品向全部使用者逐步慢慢鋪開，同時進行數據檢測並不斷改善。
• Tweak It（優化）= 持續不斷地提升產品。這是產品的最終狀態，產品不斷優化直到生命週期終止或產品重構（= 回到 Think It）。

 

Spotify 擁有超過 30 個 Squads（可理解為「小分隊」，下同）和許多不同的產品，為了讓公司的其他人都了解公司正在發生什麼，我們用一種產品狀態圖來表示每個產品分別處於哪個階段。大致如下：

 

我們同時也面向一些 Squad 試行預測機制，這些 Squad 對產品何時將會到達下一個階段有一個日期時間上的預期，並對提供的這個階段晉級日期範圍（日期 X- 日期 Y）負責。

 

為什麼是這 4 個階段？

 

構建一個錯誤的產品是最具風險的事情–錯誤的產品無法取悅我們的使用者，同時無法提升使用者數以及使用者留存等好的指標。我們稱這個後果為「product risk（產品風險）」。

 

這個 4 階模型幫助我們壓低風險，並且快速做出產品。下面這個圖表可以看出在每個階段產品風險是如何被降低的，同時可以看到每個階段是如何地成本密集。

 

 

我們可以看到，Think It 這個階段可以以很低的成本降低風險。同時我們也看到我們為什麼要盡可能縮短 Build It 這個階段（因為它消耗很高的運作成本卻幾乎無法帶來風險的降低）。而在 Tweak It 階段逐漸降低的運作成本表明，隨著時間推移，產品並不需要進行盡可能多的更新，Squad 們可以開始繼續去做其他事情。

 

每個階段的周期變化多端，上面的這個比例只是一個例子而已。總的時間同樣也是會變的；有些產品從孵化到產出也就是幾個月的事情，而另一些產品可能要花去大半年甚至更多的時間。但是在每個階段裡，產出（即便只是內部的）都是在一個可持續性的基礎上完成的。好，現在我們仔細來研究一下每一個階段。

 

Think It

 

產品靈感在任何時間，在公司的任何人身上都可能誕生出來。大部分靈感都是去提升現有的產品（也就是「tweaks」），這種情況 Squad 們只需自己實施和發表即可。

 

這裡說的「Think It」階段指的是某人想出了一個全新的產品創意，或者說去重構一個現有產品。

 

如果管理者也認為這個想法是值得付諸實踐的，那麼一個小型的「Think It」Squad 隨即成立。典型的「Think It」Squad 一般包括一個開發者，一個設計師和一個產品經理。他們的工作就是去完善產品描述，同時構建一個足夠吸引人的產品原型。

 

產品描述通常是一個用來回答如下問題的一個簡短的文件：

• 我們為什麼要去構建他？誰會從中受益，如何受益？
• 我們期望這個產品去提升哪些關鍵指標？這些指標可能關於播放了多少串流音樂，下載量有多少，註冊量有多少等等。
• 我們的預期是怎樣的？我們如何去判斷這個產品是否成功？
• 產品會帶來「階段性的改變」（階段性改變指的是，在預期中這個產品將帶來至少雙倍的既選指標上的提升）嗎？如果在我們的期望中，這個產品只是較小地提高了指標，那麼要去構建它，最好有更強有力的理由，比如一些戰略方面的原因等。

 

產品描述不是必備的文件，也不是所謂的專案計劃。它不包括特性清單、預算、資源計劃等等。它更像是一個用數據說話（數據驅動）的意願陳述。

 

產品描述中最重要的部分就是故事性描述。我們要向世界講什麼故事？新聞稿又是什麼樣的呢？

 

舉個例子，Spotify 的「Discover（發現）」標籤是最近的一個產品。介紹一種發現音樂的更好方式。看！你最喜愛的藝術家剛剛分享了一首歌給你。我們讓藝術家們和粉絲們從未如此靠近過。喜歡一個藝術家？那就去 follow（關注）他，並與朋友們分享你的新發現吧。

 

另一個例子是有「Radio you can save（你可以保存的電台）」說法的免費行動電台。這種情況下，我們會用 Google 的關鍵詞廣告去嘗試幾種不同的描述，看看哪種描述最吸引人。

 

關鍵在於，這個故事性描述在產品構建前就寫好了！這樣我們可以在產品構建前就確定這個產品足夠吸引人。

 

另外，「Think It」Squad 會構建許多不同的原型來傳遞產品的感官上的體驗–同時會有「低保真」的紙面原型和「高保真」的可運行的原型（上面跑偽數據源之類）。這時幾個內部焦點小組會用來辨別哪一個原型最好地傳達了它的產品精神（那個故事性描述），直到我們不斷縮小範圍，最後只剩下幾個勝出的原型。

這是一個沒有截止日期的迭代（iteration）過程。只有當我們可以拿出一個足以吸引人的故事性描述和能夠傳達出它的可運行的原型，這個產品才是值得去構建的。我們無法決定這個產品前期會花去多少時間。

 

完成的定義：Think It 階段直到管理者和 Squad 共同認同這個產品是值得構建的（或者這個產品永遠都不值得構建，故應該被捨棄）則標誌完成。

 

這是一個主觀上的決定，它並沒有實質數據作支撐。Ship It 階段才會產生實質數據，所以我們希望盡可能快地到達 Ship It 階段。

 

Build It

在這時，Think It Squad 開始擴張，以組建一個更加長時間存在的 Squad（有時是好幾個 Squad），這個 Squad 具備開發、測試、發表一個真實產品的所有需要​​的能力，這個 Squad 會長期負責這個產品，不僅僅是在 Build It 這個階段。Build It 階段的目標是構建一個 MVP（Minimum Viable Product，最小可行產品，註釋見上文），即一個對於發表給外部使用者，傳達某些產品理念來說已經足夠好的最小可行產品。這個最小可行產品利用一些例如 Scrum、Kanban 以及 eXtreme Programming 的敏捷開發方法迭代構建。

 

 

一方面，我們不希望在發表產品前構建一個十分完備的產品，因為這個過程會延遲我們獲取數據的時間。在我們把真實的軟體發表給真實的使用者之前，我們是無法確定我們是否處於正確道路的，所以我們需要盡可能快速到達 Ship It 階段。另一方面，我們不希望產出無用的或令人沮喪的產品。人們總是期待 Spotify 產出優秀的軟體，並以此來給我們打分，即便我們說目前軟體僅僅是 beta 版本或 alpha 版本。

 

於是 Squad 需要找到可以實現最基本的 narrative（故事性產品描述，產品精神），並且可以取悅使用者的他們可以做的「最小的可能成品」。或許形容它的一個更貼切的詞是 Minimum Loveable Product（最小可愛產品）。自行車對於沒有更好的交通工具的人來說是可愛的有用的產品，但是距離它的升級版，摩托車的差距還很大。但我們的確需要實現基本的產品描述，產品精神。否則，我們的判斷標準就會被誤導：「嘿，我們做出了一個輪子，並且沒有人去用它，所以說這個產品是失敗的，我們不應該去打造自行車的剩餘部分了！」

 

Think It 和 Build It 階段的關鍵不同在於，在 Think It 中，我們盡可能快，可以走遍各種捷徑並且不用擔心技術上實現的質量；而在 Build It 中，我們要寫產品級的程式並且需要保障品質。

 

完成的定義：Build It 階段，直到管理者和 Squad 共同認為目前這個產品已經實現了最基本的產品定義，並且對於開始發表給真實使用者已經足夠好的時候標誌著結束。

 

面對 Moment Of Truth（真理到來的時刻），我們已經準備好了！

 

Ship It

 

Ship It 階段的目標是逐漸將產品鋪開給所有使用者，同時進行數據檢測，確保產品在自然環境下，也能夠履行它的設計初衷。

Squad 一開始只將產品發表給全部使用者中的一小部分（一般 1-5%），以便收集數據。如何將這些使用者的行為，相比於其他的 95-99% 呢？

 

還記得嗎，我們在 Think It 階段定義了一些關於這個產品的預期，現在我們可以最終測試一下這些預期是否依然保持正確，並且對產品進行一些必要的迭代提升。一開始我們應該不太容易一下就做對，在這個模型中花的力氣也有不少是不必要的。

 

當管理者和 Squad 共同認為產品正在小範圍的使用者群中發揮預期的效果，我們就可以逐漸地在更多的使用者中鋪開產品，同時仍舊需要做數據監測和產品提升。這可以給我們時間去處理一些業務方面的事物，例如硬碟容量、監測、腳本部署、擴展性等等。

 

完成的定義：當產品對所有使用者都可用時，Ship It 階段完成。

 

注意一下，這時並不意味著產品已經「feature complete（特性、功能完全）」，完成了 Ship It 階段只是意味著產品（最小可行產品 + 必要的改進）已經被 100% 鋪開而已。其實並沒有所謂「feature complete」的說法，因為產品即使在 Ship It 階段之後還會持續進化。

 

Tweak It

這是最為關鍵的階段，因為產品們在這裡抵達重點（除非在路上他們被拋棄），並且產品在這裡花掉它生命週期中的大部分時間。

 

產品現在已經產出成果，並且對所有使用者可用。雖然在某種程度上它已經在 Ship It 階段證明了自己，但總還是有很多提高的空間。Squad 繼續展開實驗，在跟踪數據的同時，進行 A/B 測試以及改善產品，這可以包括重要的新特性也可以是較小的調整。

 

然而，未來的某一天，Squad 可能會到達一個產品的收益遞減的點。這時產品已經很好，最重要的改進已經完成，並且改進新特性帶來的收益率也將不再那麼吸引人。轉看監測數據，新特性和改進也不見得會帶來很大程度的飛躍。

 

那麼這就意味著產品已經趨近於一個「極大值」了。

 

在這個時候 Squad 和管理者就會討論：我們是不是甘於止步於這座山的山頂，或者去尋找一個更高的巔峰？在前一種情況下，Squad 可能會逐漸地轉移到其他產品的工作上去。在後一種情況下，Squad 可能會回到「Think It」階段去考慮重構這個產品或者讓這個產品去開拓國際化道路（或者至少是一個更高的山峰…）。

 

這種情況的一個實例就是 spotify.com 這個網站。該網站在 2012 年夏天我們決定去重構它之前已經修修補補了 4 年。現在這個網站已經在以一種完全不同並且出奇高效率的方式來傳達 Spotify 的願景。

 

總覽圖

 

最後的話

希望你能享受這篇文章！

如果模型中的某些部分讓你覺得「拜託，我已經早就做過這些東西了，我們已經這樣做幾十年了好嗎」，那麼你八成是對的。這個模型所述並不是新東西或很酷的方法。它只是在講述那些有用的東西——這東西是新是老其實並不重要。我發現這種實例的結合還是非常振奮人心充滿能量的，我也希望你可以在其中找到在你的環境中也有用的東西。

 

在 Twitter 上，有個老兄 po 了一張 PPT 的圖，應該是這個主題的演講，其中用一個更形象的圖總結了什麼叫「敏捷開發」：

 

 

 

 

產品開發等到天荒地老，別怕！9種鞭子與胡蘿蔔保證讓開發人乖乖聽話

轉載自合作媒體 Inside 硬塞的網路趨勢觀察