Enterprise Agility: Understanding Spotify’s Approach to Product Development/Planning
Spotify has a unique approach to enterprise agility. Spotify’s approach to product development/planning is deeply rooted in the Lean Startup approach of “Think it, build it, ship it, tweak it.” Here’s how it works at Spotify:
- Idea/Problem: Somebody in the company has an idea for a feature. Research is conducted to determine whether the idea is likely to deliver value to the customer. Squads seek to answer the questions: Do people really want this? Does this solve a problem for them?
- Narrative: The squad writes a story, sort of like a press release or elevator pitch, that describes the benefits of the proposed feature.
- Hypothesis: The squad makes an educated guess about how the new feature will impact some metric that’s important to the company, such as frequency of logons or number of shares.
- Prototypes: The squad builds several prototypes, and various people test them to see which is best and to see whether users find the new feature valuable.
- Minimum viable product (MVP): If, based on the results of the prototype testing, the feature is deemed worthy to build, the squad builds an MVP.
- Gradual rollout and tweaking to perfection: The squad rolls out the MVP to a tiny percentage of uses, measures its impact, and tweaks the feature. It repeats this process until the product is “done” — it has the desired impact.
Changing the game plan for larger products
While Spotify’s usual approach works for small products, such as a feature, it’s less successful for large, complex products. Spotify tries its best to steer clear of larger products by breaking the product down into smaller products, so it can use the “Think it, build it, ship it, tweak it” approach. However, if that’s not an option, it takes a more traditional approach to product development.
For big products, Spotify adds a small, tightly knit leadership group, which typically includes a tech lead, product lead, and (sometimes) a design lead. The leadership group isn’t exactly management. They don’t assign and supervise work. Their function is to communicate the vision and maintain alignment among the squads and tribes.
The squads track progress visually using a Kanban board. They conduct daily syncs to facilitate coordination and collaboration and ensure alignment. And they produce a weekly demo to check how the product is coming along. The idea is increase collaboration and reduce risks by keeping the feedback loops as short as possible.
Spotify sees big products as a major source of risk, the biggest risk being building the wrong thing.
Having a system owner
For large enterprises and large products, Spotify recommends adding a role called a “system owner.” Even though “system owner” sounds like one person, it’s actually the role of two people — a developer and an operations expert, each of whom works in her own squad. Every so often (on “system owner day”), they get together to make system-level decisions.
The system owner role is based heavily on the DevOps (development and operations) role, which is an attempt to combine two roles that may seem incompatible at first glance:
- Development: Development is more in the sphere of agile, relying on innovation and experimentation through frequent iterations to achieve continuous incremental improvement.
- Operations: Operations relies on planning ahead to make sure all components or systems of a product work seamlessly together.
Having a systems owner is an attempt to strike a healthy balance between predictability and innovation on large products. The system owner should always be pushing to achieve a healthy balance between frequent changes and the stability of the whole.