Transformation Defined

By Jon Moore and Marty Cagan

There are so many anti-patterns when it comes to transformation. 

Many of us have witnessed failed transformations, but few have witnessed true successes.  Which makes the lessons learned from successful transformations unusually valuable.  We intend to write much more about both the anti-patterns, and the lessons from the successes.

Defining Success

One question that we get quite frequently is, “what can a company that has transformed do better than a company that hasn’t?”

Since we in the product world talk a great deal about outcomes and results, we think that’s the right question.  And we have been emphasizing the capabilities and results of those companies that have transformed, especially the ability to respond to threats and exploit new opportunities.

But assuming the leaders of a company believe they need to truly transform, what does that really mean?

Many of you have heard us say things like: “transforming to Agile may be necessary, but it’s in no way sufficient.”

Or, “the heart of transformation is moving from feature teams to empowered product teams.”

Or, “the goal is to transform to a product-led company.”

Moving To The Product Operating Model

While each of these comments may speak to a specific aspect of transformation, they don’t give a good holistic picture of what is truly meant by transformation.

So, recently, we’ve begun to take a different approach.  

Instead of applying a label (“Agile,” “Empowered Teams,” “Product-Led Company”), we find it useful to look at what is actually changing:

Changing How You Build and Deploy

Despite Agile being around for so many years, there are still far too many companies stuck doing quarterly (or worse), big-bang releases.  The rise of fake agile lets these companies fool themselves into thinking they’re Agile, without actually improving how they build in any meaningful way.

Our company and our customers need us to have reliable, consistent and frequent delivery vehicles.  If you’re not doing continuous delivery, then at the very least you should be doing true releases no less than every two weeks.  Note that you don’t actually need Agile methods to do this, but moving to Agile is often the forcing function to achieve this.

See here for more details on changing how you build.

Changing How You Solve Problems

This is the core of what is meant by moving from Feature Teams to Empowered Product Teams.

Instead of stakeholders prioritizing their perceived solutions (features and projects) and providing these in the form of a roadmap to a feature team, now the product team is assigned problems to solve, and the product team is empowered to discover a solution that is valuable, usable, feasible and viable.

In practice this means developing the skills to do product discovery, and ensuring that your engineers and product designers have a true product manager (skilled in the customers, the data, the business and the industry) so that the product team has the necessary cross-functional skills to succeed.

It’s important to note that this change implies a new relationship with the company stakeholders; where the product team moves from a subservient relationship, to a collaborative relationship where the product team must discover a solution that the customers love yet works for the business.

See here for more details on changing how you solve problems.

Changing How You Decide Which Problems To Solve

Getting skilled at product discovery so that your teams can consistently and quickly solve hard problems in ways that your customers love yet work for your business is a significant leap forward by anyone’s definition, but it doesn’t address the question of “how did you decide this was the most important problem to be solved?”

Every company faces many threats and many opportunities.  Which threats you take seriously, and which opportunities you decide to pursue, can mean the difference between success and failure.

A strong product-led company has a compelling product vision, and an insight-based product strategy to identify the most critical problems to solve in order to deliver on the business objectives.

See here for more details on changing how you decide which problems to solve.

A couple of important notes:

First, all three of these changes depend on strong product leaders (leaders of product management, product design, and engineering), and hopefully you can see why product leadership is hard.  The people on the product teams will require coaching and strategic context.  If your product leaders do not have the necessary skills themselves, then this is where finding a product leadership coach is key.

Second, it sounds intuitive to treat each of these three as steps in a progression, and indeed this would be one way to approach a company transformation, but they can in fact be pursued in parallel.  Rather than thinking of these three as a progression, we typically recommend to instead pursue all three (or whichever subset has not yet been accomplished) in parallel, but doing so with one or a few pilot teams, or a subset of the organization, and then expanding the transformation from there.

So to summarize:

Changing how you build and deploy means moving from big quarterly releases to a cadence of small, consistent releases.

Changing how you solve problems means moving from stakeholder-driven roadmaps and feature teams, to empowered product teams given problems to solve, and then using product discovery to come up with solutions that are valuable, usable, feasible and viable.

Changing how you decide which problems to solve is typically the most profound change of all, as this drives what opportunities you choose to pursue, and how you make the most out of the investment you make, including product vision and product strategy.

Hopefully this framing can help you think more holistically about the transformation that your company may need, and where you may be on that journey.

Special thanks to Chris Jones for his help with this series.