Transformation as a Product

In these cost conscious, competitive times everyone wants to accelerate digital transformation, and get ‘there’ quicker.  Often ’there’ is clear, but the route, and how to bring everyone along, far less so.  The result is that after a promising start, transformations stall and don’t offer the espoused benefits, people are distracted by change, productivity drops, stakeholders are confused and patience runs out at every level.

Look for backup and you’ll find an abundance of high level steps, comfortingly simple diagrams and witty backronyms.  These are a fine source of inspiration, but describing is easier than doing and the nitty gritty, the graft, that keeps momentum behind successful transformations is less glamorous and rarely documented.  The same applies when that slick framework doesn’t quite fit, or your actual situation is slightly different to the book, which in my experience, it nearly always is.

Although frameworks and methodologies are often blamed, part of the issue is how transformations are approached and the business of managing change.  

One approach I’ve found successful is to treat the transformation as a product in its own right, fully adopting a product mindset.  This reflects the uncertainty of the environment in which the work is unfolding.  It encourages long term commitment and adaptive planning, inspires an experimental entrepreneurial mindset, balanced against increased rigour around feedback, planning and user centred design.  It also prizes small steps and longer term investment, rather than quick fixes.

Finally it helps steer away from a directive approaches to a more coaching, collaborative stance, more likely to foster engagement, contribution and lasting change.

Quick note on the title, which avid agile archaeologists may recognise from Joakim Sundén’s insightful keynote at Agile In the City Bristol in 2024. I’d hate for you to think I’ve stolen it. In preparation for the conference Joakim described his ideas for transformation, with similar approaches to mine, so I mentioned I called the notion 'Transformation as a Product' which seemed to resonate. So now you know, and now you have two sources ;-)

Photo by Pixabay

Why treat transformation as Product?

The key difference in thinking from a top down project approach is to recognise that introducing change into an organisation is more like developing a product for a new market.  It is full of uncertainty with unpredictable users, no real way of knowing how things will land or whether the ‘right’ outcomes will occur.  Admittedly, unlike many commercial products, organisations are able to compel their contributors to adopt new ways of working, but this kind of coercion can lead to minimum compliance, low discretionary effort and degrees of resistance.  

So the primary reason to switch perspective is that new technology, processes and ways of working are more likely to be adopted and used long term, without seriously damaging performance or disenfranchising employees and customers.   The concept may be contrasted with some common anti-patterns:

Transformation as-a-project - This is the most common approach, assuming that change can be predicted and delivered in phases with fixed time cost and scope.  The issue here is not so much the plan itself as the tendency to neglect discovery and start from an unrealistic state, coupled with a lack of responsiveness to how changes are received.

Perpetually imminent Transformation - Constantly promising change and transformation, but never quite starting.  Often used to placate, look out for phrases like, ‘Once we get this deadline done’.  By thinking in product, or start up terms, we can at least make small valuable steps.

All talk transformation - Adopting new methods takes time and a blend of approaches to enable people to understand and master new ideas.  It's not unusual to find a heavy focus on top down comms and class room training, but a distinct lack of investment in activities which embed and evolve practices, such as learning time, communities, mentoring and coaching.   

Photo by Ron Lach

What kind of product? / What are we making?

If we’re talking product, we need to dig into what kind of product our transformation is.  This will tell us how to design, build and run it, who our users and stakeholders are.  It will help understand investment, drawbacks and expected benefits, signs of success and failure. 

Phrases like “We are going to build a modern agile cloud based devops organisation” are not uncommon.  The trouble is these speak more to how we are planning to do something, the tools we are going to use, rather than what we actually want to achieve.  While a useful shorthand for practitioners, they presuppose a solution to the problem, and they neglect the ‘why’, which is key for teams to act with aligned autonomy.  It’s similar to having a poorly running car and declaring “We are going to spanner”.

We need a better way to articulate what our product is supposed to do, and how we’ll know it’s working. The why binds it together and reminds us not to get bogged down in unproductive dogmatic conversations about which method is superior or what modern means.  A strong clue is why the business asked for the transformation in the first place, and why it’s willing to invest in it.

For example the Toyota Production System could be viewed as a product which “aims to eliminate waste and achieve the best possible efficiency” in order to build quality vehicles.  You’ll note that while this includes multiple lean methodologies, processes and behaviours these are not considered the goal.

You’ll also note that this is a business outcome for the product, not what it offers people working at Toyota or its customers, the transformation product users.  So while our product creates business outcomes, the lens on the product created and sold by the transformation team is subtly different.   In simple terms it's a collection of processes, tech, ways of thinking, behaving and working that are likely to contribute to a specified (and ideally specific) business goal, a set of initiatives to further these outcomes. 

From an internal user perspective the transformation could be likened to an app store, enabling people to learn and select a range of tools to achieve differing goals.  It may contain simple and complex solutions, fledgling and mature items, duplicates and alternatives. The collection of tools should be wrapped a coherent, engaging  and trusted experience, so people want to use it, and provide mechanisms for feedback and contribution.

What you have is a Three Product Problem: What it is to the business, what it is to internal users expected to change significantly, and what it is to stakeholders.  There is a need to consider them all, but in terms of getting traction for change the latter two are where the emphasis should be.

Change Capability, the crucial by product

There’s another element which is often overlooked, a vital product of our transformation is change capability.  From a strategic standpoint, the more frequently or radically we want our organisation to adapt the more important this becomes. 

Change capability is an organisation (or team’s) ability to respond to change whether it be a challenge or opportunity, internally or externally motivated.  A good change capability leads to timely adaptations to make the best of situations, in a way that is sustainable for the business and it’s contributors.

"A learning organization is an organization that is continually expanding its capacity to create its future. " - Peter Senge "The Art and Practice of the Learning Organization"

Organisations (and people) who pivot successfully time and time again are good examples of this, they are set up not only to sense an opportunity but to do something about it.  This capability is baked into the organisation, its part of culture and attitude.  

You’ll note a parallel with successful athletes and musicians: they develop skills in a discipline and to get there develop a crucial transferable skill, a training mindset.  Their training mindset is a long term investment and part of how they can be successful in other, quite different, disciplines like Cycling, Horse Racing and Jousting.

In tandem to change capability we are also encouraging and demonstrating a learning mindset, both in terms of new practices and how to approach the transformation.

Photo by cottonbro studio

Who Uses Our Transformation Product?

If you want product-market fit you need to understand your users, and this is where viewing our transformation as a product gets tricky, but it also guides attention towards a stumbling block; gaining and keeping support.  

We should recognise that people in our organisation, internal users, have a choice about whether or not to adopt our product, and how enthusiastically.  It's a kind of discretionary effort applied to change.  

Our internal market is already saturated with ways of working, and there is enough to think about already.  We’re not just asking for people to try challenging things, we are asking them to put aside familiar approaches, some tied to their beliefs and professional identity, the culmination of years of work and training.  In short, leads are asking, and occasionally ordering, them to step into unfamiliar, vulnerable territory.

By thinking more about our users, and viewing them exactly as they are - smart, busy people with a choice, we are guided towards better research and user centred design, to understanding the problems they want solved.  It also speaks to a listening, engaging and coaching approach, which in addition to getting support is more likely to create active contributions, the volunteer army in Kotter speak.  

With transformation I often think about the old saying: “No one will thank you for solving a problem they don’t have”.  If we are leading with ‘we are going to use Safe’ or ‘We want efficiency’ some might reasonably ask “what’s in it for me?”.   Our user centred approach to transformation means we should have a good answer (or at least assumptions to test) and take time to learn what expectations people have and what they would see as positive outcomes of the transformation.  This is the value proposition of our product.

Of course our users are not all the same and it pays to consider different cohorts.  In particular there will often be a greater burden of change on some groups than others.  Often stakeholders are required to change less than people responsible for design, planning, delivery and operations.  Paradoxically senior stakeholders are also often the people who can make the biggest difference to transformation.  Consider for example the effect of agile budgeting compared to yearly cycles.

Closing Thoughts

I often see change treated as a project, with predefined phases, investments and outcomes, while this is backed with a theoretical understanding of how people react to change, it seldom incorporates feedback, responds to what is actually happening, or considers the rate of mastery of new techniques. With a plan divorced from reality it's hard to know where you actually are, even if you know where you are going.

Grand transformation plans rarely survive first contact, ironically for the very reasons people were hired in the first place: they are productive, smart, collaborative and have their own ideas.  They are also very busy.  It is often assumed that employees can be told what to do and how to behave but just like external users they make a choice, conscious or not, about how much to engage, if at all.

Transformations are frequently explained through the advantages to the business, rather than contributors.  To be successful we should speak to both.  Organisational benefits arise from outcomes produced by internal users.  They are creating and adopting new approaches, in part because of benefits to themselves.

Treating Transformation as an product encourages the kind of rigour applied to a new product or venture, including an experimental user centred approach, adaptive planning and a strong focus on engagement and community contribution.

In the next post I'll build on the theory and cover principles and practices.