向Spotify學習如何設計產品(轉)

導語：Spotify是瑞典的精益創業項目，同時保持着很棒的產品交付記錄。通常在產品上線以後，開發者才知道人們喜不喜歡它。Spotify如何解決這個問題？

本文轉自 kent.zhu's Blog，原文 How Spotify builds products，譯者 @OmniBingo / OmniBingo|LOFTER。

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

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(你能夠保存的電臺)」說法的免費移動電臺。這種狀況下，咱們會用谷歌的關鍵詞廣告去嘗試幾種不一樣的描述，看看哪一種描述最吸引人。

關鍵在於，這個故事性描述在產品構建前就寫好了!這樣咱們能夠在產品構建前就肯定這個產品足夠吸引人。

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

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

完成的定義：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 的圖，應該是這個主題的演講，其中用一個更形象的圖總結了什麼叫「敏捷開發」：