Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

The Improvement Flywheel

Freshness Warning
This blog post is over 3 years old. It's possible that the information you read below isn't current and the links no longer work.

Improvement flywheel system diagram

A few weeks ago on Twitter, John Cutler posted what he called "the wicked loop" of product development problems.

A team doesn’t execute well, which leads to pressures to deliver things faster. Those pressures come from both inside and outside the team.

In an attempt to deliver value and relieve this pressure, the team becomes reactionary to requests, trying to do more at once, and starts paying more attention to their output than what outcomes they want. They see small holes in their schedule and try and fill those with extra work.

The result is high work in progress, with everyone doing something slightly different. What used to be seen as teamwork starts becoming an interruption, and everyone spends half the day is doing things that aren’t known to the rest of the team. And because everything is depending on everything else, shipping gets harder and batch sizes increase.

The list of missed promises grows, less gets delivered, and because the team isn’t executing well, pressures increase.

Wicked Loop diagram

This feedback loop drives the team to become worse, not better.

But what John calls a Wicked Loop is also an incredible flywheel for improvement. Set it in motion and things will get better faster than you can imagine. The same things that cause a cascade of poor performance can also cause a cascade of improvements in the other direction.

Pick some quick wins and ship those fast. This starts gaining trust within the team and outside it that the team is capable of building quickly.

Use this trust to go back over the outstanding requests and reset expectations. Start telling customers and internal stakeholders, “not now, ask again later.” This reduces the pressure on the team and slows the tide of reacting to the loudest customer. The team can now align around some larger goals instead of jumping when a wheel squeaks.

Because you’re not reacting, you’re not trying to jam lots of things into the schedule, so your work in progress drops. You make all the Work in Progress visible and discuss with the team what’s causing that and how to do less at once. By doing less at once, you experience less context switching and you start working as a team again instead of a collection of individuals. Working as a whole team reduces handoffs and improves flow.

Your better flow means that your main efforts aren’t delayed any longer, that the team starts gaining a reputation for executing well.

You’ve built an Improvement Flywheel. (Click image for full size)

Improvement flywheel system diagram

You’ll fail at this if you try and change everything at once. You have to do it incrementally, especially where trust from outside the team is concerned. Pick off one thing from each of the four boxes and aim at that. You’ll find the rest starts falling into place.

Recently Written

Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13)
A description of how I use OKRs to guide a team, written so I can send to future teams.
Build the whole product (Oct 6)
Your code is only part of the product
Input metrics lead to outcomes (Sep 1)
An easy to understand example of using input metrics to track progress toward an outcome.
Lagging Outcomes (Aug 22)
Long-term things often end up off a team's goals because they can't see how to define measurable outcomes for them. Here's how to solve that.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2024 Adam Kalsey.