 |
相關閱讀 |
精益創業實例，Spotify 如何構建產品
|
>>> 創業先鋒 眾人拾柴火焰高 >>> | 簡體 傳統 |
原：Henrik Kniberg 譯：Omnibingo 產品開發并不簡單。事實上，大多數產品開發努力到最后都失敗了，并且最常見的失敗原因就是開發了錯誤的產品。 Spotify是一個瑞典的精益創業項目，它同時保持著一個很棒的產品交付記錄。他們的產品廣為用戶和藝術家喜愛，并且像病毒一樣傳播開來：他們有超過2000萬活躍用戶，500萬付費用戶，并且用戶數量增速迅猛。舉一組數字說明問題，Spotify在美國這樣一個已經充斥著不少音頻傳播軟件提供商的海外市場，只用了1年時間，就把付費用戶數從0上升至100萬。 Spotify的愿景是在任何時候給你帶來對的音樂。這意味著它將無限地接入全世界的音樂，并且在Spotify中分享音樂會十分容易；并且音樂被分享和播放得越多，那么音樂的創作藝術家們就可以獲得越多的錢。幾年前，Spotify以一個音樂播放器的身份誕生，如今，他們的產品演變成一個發現新音樂和在藝術家和粉絲間建立直連的廣袤的平臺。 這個產品的設計理念是簡單、個性、有趣。甚至連Metallica（美國樂隊名），這支長期以來被認為是音樂流服務的死對頭的樂隊，現在都稱Spotify是“目前最好的流服務”并且“被它的方便所震精。” 但仍舊存在一個悖論：就是像Spotify這樣成功的公司當然只希望產出人們喜愛的產品，但是只有在產品上線之后，他們才知道人們到底喜不喜歡這個產品。 那么他們是怎么做的呢？ 這篇文章的目的就是給Spotify的產品開發方法做一個高度的概括總結。 免責聲明：類似于所有的模型一樣，這里講述的模型只是實際情況的一種簡化。他們并不總是緊緊地依照下面所述的流程做事，同時實際情況中，還會有許多局部上的變化。但是這篇文章可以向你傳達大致精神。 鳴謝：并不是我發明了這個模型。這篇文章的基礎來源于和Gustav Söderström, Oskar Stål, Olof Carlson的討論以及他們的內部資料和一些框架，諸如“Think It,Build It, Ship It, Tweak It”。通過和設計師、開發者以及犀利的導師的對話，我也學到了很多。感謝所有人！ 我們的核心理念是： 我們創造革命性的產品，同時通過早期低成本的原型設計來控制風險。 我們直到品質過關了才會發布產品，即便已經錯過了發布日期。 我們通過產品發布后虐心地一次次tweak（可理解為“調整優化”）產品，來確保我們的產品從發布起就表現優異，并且到后來驚艷得令人稱奇。 Think It（思考） = 整明白我們在打造何種產品，為什么。 Build It（構建） = 開發出最小可行產品 Bingo注：“精益創業”最核心的思想是“最小可行產品(Minimum Viable Product)”。 Ship It（發布） = 將產品向全部用戶逐步慢慢鋪開，同時進行數據檢測并不斷改善。 Tweak It（優化） = 持續不斷地提升產品。這是產品的最終狀態，產品不斷優化直到生命周期終止或產品重構（= 回到Think It）。 Spotify 擁有超過30個 squads （可理解為“小分隊”，下同）和許多不同的產品，為了讓公司的其他人都了解公司正在發生什么，我們用一種產品狀態圖來表示每個產品分別處于哪個階段。大致如下： Bingo注：squad，是一種小的，由不同職能隊員自發組成的開發小組。 我們同時也面向一些squad試行預測機制，這些squad對產品何時將會到達下一個階段有一個日期時間上的預期，并對提供的這個階段晉級日期范圍（日期X-日期Y）負責。 為什么是這4個階段？ 構建一個錯誤的產品是最具風險的事情--錯誤的產品無法取悅我們的用戶，同時無法提升用戶數以及用戶留存等好的指標。我們稱這個后果為“product risk（產品風險）”。 這個4階模型幫助我們壓低風險，并且快速做出產品。下面這個圖表可以看出在每個階段產品風險是如何被降低的，同時可以看到每個階段是如何地成本密集。 我們可以看到，Think It這個階段可以以很低的成本降低風險。同時我們也看到我們為什么要盡可能縮短Build It這個階段（因為它消耗很高的運作成本卻幾乎無法帶來風險的降低）。而在Tweak It階段逐漸降低的運作成本表明，隨著時間推移，產品并不需要進行盡可能多的更新，squad們可以開始繼續去做其他事情。 每個階段的周期變化多端，上面的這個比例只是一個例子而已。總的時間同樣也是會變的；有些產品從孵化到產出也就是幾個月的事情，而另一些產品可能要花去大半年甚至更多的時間。但是在每個階段里，產出（即便只是內部的）都是在一個可持續性的基礎上完成的。 好，現在我們仔細來研究一下每一個階段。 產品靈感在任何時間，在公司的任何人身上都可能誕生出來。大部分靈感都是去提升現有的產品（也就是“tweaks”），這種情況squad們只需自己實施和發布即可。 這里說的“Think It”階段指的是某人想出了一個全新的產品創意，或者說去重構一個現有產品。 如果管理者也認為這個想法是值得付諸實踐的，那么一個小型的“Think It”squad隨即成立。典型的“Think It”squad一般包括一個開發者，一個設計師和一個產品經理。他們的工作就是去完善產品描述，同時構建一個足夠吸引人的產品原型。 產品描述通常是一個用來回答如下問題的一個簡短的文檔： 我們為什么要去構建他？誰會從中受益，如何受益？ 我們期望這個產品去提升哪些關鍵指標？這些指標可能關于播放了多少流音樂，下載量有多少，注冊量有多少等等。 我們的預期是怎樣的？我們如何去判斷這個產品是否成功？ 產品會帶來“階段性的改變”（階段性改變指的是，在預期中這個產品將帶來至少雙倍的既選指標上的提升）嗎？如果在我們的期望中，這個產品只是較小地提高了指標，那么要去構建它，最好有更強有力的理由，比如一些戰略方面的原因等。 產品描述中最重要的部分就是故事性描述。我們要向世界講什么故事？新聞稿又是什么樣的呢？ 舉個栗子，Spotify的“Discover（發現）”標簽是最近的一個產品。這里有一段2分鐘的視頻來為這個產品講故事：（原文鏈接失效） 介紹一種發現音樂的更好方式。 看！你最喜愛的藝術家剛剛分享了一首歌給你。我們讓藝術家們和粉絲們從未如此靠近過。喜歡一個藝術家？那就去follow（關注）他，并與朋友們分享你的新發現吧。 另外，“Think It”squad會構建許多不同的原型來傳遞產品的感官上的體驗--同時會有“低保真”的紙面原型和“高保真”的可運行的原型（上面跑偽數據源之類）。這時幾個內部焦點小組會用來辨別哪一個原型最好地傳達了它的產品精神（那個故事性描述），直到我們不斷縮小范圍，最后只剩下幾個勝出的原型。 這是一個沒有截止日期的迭代過程。只有當我們可以拿出一個足夠吸引人的故事性描述和能夠傳達出它的可運行的原型，這個產品才是值得去構建的。我們無法決定這個產品前期會花去多少時間。 完成的定義：Think It階段直到管理者和squad共同認同這個產品是值得構建的（或者這個產品永遠都不值得構建，故應該被舍棄）則標志完成。 這是一個主觀上的決定，它并沒有硬數據作支撐。Ship It階段才會產生硬數據，所以我們希望盡可能快地到達Ship 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階段的目標是逐漸將產品鋪開給所有用戶，同時進行數據檢測，確保產品在自然環境下，也能夠履行它的設計初衷。 Squad一開始只將產品發布給全部用戶中的一小部分（一般1-5%），以便收集數據。 如何將這些用戶的行為，相比于其他的95-99%呢？ 還記得嗎，我們在Think It階段定義了一些關于這個產品的預期，現在我們可以最終測試一下這些預期是否依然保持正確，并且對產品進行一些必要的迭代提升。一開始我們應該不太容易一下就做對，在這個模型中花的力氣也有不少是不必要的。 當管理者和squad共同認為產品正在小范圍的用戶群中發揮預期的效果，我們就可以逐漸地在更多的用戶中鋪開產品，同時仍舊需要做數據監測和產品提升。這可以給我們時間去處理一些業務方面的事物，例如硬盤容量，監測，腳本部署，擴展性等等。 完成的定義：當產品對所有用戶都可用時，Ship It階段完成。 注意一下，這時并不意味著產品已經“feature complete（特性、功能完全）”，完成了Ship It階段只是意味著產品（最小可行產品+必要的改進）已經被100%鋪開而已。其實并沒有所謂“feature complete”的說法，因為產品即使在Ship It階段之后還會持續進化。 這是最為關鍵的階段，因為產品們在這里抵達終點（除非在路上他們被拋棄），并且產品在這里花掉它生命周期中的大部分時間。 產品現在已經產出成果，并且對所有用戶可用。雖然在某種程度上它已經在Ship It階段證明了自己，但總還是有很多提高的空間。Squad繼續展開實驗，在跟蹤數據的同時，進行A/B測試以及改善產品，這可以包括重要的新特性也可以是較小的調整。 然而，未來的某一天，squad可能會到達一個產品的收益遞減的點。這時產品已經很好，最重要的改進已經完成，并且改進新特性帶來的收益率也將不再那么吸引人。轉看監測數據，新特性和改進也不見得會帶來很大程度的飛躍。 那么這就意味著產品已經趨近于一個“極大值”了。 在這個時候squad和管理者就會討論：我們是不是甘于止步于這座山的山頂，或者去尋找一個更高的巔峰？在前一種情況下，squad可能會逐漸地轉移到其他產品的工作上去。在后一種情況下，squad可能會回到“Think It”階段去考慮重構這個產品或者讓這個產品去開拓國際化道路（或者至少是一個更高的山峰...）。 這種情況的一個實例就是spotify.com這個網站。該網站在2012年夏天我們決定去重構它之前已經修修補補了4年。現在這個網站已經在以一種完全不同并且出奇高效地方式來傳達Spotify的愿景。 希望你能享受這篇文章！ 如果模型中的某些部分讓你覺得“我去，我已經早就造這些東西了，我們已經醬紫做幾十年了好伐”，那么你八成是對的。這個模型所述并不是啥新玩意兒，屌玩意兒。它只是在講述那些有用的東西--這玩意兒新老其實并不重要。我發現這種實例的結合還是非常振奮人心充滿能量的，我也希望你可以在其中找到在你的環境中也有用的東東。 如果你有任何反饋或問題，一定及時聯系，或者在博客里寫評論。我們可能不一定有時間回答具體的問題，但是可能可以依照這常見的問題在這個文章后面加上FAQ。 /Henrik Kniberg henrik.kniberg@spotify.com http://www.crisp.se/henrik.kniberg 翻譯： wechat/weibo : Omnibingo mail : Omnibingo@gmail.com http://omnibingo.lofter.com
所有主要的產品計劃都經歷4個階段--“Think It（思考）”，“Build It（構建）”，“Ship It（發布）”，“Tweak It（優化）”。下方為一個關于從產生靈感到形成產品的整個流，以及過程中的各個階段會產出什么玩意兒的圖示。
什么是“最小可行產品”？簡單說，就是一個產品雛形。將它推向市場后，根據客戶反饋來改進它。可以舉例說明之。在建筑行業，建一座房子之前，必先搭一個模型，這就是“最小可行產品”。
產品描述不是必備的文檔，也不是所謂的項目計劃。它不包括特性清單、預算、資源計劃等等。它更像是一個用數據說話（數據驅動）的意愿陳述。
另一個例子是有“Radio you can save（你可以保存的電臺）”說法的免費移動電臺。這種情況下，我們會用谷歌的關鍵詞廣告去嘗試幾種不同的描述，看看哪種描述最吸引人。
關鍵在于，這個故事性描述在產品構建前就寫好了！這樣我們可以在產品構建前就確定這個產品足夠吸引人。
互聯網er的早讀課 2015-08-23 08:47:03
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表