產(chǎn)品開發(fā)并不簡單。事實上，大多數(shù)產(chǎn)品開發(fā)努力到最后都失敗了，并且最常見的失敗原因就是開發(fā)了錯誤的產(chǎn)品。

來源：kent.zhu's Blog
原文：How Spotify builds products
譯者 @OmniBingo

Spotify 是一個瑞典的精益創(chuàng)業(yè)項目，它同時保持著一個很棒的產(chǎn)品交付記錄。他們的產(chǎn)品廣為用戶和藝術家喜愛，并且像病毒一樣傳播開來：他們有超過 2000 萬活躍用戶，500 萬付費用戶，并且用戶數(shù)量增速迅猛。舉一組數(shù)字說明問題，Spotify 在美國這樣一個已經(jīng)充斥著不少音頻傳播軟件提供商的海外市場，只用了 1 年時間，就把付費用戶數(shù)從 0 上升至 100 萬。

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

這個產(chǎn)品的設計理念是簡單、個性、有趣。甚至連 Metallica（美國樂隊名），這支長期以來被認為是音樂流服務的死對頭的樂隊，現(xiàn)在都稱 Spotify 是“目前最好的流服務”并且“被它的方便所震精。”

但仍舊存在一個悖論：就是像 Spotify 這樣成功的公司當然只希望產(chǎn)出人們喜愛的產(chǎn)品，但是只有在產(chǎn)品上線之后，他們才知道人們到底喜不喜歡這個產(chǎn)品。

那么他們是怎么做的呢？

這篇文章的目的就是給 Spotify 的產(chǎn)品開發(fā)方法做一個高度的概括總結(jié)。

概要

我們的核心理念是：

• 我們創(chuàng)造革命性的產(chǎn)品，同時通過早期低成本的原型設計來控制風險。
• 我們直到品質(zhì)過關了才會發(fā)布產(chǎn)品，即便已經(jīng)錯過了發(fā)布日期。
• 我們通過產(chǎn)品發(fā)布后虐心地一次次 tweak（可理解為“調(diào)整優(yōu)化”）產(chǎn)品，來確保我們的產(chǎn)品從發(fā)布起就表現(xiàn)優(yōu)異，并且到后來驚艷得令人稱奇。

所有主要的產(chǎn)品計劃都經(jīng)歷 4 個階段——“Think It（思考）”，“Build It（構建）”，“Ship It（發(fā)布）”，“Tweak It（優(yōu)化）”。下方為一個關于從產(chǎn)生靈感到形成產(chǎn)品的整個流，以及過程中的各個階段會產(chǎn)出什么玩意兒的圖示。

• Think It（思考）= 整明白我們在打造何種產(chǎn)品，為什么。
• Build It（構建）= 開發(fā)出最小可行性產(chǎn)品 (MVP)
• Ship It（發(fā)布）= 將產(chǎn)品向全部用戶逐步慢慢鋪開，同時進行數(shù)據(jù)檢測并不斷改善。
• Tweak It（優(yōu)化）= 持續(xù)不斷地提升產(chǎn)品。這是產(chǎn)品的最終狀態(tài)，產(chǎn)品不斷優(yōu)化直到生命周期終止或產(chǎn)品重構（= 回到 Think It）。

Spotify 擁有超過 30 個 Squads（可理解為“小分隊”，下同）和許多不同的產(chǎn)品，為了讓公司的其他人都了解公司正在發(fā)生什么，我們用一種產(chǎn)品狀態(tài)圖來表示每個產(chǎn)品分別處于哪個階段。大致如下：

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

為什么是這 4 個階段？

構建一個錯誤的產(chǎn)品是最具風險的事情–錯誤的產(chǎn)品無法取悅我們的用戶，同時無法提升用戶數(shù)以及用戶留存等好的指標。我們稱這個后果為“product risk（產(chǎn)品風險）”。

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

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

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

Think It

產(chǎn)品靈感在任何時間，在公司的任何人身上都可能誕生出來。大部分靈感都是去提升現(xiàn)有的產(chǎn)品（也就是“tweaks”），這種情況 Squad 們只需自己實施和發(fā)布即可。

這里說的“Think It”階段指的是某人想出了一個全新的產(chǎn)品創(chuàng)意，或者說去重構一個現(xiàn)有產(chǎn)品。

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

產(chǎn)品描述通常是一個用來回答如下問題的一個簡短的文檔：

• 我們?yōu)槭裁匆嫿ㄋ空l會從中受益，如何受益？
• 我們期望這個產(chǎn)品去提升哪些關鍵指標？這些指標可能關于播放了多少流音樂，下載量有多少，注冊量有多少等等。
• 我們的預期是怎樣的？我們?nèi)绾稳ヅ袛噙@個產(chǎn)品是否成功？
• 產(chǎn)品會帶來“階段性的改變”（階段性改變指的是，在預期中這個產(chǎn)品將帶來至少雙倍的既選指標上的提升）嗎？如果在我們的期望中，這個產(chǎn)品只是較小地提高了指標，那么要去構建它，最好有更強有力的理由，比如一些戰(zhàn)略方面的原因等。
• 產(chǎn)品描述不是必備的文檔，也不是所謂的項目計劃。它不包括特性清單、預算、資源計劃等等。它更像是一個用數(shù)據(jù)說話（數(shù)據(jù)驅(qū)動）的意愿陳述。

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

舉個栗子，Spotify 的“Discover（發(fā)現(xiàn)）”標簽是最近的一個產(chǎn)品。介紹一種發(fā)現(xiàn)音樂的更好方式。看！你最喜愛的藝術家剛剛分享了一首歌給你。我們讓藝術家們和粉絲們從未如此靠近過。喜歡一個藝術家？那就去 follow（關注）他，并與朋友們分享你的新發(fā)現(xiàn)吧。

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

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

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

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

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

這是一個主觀上的決定，它并沒有硬數(shù)據(jù)作支撐。Ship It 階段才會產(chǎn)生硬數(shù)據(jù)，所以我們希望盡可能快地到達 Ship It 階段。

Build It

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

一方面，我們不希望在發(fā)布產(chǎn)品前構建一個十分完備的產(chǎn)品，因為這個過程會延遲我們獲取數(shù)據(jù)的時間。在我們把真實的軟件發(fā)布給真實的用戶之前，我們是無法確定我們是否處于正確道路的，所以我們需要盡可能快速到達 Ship It 階段。另一方面，我們不希望產(chǎn)出無用的或令人沮喪的產(chǎn)品。人們總是期待 Spotify 產(chǎn)出優(yōu)秀的軟件，并以此來給我們打分，即便我們說目前軟件僅僅是 beta 版本或 alpha 版本。

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

Think It 和 Build It 階段的關鍵不同在于，在 Think It 中，我們盡可能快，可以走遍各種捷徑并且不用擔心技術上實現(xiàn)的質(zhì)量；而在 Build It 中，我們要寫產(chǎn)品級的代碼并且需要保障質(zhì)量。

完成的定義：Build It 階段，直到管理者和 Squad 共同認為目前這個產(chǎn)品已經(jīng)實現(xiàn)了最基本的產(chǎn)品定義，并且對于開始發(fā)布給真實用戶已經(jīng)足夠好的時候標志著結(jié)束。

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

Ship It

Ship It 階段的目標是逐漸將產(chǎn)品鋪開給所有用戶，同時進行數(shù)據(jù)檢測，確保產(chǎn)品在自然環(huán)境下，也能夠履行它的設計初衷。

Squad 一開始只將產(chǎn)品發(fā)布給全部用戶中的一小部分（一般 1-5%），以便收集數(shù)據(jù)。如何將這些用戶的行為，相比于其他的 95-99% 呢？

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

當管理者和 Squad 共同認為產(chǎn)品正在小范圍的用戶群中發(fā)揮預期的效果，我們就可以逐漸地在更多的用戶中鋪開產(chǎn)品，同時仍舊需要做數(shù)據(jù)監(jiān)測和產(chǎn)品提升。這可以給我們時間去處理一些業(yè)務方面的事物，例如硬盤容量，監(jiān)測，腳本部署，擴展性等等。

完成的定義：當產(chǎn)品對所有用戶都可用時，Ship It 階段完成。

注意一下，這時并不意味著產(chǎn)品已經(jīng)“feature complete（特性、功能完全）”，完成了 Ship It 階段只是意味著產(chǎn)品（最小可行產(chǎn)品+必要的改進）已經(jīng)被 100% 鋪開而已。其實并沒有所謂“feature complete”的說法，因為產(chǎn)品即使在 Ship It 階段之后還會持續(xù)進化。

Tweak It

這是最為關鍵的階段，因為產(chǎn)品們在這里抵達重點（除非在路上他們被拋棄），并且產(chǎn)品在這里花掉它生命周期中的大部分時間。

產(chǎn)品現(xiàn)在已經(jīng)產(chǎn)出成果，并且對所有用戶可用。雖然在某種程度上它已經(jīng)在 Ship It 階段證明了自己，但總還是有很多提高的空間。Squad 繼續(xù)展開實驗，在跟蹤數(shù)據(jù)的同時，進行 A/B 測試以及改善產(chǎn)品，這可以包括重要的新特性也可以是較小的調(diào)整。

然而，未來的某一天，Squad 可能會到達一個產(chǎn)品的收益遞減的點。這時產(chǎn)品已經(jīng)很好，最重要的改進已經(jīng)完成，并且改進新特性帶來的收益率也將不再那么吸引人。轉(zhuǎn)看監(jiān)測數(shù)據(jù)，新特性和改進也不見得會帶來很大程度的飛躍。

那么這就意味著產(chǎn)品已經(jīng)趨近于一個“極大值”了。

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

這種情況的一個實例就是 spotify.com 這個網(wǎng)站。該網(wǎng)站在 2012 年夏天我們決定去重構它之前已經(jīng)修修補補了 4 年。現(xiàn)在這個網(wǎng)站已經(jīng)在以一種完全不同并且出奇高效地方式來傳達 Spotify 的愿景。

總覽圖

最后的話

希望你能享受這篇文章！

如果模型中的某些部分讓你覺得“我去，我已經(jīng)早就造這些東西了，我們已經(jīng)醬紫做幾十年了好伐”，那么你八成是對的。這個模型所述并不是新玩意兒，屌玩意兒。它只是在講述那些有用的東西–這玩意兒新老其實并不重要。我發(fā)現(xiàn)這種實例的結(jié)合還是非常振奮人心充滿能量的，我也希望你可以在期中找到在你的環(huán)境中也有用的東東。

在 Twitter 上，有位哥們 po 了一張 PPT 的圖，應該是這個主題的演講，其中用一個更形象的圖總結(jié)了什么叫「敏捷開發(fā)」：