Tag Software development

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

Product-based development vs. Project-based development

A few months ago my director and I had lunch with a couple of colleagues from another big media company where I had worked as a product manager for a few years. They were interested in adopting Agile as a more nimble and cost-effective software development process, which is something the Globe and Mail started right around the time I arrived. The conversation brought me back to my previous role and the challenges of their ‘project-based’ development process.
In that world, projects would be identified and approved by senior management, assigned a priority and then handed down to the digital production team. Resources were organized as a matrix, so there was a design and UX team, a developer team, a platform team and so on. Sometimes a project manager would be assigned, otherwise the product manager would need to fill that role. The constant challenge was hanging on to your resources. If a higher-priority project came along and they need your designer, or developer or whatever, they got them, leaving you to scramble to fill the hole and keep your project on track.
It’s done differently at the Globe. In a nutshell, we have cross-functional Agile teams organized around products, so all the key components of the business – the publishing CMS, the video platform, community/social/comments, or advertising products (the newest product team, which I’m currently running) – have a dedicated Agile team responsible for those products.
The assignment of the teams is meant to be flexible to meet the needs of the business. If the organization finds it isn’t effectively addressing the inevitable site glitches and performance issues, it can reorganize resources to create a critical issues team. If you want to treat mobile not as a separate product category, but as an integral part of the editorial platform, then create a single team with mobile expertise that has responsibility for both web and mobile platforms.
But this is pretty obvious stuff. Agile is pretty much the new standard for software development, and if your company is not iterating on some version of Agile, you should probably find employment somewhere that is. The real advantage of creating product based teams is that the teams take ownership of the product. They stick with the platform and become the experts on its stresses, capabilities and potential. With the proper management structure in place, the broad, non-prescriptive business goals of senior management are communicated to the product teams, and the team members collaborate with business stakeholders to work out the best way to achieve those goals. Projects are scoped and budgeted based on estimates and technical input from the people who will be doing the work. When you’re handed a budget, a set of requirements and a delivery date without the input of the team doing the work, you’re probably in trouble (also see Iron Triangle).
Anyone working in digital knows the phrase ‘knowledge economy’ but too often the core of that idea is overlooked in how digital companies organize themselves. It’s been over a hundred years since Frederick Taylor published The Principles of Scientific Management, yet many (most?) companies are still organized around the idea that senior management understands exactly what needs to be done, and the manager’s job is to make sure the employees execute their tasks as efficiently as possible.
But in the knowledge economy, the power is reversed – or at least more evenly distributed. The keys to a successful product lie with the people on the front line – the coders, designers, your QA and infrastructure team. They have the actual expertise to execute, and the job of management is to empower them with information and the environment that they can execute successfully in.

Once your digital department exceeds a few dozen people it’s impossible for the people at the top of the org chart to know best to resolve technical problems or make the hundreds of UX decisions that go into a good digital products. The great idea or elegant solution is far more likely to come from a clever UW intern than your VP of Digital (something our VP of Digital surely would agree with). And the role of senior management then, is to communicate the business needs and create the environment where the experts on the platform can effectively figure out the solution. This is another area where Agile really excels – but we’ll leave the for another post.

Reading List:

Agile Software Development, Principles, Patterns, and Practices Robert C. Martin – a great all-round guide to the nuts and bolts of working with Agile.

Succeeding with Agile: Software Development Using Scrum Mike Cohn – more focused on how to adopt Agile within an organization. Essential for managers and up if your organization is adopting or thinking about Agile.