It was interesting to read a very detailed breakdown of how Spotify build products by Henrik Kniberg. Kniberg is a Swedish Agile expert who consults with a lot of different companies on how to best implement Agile and Lean practices. Kniberg is well respected when it comes to iterative development and Spotify is growing rapidly within the music industry (an industry which I also happen to work in with 7digital). Kniberg’s article gives a great insight into how companies can successfully apply some of the principles around “releasing early and often”.

In this blog post, I’ll highlight both Spotify’s underlying philosophy and the 4 key stages that form its product development process. Let’s start with Spotify’s core philosophy first:

1. “We create innovative products while managing risk by prototyping early and cheaply” – Rather than taking a product through a whole product development cycle before finding out whether it provides value or not, Spotify prefers to release early and often instead. True to the philosophy of  “Agile” and “Lean” development methodologies, Spotify’s focus is on launching new products or features as soon as possible to see how they perform in real-time. The main benefits of this approach are twofold. Firstly, risk is managed more effectively and companies are likely to get real-time product feedback (from real users) a lot sooner.
2. “We don’t launch on date, we launch on quality” – I guess not all businesses have the luxury of not having too worry about deadlines – think of companies that have to oblige contracts or other time-led constraint – but Spotify clearly seem to value quality over time. I guess the main point of this principle is the focus on quality above anything else. The challenge for any product person and developer is to strike the right balance between releasing early and often AND launching quality products. For instance, at 7digital we aim to release continuously whilst making sure that every singly release is fully tested to ensure set quality standards (I’ve written about this practice earlier).
3. “We ensure that our products go from being great at launch to becoming amazing, by relentlessly tweaking after launch” – “Continuous Improvement” is the key term here. I wrote about this earlier and highlighted its roots in Japanese car manufacturing. In practice, this means that Spotify will try to ensure a certain quality standard upon launch, followed by further improvements based on real-time feedback and performance. A product is never ‘finished’ and as a product person you can never rest on your laurels; I believe that iterative development is effectively a continuous loop of releasing, measuring, learning, iterating, releasing and measuring again.

Now look at the 4 product development stages that are applied at Spotify:

1. “Think It” – The first stage of Spotify’s product development process is all about figuring out what type of product should be built and why. The “Think It” stage can apply to both completely new product ideas or improvements to existing Spotify products. What’s interesting about this stage is that the overriding emphasis seems to be on creating a compelling narrative and less on on coming up with convincing metrics or a tight business case. Like they do at Amazon, a product’s narrative is written well before its being built (see also the the scope of a standard Spotify “product definition” in Fig. 1 below). Prototyping is the other aspect of the “Think It” stage that I like very much; a dedicated “Think It Squad” (typically a designer, a developer and a product owner) will create a number of prototypes to kick things off, varying in fidelity.
2. “Build It” – With Spotify’s “Build It” stage the focus is on creating (and shipping) a product that’s “narrative complete” and not feature complete. Going back to the focus on delivering a compelling narrative in the previous “Think It” stage, the aim is is to release a product that fulfils the basic narrative to the user. At Spotify, they don’t talk about a minimum viable product (‘MVP’) but about a “minimum loveable product” instead. It’s about creating an initial product that real users will love and that fulfils the narrative.
3. “Ship It” – True to the “Lean” approach, in the “Ship It” stage, Spotify will gradually roll out the product to all of its users. Instead of one big bang release, Spotify will start by releasing to a small percentage of all users (typically 1-5%), in order to collect data. This is the best bit in my opinion; the use of data to incrementally improve a product, compare groups of users and spread risk. This approach is a clear example of “data driven product development” as advocated by the likes of Eric Ries, Ash Maurya and Steve Blank. This ‘staggered’ approach is used for continuous measuring and improving, making product improvements as it’s being rolled out to more and more users. This also means, as Kniberg points out, that by the end of the “Ship It” stage a product is by no means “feature complete”. It just means that the product (= MVP + necessary improvements) has been 100% rolled out and that it will continue to evolve.
4. “Tweak It” –  This is a critical part of the product lifecycle since this is where the product is likely to spend most of its time. The product is now live and being used by all users and ‘the squad’ will continue to experiment with the product. The squad will continue doing A/B tests to make improvements (big or small) until a point is reached where the product as whole needs to be evaluated, especially when the product is starting to reach the point of diminishing returns (see also Spotify’s definition of “done” for this stage in Fig. 2 below). Do we keep tweaking the product, adding minor improvements? Or do we rethink the product as a whole?

Main learning point: Kniberg’s article on how Spotify builds products provides in my opinion mandatory reading for most product managers or developers, especially for those with an interest in lean or iterative development. The 4 different product development stages used at Spotify are well defined and really help in both spreading the risks involved in launching a new product and getting real user feedback as soon as possible. Don’t worry if you don’t have the resources that Spotify have; you’ll still be able to apply a lot of the underlying principles and techniques!

Fig. 1 – Scope of a “product definition” document at Spotify

The product definition is a short document that answers questions such as:

• Why should we build this?
• Who will benefit from this and how?
• What are the key metrics that we expect this product to improve?
• What are the hypothesis? How will we know if this product is successful?
• Is this a “step change” (that is, a product that we expect will give at least a 2x improvement on the chosen metric)? If we expect only minor improvement on the metrics, there better be some other strong reason for building it, for example a strategic reason.

Fig. 2 – Definitions of “done” for the 4 stages of Spotify’s product development

• Think It – definition of done: The Think It stage ends when Spotify’s 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 – definition of done: The Build It stage ends when Spotify’s management and ‘the squad’ jointly believe that this product fulfils the basic narrative and is good enough to start releasing to real users.
• Ship It – definition of done: The Ship It stage ends when the product is available to all users.
• Tweak It – definition of done: The Tweak It stage ends when a product has reached a point of diminishing returns. The product is great and the most important improvements have been made. The cost/benefit ratio of new feature development, however, is less attractive. Looking at the metrics, new features and improvements don’t seem to be moving the needle a lot.

Fig. 3 – Scaling Agile at Spotify – Taken from: http://techcrunch.com/2012/11/17/heres-how-spotify-scales-up-and-stays-agile-it-runs-squads-like-lean-startups/

Related links for further learning:

1. http://blog.crisp.se/2013/01/13/henrikkniberg/how-spotify-builds-products
2. http://www.spotify.com/se/blog/archives/2012/12/06/discover/
3. http://www.svproduct.com/assessing-product-opportunities/
4. http://www.theverge.com/2013/3/11/4080130/can-anyone-turn-streaming-music-into-a-real-business
5. https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
6. http://techcrunch.com/2012/11/17/heres-how-spotify-scales-up-and-stays-agile-it-runs-squads-like-lean-startups/