Learning about how Spotify build products

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/

Developing my own product – Creating a product vision

One of my longstanding dreams has been to develop my own product. My own creation, from start-to-finish, is something I’d really wanted to do. The goal is not to become the next Steve Jobs or Mark Zuckerberg, but it would be great to having something that people can actually use and that’s ‘my own’. So I decided to go through the ‘proper product development’ process as I would with any other product and apply the same logic and steps.

My first step was to determine whether a product ‘has got legs’. What is my product idea? Who are my target customers and which of their problems is my idea aiming to solve and why? Can the product be technically and commercially viable? What’s the best business model for the app? What are my expectations with this app? With all these questions flying through my head, I decided on creating a product vision as a starting point. My thinking was that once I had worked out what problem I was looking to solve and for whom, I could start assessing the opportunity.

  1. Let’s start with a bit of context first – For the past 4 years I’ve been running HipHopListings, a simple Twitter feed and blog that informs people of upcoming Hip Hop gigs in the UK and lets them know about new Hip Hop releases. HipHopListings has proven to be very popular, with approximately 4,000 followers on Twitter and lots of interaction around what’s effectively a list. Numerous users have been asking me to create a mobile app, providing an overview of Hip Hop shows on any given date for any UK location.    
  2. Now what’s the idea!? – Existing concert tracking apps like Songkick or Ticketmaster mostly enable tracking based on a user’s location (Ticketmaster or Seatwave) or based on specific artists that you’re tracking or that are in your music library (Songkick or GigsandTours). However, none of them seem to be doing ‘genre specific tracking’, providing users with an overview of shows in a specific music genre they’re interested in. Whilst doing HipHopListings, I’ve received a lot of feedback from users who liked the fact that HHL covers Hip Hop shows and releases in the broadest sense of the word and thus lets them discover things they might not have done otherwise (see Fig. 1 below).
  3. My main goal / vision – Before I did anything else, I started thinking about a clear product vision or goal to work towards. I tied this in with thinking about HipHopListing’s target users and their needs (see Fig. 1 below) and some very rudimentary sketches of my product idea (see Fig. 2 below). I believe that a good product vision has two main characteristics. Firstly, it’s succinct but very clear. Secondly, it needs to express a clear goal that you’re trying to achieve (and which you can validate). I thus started drafting a number of possible product vision statements (see Fig. 3 below).
  4. Can my vision be tested? – Whilst coming up with potential vision statements (see Fig. 3 below) I also started thinking whether my goals and visions could be validated. I’ve learnt the importance of being able to test a specific goal or aspiration. For instance, what does a possible vision statement stating that I want to create “A great overview of Hip Hop gigs and releases at your fingertips” actually mean? Is there a way to measure whether I’ve been successful in achieving this vision? Which metrics do I need to start measuring? With the rough product vision statements that I started outlining I also started thinking about potential metrics that could help to validate some of my assumption (see Fig. 4 below).
  5. Initial product vision – In the end I settled on “A comprehensive list that lets users filter shows by location and by date”. This vision encapsulates what I’d ultimately like to achieve with my HipHopListings app: a simple but truly comprehensive list of shows that users can interact with, wherever they are. This vision leaves room to add features like ‘upcoming release information’, but my key focus is to create a list that provide info on all Hip Hop gigs (big and small) across the UK.

Main learning point: applying some common product management tools to your own idea definitely adds a different dimension! I found that taking something that’s your own brainchild and being rigorous about can certainly be challenging at times. Mind you, at this stage no one hadn’t really heard about my idea or goal, nor had seen any of my – very rudimentary – sketches. However, spending a bit of time of upfront thinking about the “why” and “who” of my idea was very helpful in refining some of my ideas and assumptions. I believe that every idea for a product or service needs a starting point. Thinking about an product vision / goal was my starting point in thinking about creating a mobile app for HipHopListings.

Fig. 1 – Target users and the problems that the HipHopListings app is looking to solve

User 1 – Hip Hop fans who wish to find out about Hip Hop gigs in their local area

“King B” – “How do u find out about concerts & gigs in uk? Is there an app for iPhone?”

“King B” is a Manchester-based finance student and entrepreneur. He has been following HHL on Twitter for 3 years and checks it regularly to find out about Hip Hop shows in Manchester. His favourite artists are J. Cole, Blu and Trey Songz.

Main problem: would like to find out about Hip Hop gigs in the UK though a mobile app.

King B screenshot

User 2 – Regular concert visitors looking to plan city trips around shows

“Beth Jo Scott” – “Sappnin 23-26th Feb in London? Anything good/not sold out?”

“Beth Jo Scott” lives in Blackburn, follows HipHopListings on Twitter and is passionate about music and Hip Hop music in particular. Beth Jo is 23 and loves going to Hip Hop gigs across the UK. However, she often tends to find out about shows once they’re already sold out or have taken place.

Main problems: (1) finding out abouts shows as soon as details are released and (2) planning trips to UK cities around a Hip Hop gig.

User 3 – Hip Hop artists or promotors who wish to promote their gigs and releases

“Skillit” – #skillitbang album launch party on @hiphoplistings tumblr#skilllitmusic make it down there http://instagr.am/p/VuD2nImSgx/

“Skillit” is a London-based rapper who does a lot of gigs in small venues across the UK. He’s not yet big enough to be picked up by big ticket resellers such as Tickemaster or See Tickets. He therefore uses a much more ‘grass roots’ approach to marketing his upcoming shows, using HipHopListings and other UK Hip Hop sites to promote his gigs. Main problem: being able to promote my gigs and releases across a wide audience of Hip Hop fans.

Skillit screenshot

User 4 – Hip Hop fans who wish to be alerted on upcoming Hip Hop shows in their area.

“Joey Del Negro aka DJ Skoundrel” – “why am I only hearing about this now??!!”

Joey Del Negro is a London-based DJ and regular visitor of Hip Hop gigs. He finds that’s he often (too) late in finding about Hip Hop gigs in London and wants to receive regular alerts about Hip Hop gigs coming up. Joey doesn’t have a specific Hip Hop artist or DJ he’s interested in, he likes to be kept up to date on upcoming Hip Hop shows, so that he can then decide what he really wants to go and see.

Main problem: wanting to find out about upcoming Hip Hop shows as soon as possible.

Joey Del Negro screenshot

Fig. 2 – Some initial sketches of possible user interface 

A basic way to list gig information, outlining date, artist, location, venue and ticket resellers: 

0306'13 Gig outline sketch V1.pdf

A basic way to filter gig information, with the user being able to select using a number of filters:

0306'13 Gig filter sketch V1 A basic way to list release information, outlining date, artist, release title and link to buy / download: 

0306'13 Release outline sketch V1.png

Fig. 3 – Possible vision statements for the HipHopListings mobile app

Long version:

“HipHopListings is a mobile app for Hip Hop fans in the UK who want to be kept up to date on Hip Hop events across the UK and Hip Hop releases. Our app lets users find about Hip Hop shows or releases by artists they might not even have heard about, but will be triggered to go an check it out. Our app goes beyond specific artists you wish to track and gives you a complete overview of upcoming Hip Hop shows and releases, making sure you have full access to what’s going on and letting you filter this info by location or date.”

Shorter vision statements:

  • “A great overview of Hip Hop gigs and releases at your fingertips”
  • “Enabling Hip Hop fans to access gig and release info where and when they like”
  • “A comprehensive list that lets users filter shows by location and by date”
  • “A single source for all Hip Hop concert and release information”
  • “An app that doesn’t track artists but tracks all the releases and shows in the genre you’re passionate about”

Fig. 4 – Assumptions and metrics to validate

  1. Assumption: Users wish to receive alerts not based on a specific artist. Instead, they wish to receive alerts on all gigs within a specific genre and within their local area. Possible metrics to validate this assumption: (a) number of alert sign-ups (b) ‘click-through‘ on alerts and (c) conversion on concerts listed (i.e. ticket purchases).
  2. Assumption: Users like having immediate access to a list of Hip Hop releases and gigs on the go using their smartphone. Possible metrics to validate this assumption: (a) number of app downloads (b) cohort analysis, e.g. comparing usage by recent sign-ups to non-recent sign-ups (c) number of retweets and shares of release and concert info and (d) conversion on releases and concerts listed (e.g. ticket purchases and purchases/downloads of releases listed).
  3. Assumption: Artists and promotors wish to interact with the app by providing gig or release info. Possible metrics to validate this assumption: (a) number of artists providing release or concert info to HipHopListings and frequency (b) number of promoters providing release to HipHopListings and frequency and (c) conversion on releases and concerts listed (e.g. ticket purchases and purchases/downloads of releases listed).

Related links for further learning:

  1. http://www.digitalmusicnews.com/permalink/2013/20130206concert-attendance-down
  2. http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html
  3. http://www.svproduct.com/product-validation/
  4. http://www.slideshare.net/JasonDavis5/jdavis-strata-eubigdatabigchanges

Use your brains to fly a helicopter

When you think that flying a miniature helicopter solely through using your brains is impossible, then think again! I recently found out about this company called Neurosky and how it has now come up with a miniature helicopter that users can control through their brains.

Neursoky is a company that specialises in “bridging the gap between technology and the human body.” Its instruments measure brainwave EEG and heartbeat ECG signals to help entertain, relax or exercise our vital organs. Neurosky essentially creates bio-sensors which help detect brainwaves and body sensations. Together with its partners, Neurosky has developed products that help converting body signals into concrete actions such as flying a miniature helicopter or using a mobile phone.

Whilst I’m still learning more about how the underlying technology works, let me make a start here:

  1. Brain Computer Interface technology – Brain Computer Interface (‘BCI’) technology is what underpins Neurosky’s products. BCI essentially takes electrical brainwaves and processes them into digital signals to make measurements available to power the user-interface of games, computers and investigational medical applications.
  2. Use your brains! – Our brains are made up of lots and lots of brain cells called neurons which use electricity to communicate with each other. These ‘inter-neuron interactions’ produce a large amount of electrical activity in the brain, which can be detected using sensitive medical equipment (such as an EEG). Don’t think for a minute that I’ve suddenly become an expert on the human brain. Instead, all credit goes to “Dr. Hugo” who goes on to write about the different brainwave types such as “beta” (an alert state) or “alpha” (a relaxed state). You can use these different brainwave types to control a device, makiing it do the things you want it to based on your ‘state’.
  3. How Neurosky uses BCI – As I mentioned, the core of Neurosky’s research and technology concentrates on detecting electrical brainwaves and converting these into digital signals to make measurements available to power the user-interface of games, computers and other applications. In simple words, this means that if you’re using one of Neurosky’s products in a relaxed state, this will have an impact on how you use your mobile device (see Fig. 1). Similarly, if you really concentrate on getting your miniature helicopter up into the air, you will (eventually) get it to fly (see Fig 2.).

Main learning point: the research and technology which Neurosky and its partners use is fascinating stuff. Combined with the developments we’ve seen in wearable technology (think Google Glass and Vuzix M100) I reckon this will be an area that we’ll see a lot more of development over the coming years! Can’t wait to drive a remote controlled car using my brains!

Fig. 1 – Demonstrating Neurosky’s technology
Fig. 2 – Demonstrating Puzzlebox Orbit