New transformation cycle - how to make those millions pay off
Each 3-5 years or so a larger org will spend millions on some sort of transformation initiative.
People will be brought in, new ways of working established, new strategy, new frameworks, new method…
Some will love it and adopt it. Some will tolerate it. Some will hate it or lose a job to it - or might leave on their own.
At first it will feel like progress - a movement, a change, a purge.
But when the dust settles and the coaches leave, a shortcut gets made here. Then there. Then something changes and it doesn't fit and the discussions are back:
"This is not how real <insert framework> is done" , "Actually we should be doing <other method> instead" or "We don't even have a proper problem/product/strategy"...
Soon enough people will be either advocating for the system, working around the system, or pushing for another system, and everything will start feeling a bit heavier, a bit slower and exhausting again, eventually and ironically prompting the next transformation.
Don't get me wrong - transformation is often more than necessary!
But it has a cycle, and when it "fails" it's almost always for the same reason: people disengaging.
There is a root-cause to that. I call it - the Clash of Expertise.
(aka cross-functional misalignment if you fancy a more corpo term)
Here it is:
Each company exists because it has products to sell.
These products need all sorts of expertise (dev, design, sales, marketing, compliance.. etc).
Each of those roles, exactly due to the expertise, has a completely different model of what good looks like. So each one is pulling in a different direction; optimising for something specific, likely important, for reasons not fully visible to others.
Then a transformation arrives, brings in a framework, a method, a set of expectations, and installs it full force across all those different realities and mental models at once.
The result is: it fits some, it breaks others, and a couple of millions later your team starts questioning wether the framework is installed properly or is it working at all.
There is a fix to that and it is not another framework.
It’s aligning the mental models across all the different roles - so that the framework can land.
"Ok, so you mean teaching each other what the other role does?" - you may ask.
Nope.
Aligning the mental models to the reality of a business.
Hear me out...
The actual purpose of a business is so simple - that it's borderline offensive to lay it out here:
Attract potential customers,
Convert them to try your thing,
And then to pay for it,
Again and again,
Do all this by spending less money than you can make,
So that you can collect profits and grow.
Every role and every initiative within product or not is serving one of those at any given time.
And not always the obvious one:
For example:
In some products complianceisthe feature that actually converts and keeps the customers. In others it's a cost-saving initiative that avoids regulatory fines.
Refactoring architecture can be an acquisition or retention play in one sector, a cost-saving initiative in another, and an overkill in a third.
A specific design choice or a feature can be an attractor or a converter for a specific audience or the reason a customer pays or leaves.
Any role, any project, any feature is affecting one or more parts of the business model in some way.
The goal of a transformation is to enable your company to adapt its teams fast, so it can orchestrate, decide and change direction based on what matters most in any given moment to eventually make profit. Do you need to attract more people? Are they falling off for some reason? Are your costs too high? Are you making enough money?
That is what agility is supposed to be for.
The problem is, without everyone internalising this simple model of business reality, your framework, your transformation, your system becomes yet another thing for your team to manage, improve and optimise - a job given to you by the product you paid for.
And your team’s expertise becomes a resistance mechanism instead of your advantage.
This is why I built Heads of Product® the way I did - as a simulator of reality - not a framework showcase. And this is what it does - it installs the simple model of business into every role that plays it so that your transformation initiative can land fast.
Plus it's fun to play - I've heard.
If this resonates with you... let's talk.
