[核心提示] 像 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 的圖，應該是這個主題的演講，其中用一個更形象的圖總結了什么叫「敏捷開發」：