Baking the Flywheel into your Development Process
By Shira Berkovich
When you are just starting out in product management, you may think that as soon as you develop the new feature your customer asked for all your problems will disappear.
The truth is that when you come up with an idea for a feature, you hope it solves your users’ problems. In reality, however, the chances of that are quite low.
Marty Cagan, one of the most influential people in the product space, calls this the “two inconvenient truths about product:”
- At least half of our ideas are not going to work. Why? Either the users are not as excited about the idea as we are, so they simply don’t use it, or they try to use it and it’s just too complicated. Both results are the same: The user chooses not to use it.
- There is very little chance you’ll get it right the first time. Even if you came up with an idea with great potential, it would take several iterations of improvements to fine-tune the feature so that it delivers the intended business value.
As a professional with fifteen years’ experience in different software development roles, I completely agree with Cagan’s analysis that there is just no escaping these truths.
A more effective approach that has become very popular is to manage by the desired outcome. In other words, start with the end result in mind and work your way backward. Ask yourself what success looks like and which metrics determine it.
Using this approach, success isn’t defined by the release of a feature, but by the achievement of results you’ve defined ahead of time.
In this article, I will focus on a concept that I’ve personally found to be a helpful framework for creating the systems required for an outcome-based approach called the “The Flywheel Effect.”
What is the Flywheel Effect?
The Flywheel Effect, coined by Jim Collins’ monograph Turning the flywheel, is the idea that good companies don’t just suddenly become great companies overnight. There isn’t a single defining action, killer innovation or miracle event responsible for that success.
Instead, it’s compared to turning a heavy flywheel. At first it barely moves, but when you keep pushing it with great effort, eventually it overcomes the inertia. Push by push, the wheel starts accelerating. As you make a series of good decisions, each turn builds upon previous work that is supremely well-executed. Then at some point — breakthrough! The flywheel flies forward with almost unstoppable momentum.
It’s a gradual process that takes plenty of time, hard work, discipline, creativity and deliberate action toward the destination.
Let’s have a look at Amazon’s simplified Flywheel example, to get a better understanding of this concept:
In this model, you can see an important aspect of the flywheel according to Collins. Each component in the flywheel isn’t merely the “next action step on a list,” but almost an inevitable consequence of the step that came before. If you nail one component, you’re propelled into the next component, and the next and the next — almost like a chain reaction.
Over time, Amazon would renew and extend the flywheel far beyond a simple e-commerce website and enhance the flywheel with new technology accelerators. Throughout this process, the underlying flywheel architecture remained largely intact, creating a customer-value compounding machine.
At this point, you may be thinking to yourself, but I’m not the CEO of a company, I am only a Product or Development manager — how does this model apply to me?
Since I’ve learned about this concept, I’ve come to see that there is an underlying flywheel anywhere you find continuous success: successful schools, medical centers, sports dynasties — and software products.
Applying the Flywheel Effect to your Software Product Development
Looping back to outcome-based management, I believe that understanding the flywheel can accelerate your product by building the systems that help you achieve the desired momentum in development.
Let’s look at an example from a year ago. My team started developing a product that would replace the legacy production system with completely new code. The whole point of this new system was to allow better scale and enable R&D to develop and test their code in a production-like environment, which they didn’t have access to before, improving the lead time for new feature releases.
You can probably guess what the main challenge was here — it’s an all-or-nothing situation, with no small minimal viable product (MVP). But the new system is supposed to launch with all the existing production environment features — a huge amount of work!
To complicate things, there was a lot of pressure to launch since many strategic company-wide projects were planned to be built on top of this new system. Understanding the flywheel architecture behind our product helped us stay focused on the things that really mattered.
So how did we create the flywheel? Let’s take a closer look…
Creating Our Product’s Flywheel
To create our flywheel we followed Collins’ guidelines:
- We made an inventory of the components that led us to successful or failed products in the past.
- Following this list, we identified components that may belong to our flywheel.
- We simplified the list by narrowing it down to four-to-six components, arranging them so that each step is the inevitable consequence of the step that came before it.
- We tested our flywheel against the inventory of successes and failures. Our empirical experience validated that these steps led to success.
As you can see in the results, a flywheel doesn’t necessarily have to be unique and can apply to many similar products.
Here are a few of the lessons we’ve learned from our flywheel….
What We’ve Learned from Our Product Flywheel
Here’s what we learned should be done to make the wheel turn and eventually fly, achieving the compounding effect and the goal we are all looking to reach — short lead time.
- We must drive usage , Regular meetings with the users (also №2 in the Flywheel) are necessary to get their feedback and understand how to improve their lives.
- To improve (for the wheel to turn), we need to measure the failure rate and performance (№2 in the Flywheel) and create the tools that collect this data, establish weekly sessions to review the previous week’s results and discuss what should go in the backlog.
- For significant improvement of these metrics, we must give the team time to explore and play with different ideas.
- Since the system is partially open source, we need to make it easy for everyone to develop new features with good architecture, automatic testing, gated PR and great documentation (№4 in the Flywheel).
But goals are set in the future, which means you are in a constant state of underachievement until you reach them — and no one likes being an underachiever.
And that brings us to the best part about the Flywheel. 😊
The Flywheel as a Mirror of our Success in the Present Moment
In his excellent book, Tribal Leadership, Dave Logan and his co-authors give a definition of outcome that aligns perfectly with the benefits we found in the flywheel:
“Outcome is a present state of success that morphs into bigger victory over time. In fact you have already succeeded and this is what it looks like at this stage in the process.”
Runner Carl Lewis also illustrated this principle when he said that he ran while the others raced. He had already seen himself winning long before the race had begun, and the race was merely the unfolding of his vision.
Similar to this vision, the flywheel is a tool that shows success in the progress of each turn of the wheel. That’s why it does not contain any metrics. With each turn of the wheel (e.g., stage of the project) there is a different set of metrics (outcomes) that change and improve, both bringing us closer to the goal and allowing us to celebrate our success in the present moment.
