CASE STUDY SPOTIFY Introduction Spotify is a Swedish

CASE STUDY: SPOTIFY

Introduction • Spotify is a Swedish lean startup with an awesome track record of product delivery. • Over 20 million active users, 5 million paying subscribers, and growing fast. For example, it took roughly a year to go from zero to 1 million paying • Even Metallica, long known as die-hard opponents to music streaming services, now say that Spotify is “by far the best streaming service” and are “stunned by the ease of it”. • Paradox: Spotify only want to deliver products that people love. But they don’t know if people love it until they’ve delivered it. • Reference: Henrik Kniberg: How Spotify Build Products

Philosophy • “� We create innovative products while managing risk by prototyping early and cheaply. • We don’t launch on date, we launch on quality. • W �e ensure that our products go from being great at launch to becoming amazing, by relentlessly tweaking after launch. ” • How these are matching with agile concepts?

The Whole Flow

Phases • Think It • Figure out what type of product we are building and why. • Build It • Create a minimum viable product that is ready for real users. • Ship It • Gradually roll out to 100% of all users, while measuring and improving. • Tweak It • Continuously improve the product. This is really an end state; the product stays in Tweak It until it is shut down or reimagined (= back to Think It).

Risk vs. Cost • The real risk is building a product no one needs. • Think It reduces the risk tremendously • Build It must be as fast as possible • At the end squads can go to outher things to do

Think It

Think It • A small squad is assigned • Squad is a small, cross-functional, self-organizing, independent, authoritive development team. • Members: developer (technical), (art) designer, product owner (business) • They must build • a compelling narrative (example) and, • a runnable prototype, • without deadline. • They usually build many prototypes in loops until one or some reach the target. • Aim: Decrease the product risk in a cost effective way. • Definition of Done: Think It stage ends when management and the squad jointly believe that this product is worth building (or that the product will never be worth building and should be discarded).

Build it

Build It • Squad is increased including test, build and ship competence. They own the product for long term until the end. . . • MVP: Minimum Viable Product • MVP is built iteratively according to agile methods • Should be workable, with good quality • This is narrative complete, not feature complete – find the smallest possible thing fulfills the basic narrative (Minimum Loveable Product). • Do not release the „wheel” because you need to finish if no one uses that. • Not aimed to build a complete product – that would delay learning. • You are judged based on quality (alpha and beta just a marketing stuff) • In this phase production level code is made instead of prototype quality level. • Definition of Done: The Build It stage ends when management and the squad jointly believe that this product fulfills the basic narrative and is good enough to start releasing to real users.

Ship It

Ship It • Ship gradually • first delivered only to 1 -5% of users • Test if hypotesis from Think It phase works • Improve, change the product if necessary • Gradually increase the roll out target, measure and improve continuously • Definition of Done: The Ship It stage ends when the product is available to all users. • Still not feature complete, just 100% rolled out. Feature is getting more and more complete in Tweak It phase.

Tweak It • Product spends most of its time here. • Significant new features, small improvements and fixes can get in continuously. • After some time cost/benefit ratio decreases of any modification => local maximum. Decision is needed if team and management see a higher peak • Yes: go back to Think It (rethink), • No: squad moves out to a new product (feature)

Finalize or Rethink It

Overview

• http: //xkcd. com/1492/