作者： Henrik Kniberg
- henrik.kniberg@spotify.com
- http://www.crisp.se/henrik.kniberg
原文：
- http://blog.crisp.se/2013/01/13/henrikkniberg/how-spotify-builds-products
- https://dl.dropboxusercontent.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf

產品開發著實不易。事實上，絕大多數的產品開發工作最後都徒勞無功，而最常見的原因，就是做出了錯誤的產品。
Spotify 是一家來自瑞典，具備優異產品產出履歷的精實創業公司。他們的產品為眾多的用戶與藝人喜愛，並且以病毒般的速度擴散-他們擁有兩千萬名活躍用戶，五百萬名付費用戶，而且還在持續快速成長。比方說，他們只花了一年，在美國這塊已經有眾多競爭者的土地上，讓用戶數就從零成長到一百萬人。
Spotify 的願景是在任何時刻都給你想聽的音樂。也就是，你可以無限制的接觸到來自全世界的所有音樂，也讓你可以輕易分享。播放與分享的次數愈多，藝人也就可以擁有愈豐厚的利潤。幾年前他們的產品以音樂播放器起步，現在已經演化成了可以發掘新音樂、讓藝人連結粉絲而無所不在的平台。

這些產品都被設計成容易使用、個人化、以及充滿趣味。甚至就連像 Metallica 這種原本堅決反對音樂串流服務的死硬派，現在也說「Spotify 是目前看到最佳的串流服務」，而且「簡單程度讓人目瞪口呆」。
我們接下來要討論以下的矛盾：像 Spotify 這樣成功的公司想要產出人們喜愛的產品，但是他們沒有出貨之前，也無法知道人們到底喜歡什麼。
那，他們怎麼打造產品呢？
本文的目的，就在於為 Spotify 的產品開發途徑做一摘要。
聲明 ：所有的理論模型，都是現實的簡化版本。Spotify 不盡然每次都照著本文的描述做事，而且每個部門都略有差異。但本文可以提供您一套大致的想法。
感謝 ：我不是文中這套理論模型的發明人。這篇文章的材料，來自於與 Gustav Söderström、Oskar Stål、Olof Carlson 諸位的討論，他們提供的內部文件，以及像是「思考、打造、出貨、調整」（“Think It, Build It, Ship It, Tweak It）這類的框架。在與許多設計師、開發者、敏捷教練的談話中，我也受益良多。感謝大家！

摘要

我們的核心哲學是：
- 我們打造創新的產品，但也在早期以廉宜的雛形管理風險
- 我們不根據時間出貨，而是在達到品質的時候出貨
- 我們確保我們的產品在出貨的時候就很傑出，在出貨之後也以不斷調整達到愈加精進
所有的主要產品在萌芽時，都需要經過四個階段：「思考、打造、出貨、調整」。下圖說明從概念到最終產品的流程，以及每個階段會發生那些事情。您可以在本文的結尾看到更完整的版本。

- 思考 ：勾勒我們想要什麼類型的產品，並思考為什麼要
- 打造 ：創造真的可供使用者使用的最小可行產品（minimum viable product）
- 出貨 ：完成百分之百可以供所有使用者使用的產品，同時繼續評量與改進
- 調整 ：持續改進產品。這是流程的最後階段；產品接下來會一直進入調整階段，直到我們結束這項產品，或是我們又重新發想一輪（回到「思考」階段）
Spotify 擁有超過三十個班（Squads），以及一定數量的產品，所以要讓公司其他人知道所有產品進度，並且以視覺化方式呈現，我們用上一塊產品進度白板顯示所有產品的所在階段。如下圖：

我們也正在實驗採用預報機制，讓每個班定期負責更新白板，寫上從哪一段日期（從某一天到某一天），他們認為他們所負責的產品可以進入下一階段。

為什麼要四個階段？

最大的風險莫過於開發了錯誤的產品-我們的使用者不喜歡，或者是沒有達到爭取新用戶、維繫舊用戶等產品是否成功的評量標準。我們稱之為「產品風險」（Product Risk）。
這四個階段幫助我們降低風險，並且讓產品儘早問世。下圖顯示每一階段中風險如何降低，以及每一階段的成本。

如您所見，思考階段以最低的成本降低最大的風險，您也可以看到為什麼我們想要盡可能縮減打造階段（成本高、可降低的風險低），而最終可以在最後的調整階段整個降低營運成本，產品不需要經常更新，每個班也因此可以移動到新的目標上。
每個階段的時間長短差異極大，上圖中的比例只是一個範例而已。總時間也長短不一，有些產品只花上幾個月就完成，有些則可能耗上半年或更久。而每個階段中，都是在相當持續的基礎上，完成（甚至可能有些只是內部的）釋出。
我們來仔細看看每個階段。

思考

在任何時間、公司裡的任何人，都可能誕生關於產品的想法。許多想法是如何改進既有產品（調整），而所負責的班，就自行在所負責的產品中，實作這套想法並釋出。
這邊所謂的「思考」階段，主要是指有人想到了一個全新的產品，或是對既有產品做了全盤重新發想。

如果管理階層同意這套想法值得繼續探索，就會組成一個小型、跨功能的「思考班」。通常包含了一位開發者、一位設計師以及產品所有者（Product Owner）。他們的任務便是寫出產品的定義文件，並製作迷人的雛形出來。
產品定義是一份要回答以下問題的文件：
- 我們為什麼要做這個？誰會從中得益？如何得益？
- 我們期待可以從這個產品中得到的好處，有什麼關鍵的評量標準？像是，會增加多少歌曲播放數、增加多少下載量、多少登入次數…等等。
- 我們做了哪些假設？釋出之後，我們怎麼知道這套產品是成功的？
- 我們會有「飛躍性的改變」嗎？（像是，在所指定的評量標準上，會產生兩倍以上的成長）如果我們期待在評量標準上只有若干成長，是否還有什麼我們非做不可的理由？例如，是不是某種長期策略？
產品定義並非需求文件或是專案計畫文件，當中並不包含功能、預算、資源分配計畫等等。這份文件比較像是資料導向的目的聲明。
產品定義中最重要的部份在於如何 /敘事/ （Narrative）。-我們要告訴全世界怎樣的故事？我們的新聞稿寫起來像是什麼樣子？
比方說，Spotify 最近推出了「探索」（Discover）分頁，我們從兩分鐘的影片中摘要當中的敘事情節：

鄭重介紹更好探索音樂的方式

瞧！您所喜愛的藝人分享了一首歌給你。我們將藝人與歌手拉近到前所未有距離。喜歡某位藝人嗎？那就關注他們，並且分享朋友說你探索到了什麼。
另一個範例則是「行動免費廣播」（Mobile Free Radio）這個產品，採用的敘事是：「你可以存檔的廣播」（Radio you can save）。我們在此使用了一些 Google 關鍵字廣告，嘗試各種敘事方式的可能，從中找到最迷人的選擇。
在這邊的關鍵是：我們在產品開始 /之前/ ，就寫好了敘事情節！我們要確定在開始打造產品之前，就具備迷人的特性。
此外，思考班需要準備許多不同的雛形，實驗產品的外觀與感受如何，可以是「低傳真」的紙上雛形，也可以是「高傳真」的、可運作的雛形（不過用的是假資料就是了）。我們會使用內部焦點團體協助勾勒出哪套雛形最能夠承載所規劃出的敘事，最終決定若干勝出的候選者。

這是一個沒有截止日期的反覆流程。除非我們可以找出迷人的敘事情節以及符合需求的雛形，我們不會開始打造產品，我們也無法決定這個流程應該要多久。
就像我們上面那張風險與成本曲線圖，思考階段讓我們以非常低成本的方式降低風險-我們就只是實驗與做雛形而已。這個階段讓我們用廉宜而安全的方式處理失敗，所以我們在找出應該做的產品前，可以安心地不斷嘗試。
對於完成的定義 ：當管理階層與負責的班都相信這個產品值得做，這個階段便告完成。（反之，就代表這個產品不值得做，而且應該擱置）
這是一個主觀的決策，沒有什麼堅實的資料足以支持這項決定。要等到出貨階段才有堅實的資料，所以我們會希望儘快到這個階段。

打造

思考班接下來便成長為更一穩固的班（有些甚至成長成好幾班），擁有打造、測試、釋出真正產品的所有技能。這個班接下來會長期擁有這項產品，而不僅只是在打造階段而已。
打造階段的目的，在於建立最小可行產品（MVP），可以好到能夠釋出給外部使用者，以及可以證明這個產品的確有些什麼。在這個階段，會反覆使用敏捷開發方式，像是 Scrum、看板（Kanban）、極限編程（eXterme Programming）打造 MVP。

在這邊我們使用一張圖表，說明如何評量從無用到完美之間的平衡取捨：

一方面，我們並不想要在出貨之前就做出完整的產品，因為這會延遲我們從使用者學習東西的時間。我們無法確定我們是否走在正確的道路上，除非我們把真正的產品提供給真正的用戶使用，所以我們要儘快完成。另一方面，我們也不想要拿出無用或讓人難堪的產品，假如我們說某個產品只是 beta 甚至 alpha，人們也會期待 Spotify 拿出像樣的東西，並且評斷我們最後會拿出什麼。
所以負責的班必須勾勒出可以符合敘事、又讓使用者高興的 /最低限度能做出來的東西/ 。我們要讓敘事成立，而不是完成所有功能。或許我們稱之為「最小可愛產品」（Minimum Loveable Product）會更為恰當。一台腳踏車對於沒有交通工具的人來說，就是可愛又有用的產品，雖然距離要進化成摩托車還有很遠的距離。我們需要做到達成敘事的條件，要不然就誤會大了：「嘿！我們做了個輪子，但是沒有人要用，所以我們產品失敗了，我們不該繼續做車子的其他部分！」
思考與打造階段間的最大差別，在於，思考階段中，我們可以使用所有的捷徑，而不需考慮任何工程品質，但是在打造階段，我們要撰寫產品等級的程式碼，並且要合乎水準。
對於完成的定義 ：當管理階層與負責的班同時相信這個產品基本達到了敘事內容，並且好到可以開始釋出給真正的用戶時，打造階段便告結束。
我們準備迎接面對真相的時刻了！

出貨

出貨階段的目的在於最終推出供用戶使用的百分之百完成的產品，並且評量、保證是否達到在產品之初所做下的承諾。

負責的班開始對少數用戶（大約在 1-5% 之間）釋出產品，蒐集所需的資料：相較於其他 95-99% 的用戶，這些使用者有些什麼行為呢？
記住，我們在思考階段的時候，就做了一些假說。我們現在就要驗證這些假說是否成立，並且視需要反覆改善我們的產品。我們很少第一次就做對，而這個模型的一部分好處就是，我們沒有必要第一次就做對。
當管理階層以及負責班同意，這項產品已經對少部分用戶產生預期的衝擊，我們便可以一邊評量與改善，一邊繼續將這項產品推廣給其他用戶。這個階段讓我們有時間處理一些營運面向的問題，像是硬體是否足夠、如何監控、撰寫佈署用 script、如何繼續擴充規模…等等。
對於完成的定義 ：當產品可以讓所有用戶使用時，出貨階段便告結束。
注意，這時候產品其實還沒有完成所有的功能。出貨階段只代表目前的產品（最小可行產品加上必要的改進）百分之百推出。我們永遠無法做完所有的功能，因為在出貨之後，產品還會繼續演進。

調整

這是最重要的階段，因為這是所有產品的最終階段（除非我們停止這項產品），也是我們在產品上花最多時間的階段。

現在，所有用戶都已經可以使用這項產品了。雖然在出貨階段這項產品就證明了自己一定的價值，但是我們還有很多改進的空間。負責的班要繼續用各種實驗，A/B 測試，以及各種評量標準改進產品。改善內容可能包括添加新功能，或是局部調整。
不過，有時候，負責的班會面臨產品開發的衰退期。產品雖然很不錯，最主要的改進都已經完成了，接下來開發新功能的損益比變得不怎麼吸引人。在評量指標上，各種新功能、改進項目，都無法改動指針所在的位置。
這就代表，產品目前走向了「局部最大化」（Local Maximum）。

這時候，負責的班與管理階層就該討論：我們該在這個頂峰就滿足，還是我們還有更高的山岳可以攀登？一般來說，負責的班就會移動到其他產品上，但如果負責的班相信還可以創造更多收益，他們就會重回「思考」階段，重新發想產品，而創造出「全域最大化」（Global Maximum），或最起碼另外一座更高的頂峰…。

就拿 spotify.com 這個網站舉個例子。我們在 2012 年夏天重新發想這個網站之前，我們花了四年的時間不斷調整；這個網站現在可以用完全不同，但戲劇化地更有效方式，承載 Spotify 的願景。

概觀圖例

結語

希望您喜歡這篇文章！
當您看到這個理論模型的一部分的時候，您可能會想「呵，我早就知道了，我們早就這麼做十幾年了。」您可能是對的。這個模型並不是什麼又新又炫的東西，而是「確實有用」-至於新舊，一點都不重要。我以為這套各種模型的混合實踐非常激勵人心，又極具威力，我也希望您可以從中找到對您而言有用的東西。
如果您有任何意見或問題，歡迎與我聯絡，或是在我的 blog 上留言。我們可能沒有足夠的時間詳細回答所有的問題，但是可能會針對一些最常見的問題增設一篇 FAQ。