How Spotify Develops Products

Here’s something well worth downloading. Henrick Kniberg, an ‘Agile Coach’ at Spotify put together an extensive overview of the product development process the company uses (h/t @gmacgregor).

Spotify’s core product dev principals:

We create innovative products while managing risk by prototyping early and cheaply.

We don’t launch on date, we launch on quality.

We ensure that our products go from being great at launch to becoming amazing, by relentlessly tweaking after launch.

And 4 stages of product development:

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)

Regardless of how you or your company does product development, there is lots of worthwhile reading here.

Probably one of the biggest shifts in thinking is in getting away from working towards a launch date, and instead shipping when the product is ready. As detailed in the Ship It stage, this doesn’t mean endless development cycles trying to perfect every last detail (done dangerously, in the absence of actual users to validate your assumptions). The short goal is to produce an MVP 1 good enough to ship to a small percentage of users to observe and gather data to determine what refinements need to be made. The actual ‘Launch’ is the day you promote your product on the home page and the press releases go out, even though many of your users were aware of what you’ve been working on for some time. Isn’t putting out the right product (that works) far more important to the company than hitting a self-imposed internal launch date that none of your customers know about?

The second thing I think is traditionally overlooked is the commitment to the ‘Tweak It’ phase, which is particularly challenging if your organization is very project/budget focused. Managing commitment to ongoing improvements to active products is a tough nut to crack – certainly it’s much better if your organization has resources organized around products, not projects (as I’ve written previously).

Henrick has produces lots of great stuff on product development process and scaling Agile – here’s a YT vid on the role of the product Owner (hey – that’s me!) within an Agile team:

…and here’s a post on how to scale Agile within a large organization posted at Henrick’s own consultancy blog.


  1. Minimum Viable Product