Driving product change - how to choose evolution or revolution?
While reading a book I came across this description of evolution:
”The basic ingredients for evolution of life are straight forward. You need: lot of suffering. Lot of struggle. Lot of time”.
This statement in its simplicity really hit a point and made me reflect on the evolution of organizations and how I tend to approach them.
Many times I found myself talking and thinking of organizational changes as evolutions - meaning that as things change around us, we adapt and transform, making incremental changes to our product organization in the exact same way we make incremental changes to our products. I many, many times praised and syndicated for evolution over revolution.
If I reflect upon it, really often I even describe the changes we make as ”this is an evolution, not a revolution”. The main reason?
I believe evolutions are easier to accept, easier to handle, require fewer changes, and can bring incremental improvements. And small incremental improvements are better than a big bang. This is the engrained mantra in my product brain, that I (almost) follow blindly as “this is what I’ve seen work”.
Or so I thought.
Reading that sentence really made me reflect on the flip side of my evolutionary approach.
What if by doing all these incremental changes and keeping them small and continuous, what I am really doing is expanding the time of the change that I want to see? What if smaller changes all the time are not always preferable and what we really need is instead a real and proper revolution?
It is given that the choice between evolution and revolution is highly contextual, and cannot be generalized. And I also believe it is given, or so it has been in my experience, that you can drive multiple evolutions at once, while you need to be quite careful with the number of revolutions you are starting and how often you start them. Revolutions take time, change management, and will in time erode trust if they are misused.
There are clearly downsides and upsides for both approaches, so the real question becomes:
how do we choose if we need an evolution or a revolution? And how do we make sure that we do not default to the solution that you are most used to or comfortable with?
Reflecting on how I drove product change in my career I pinned down some general principles that worked for me. And spoiler alert, this was based on total aftersight, as I tend to gravitate towards evolution. But it was a really healthy exercise to remind myself not to go on auto-pilot, and really evaluate the approach I choose based on the real problem at hand.
What is your approach to evolutions and revolutions?
