Avoid Transformation Failure With Product Management

Introduction

Transformations are not new; they have a rich history from which we can learn.

Transformations have become an all-encompassing vehicle for change to disrupt, avoid disruption, reduce tech debt and improve efficiency through people, process and technology changes.

Sadly, many market incumbents’ track record of delivering results through transformation has been poor. While they were flailing, new and digital-first entrants emerged to take market share and attract talent to their younger, faster, digitally enabled workplaces.

Research from Bain, BCG, McKinsey, and other major consultancies shows that the average success rate of transformations is just 25%, with Bain reporting a tragically low 12% success rate. According to the large consulting firms, the top 5 reasons for failure are:

1. Leadership Alignment and Sponsorship (McKinsey, Bain, BCG)
2. Engaging the Workforce (McKinsey, Deloitte, Bain)
3. Comprehensive Change Management (McKinsey, BCG, Deloitte)
4. Realistic and Achievable Goals (BCG, Bain, McKinsey)
5. Adequate Resources and Capabilities (Deloitte, BCG, McKinsey)

Leadership alignment and sponsorship

Simply put, is the executive team's inconsistent expectations of the transformation's impact on their strategy, business model, operating model and technology. This article will explore this issue more deeply to understand where the pitfalls occur.

In addition to alignment and sponsorship issues, this article will examine the problems that arise when managing transformations as programmes or projects introduce and propose a more suitable methodology to increase the chances of transformation success, namely Product Management.

"Transformations are not merely about delivering new software features; they require a clear understanding of the interconnected changes to business strategy, model, and operations to achieve desired outcomes."

Nicholas Whitford, Product & Transformation Leader

Misalignment from misunderstanding

Transformations generally fall under two main categories:

1. Business transformations
2. Digital transformations

Within these categories, there are several types of transformations, such as service-to-product, technology, or commercial model transformations. Before diving into definitions, you will see how transformations relate to these key concepts for businesses:

Business strategy:

The markets they wish to compete in and how they plan on differentiating to win through their value proposition, distribution and value chain.

Business model:

How they will make and spend money.

Operating model:

(including technology): how the teams in the company operate to deliver the value proposition and enact the business model.

Business transformations can encompass changes to a business strategy and/or business model, along with operating model changes to support these changes. Digital transformations are a frequently used term for operational change where significant efficiency and effectiveness improvements are expected through technological innovation.

Here's an example to help make these concepts more concrete:

Imagine a magazine distributor looking to reduce operating costs who traditionally received phone calls for stock replenishments from their retailers.

The CTO suggests a contained digital transformation to shift these replenishment requests out of the call centre and into a new customer site, perhaps with an AI chatbot.

The core team in the CTO’s group crunched the numbers and proposed removing this capability entirely, as they observed that the retailer’s replenishment requests had introduced more cost than revenue into their magazine circulation.

The team understood the bigger commercial goal and proposed managing replenishments algorithmically with some oversight from the operations team.

The executives were excited at the prospect. The team had tested the new proposition with key retailers, while the tech team experimented with some basic algorithms and was confident it could deliver optimal solutions.

The team recognised that operational changes would be required as part of this transformation and this change might prompt commercial teams to re-examine the business model to see how they might pass the value of these changes back into their pricing or margins, particularly with larger retailers.

This example is very contained. An overarching business transformation will be high risk, as the volume and complexity of change can compound when bringing about extensive amounts of frequent, interconnected change. Transforming major capabilities, let alone a whole business introduces layers of interconnected complexity across strategy, business model and operational model.

The key takeaway is that the intention and goal of a company’s transformation of a company should consider the business strategy, business model, and operating model. This will go a long way to addressing why transformations fail leadership alignment and sponsorship. If the executive team is unclear on which parts of these three key tenets of their business are changing, then they’re unlikely to succeed. This misalignment at a senior level leads to missed opportunities to create excitement, motivation and capacity to integrate the change in their teams.

Looking at reasons 2 (engaging the workforce) and 3 (comprehensive change management), the large consulting firms attribute failed transformations; it’s clear that misalignment at the top of the organisation will likely trigger an unwanted domino effect on the transformation effort.

Projects failing to deliver outcomes

Most transformations are digital or heavily reliant on technology, and they are typically managed as large programmes – cohesive collections of projects designed to deliver change. Project and programme success is often characterised by the release of a product or features, the early adoption of a new management system, the closing of a commercial deal, the removal of some legacy technology, or the company’s move to “agile” development.

The fundamental breakdown comes from project stakeholders expecting revenue or cost benefits to be delivered by the project. In contrast, those working with a project model and mindset think their job is to deliver the outputs on time and on budget and that others will harvest the benefits of their deliverables.

This fundamental breakdown in the project-model is that the team and its stakeholders believe the formula for success looks like this:

The project will deliver outputs which will deliver outcomes.

Project = output = outcomes

The equation should look more like this:

The project will deliver outputs which may deliver outcomes dependent on the likelihood of the outputs being adopted.

Outcomes = outputs X likelihood of adoption/success

So often, the first equation is how transformations, projects and product launches are expected to work. They focus on outputs and assume that the outputs will deliver success. But this is not how most things in life work, especially when groups of people are involved in delivering and adopting change.

Deterministic vs. probabilistic and the fallacy of control

Project = output = outcomes

The project model assumes that outcomes are deterministic, meaning that delivering the project's output will directly lead to success.

Outcomes = outputs/likelihood of success/adoption

This outcome-based model believes that outcomes are probabilistic and risk-based, appreciating the likelihood or probability that they will be achieved.

A significant component of the belief system behind the project model is based on a sense of control, especially for internally facing projects and transformations.

“If we install this new system and define the process people must use, then we will achieve the outcomes we want.”

Projects rarely play out like this. Adoption may take off and then fizzle out as people go back to spreadsheets and shadow processes, or there may be poor adoption of the new technology or process to begin with.

This is a phenomenon all too familiar in the product management world.

It’s taken a few decades for businesses to realise that launching a product does not automatically lead to commercial success. The adoption of the product is what drives the outcome that’s important to the business.

Product Management

Product Management is an outcome-focused discipline. Despite what the name suggests, shipping and managing a product is only part of the job. The higher goal is to ensure the product being shipped is either a direct or contributing factor to revenue growth or reducing operating expenses, and these might be acknowledged through proxy metrics that describe the value customers are getting from the product.

Excellent product practices increase the probability of success related to the three key tenants of technical feasibility, business viability, and customer usability in a product, whether internal (e.g., a workbench used by operational teams) or external (e.g., a monetised product).

Acknowledging that product and technology adoption is outside any perceived realm of control is baked into the product mindset, which, therefore, takes a probabilistic, risk-based view of product launch and management.

In practice, product management analyses the current situation, rapidly tests ideas and assumptions, and minimises confirmation bias to find solutions and opportunities to deliver the desired outcome. This is not a one-and-done exercise. Product teams work through rapid feedback loops using prototypes, working groups, and restricted launches, among many other techniques and tactics, to identify risk areas, assumptions and ultimately, solutions with the highest chance of success before building out their product or solution. Mature product teams take this test-and-learn approach to more than just the products they build, often testing and learning the best ways to go to market, deliver change programmes and maximise ongoing adoption. Unlike project teams, product teams are “long-lived”, meaning they take ownership of a valuable capability and own its delivery, ongoing enhancement and value realisation. They are not confined to projects that start and end. They are in it for the long-haul, with a view to continuously delivering value.

Many organisations have taken an initial step to conduct some of these product management activities as part of becoming “Agile” but they’re often part of a project with teams incentivised to hit deadlines and budgets. When things inevitably don’t go to plan, panic sets in, and the number of feedback loops are reduced, with the risk of delivering the outcomes greatly increased. Often, the project has a setback when creating a plan to build a barely tested solution. This major pitfall of creating a plan and schedule to create a sense of predictability and control usurps the activities that increase the chances of true success for the project.

As an organisation’s product management maturity increases, so does the product team’s empowerment. This means they are empowered to solve problems, not just build features or solutions.

Think back to the call centre example: the team was focused on a goal and developed an innovative and enduring solution that would deliver more value to customers (no need to request replenishments) and the business (no cost in handling requests). Imagine this scenario where the team was told to build a customer site, missing an opportunity for a more scalable and commercially impactful solution at a higher cost.

Product Management and Transformation

Let’s revisit the main reasons for transformation failure (below) and consider the huge interdependencies across people, processes, culture, technology, customers, etc. Knowing that these factors reduce the probability of delivering outputs, let alone outcomes, it becomes all too clear why transformations fail.

1. Leadership Alignment and Sponsorship (McKinsey, Bain, BCG)
2. Engaging the Workforce (McKinsey, Deloitte, Bain)
3. Comprehensive Change Management (McKinsey, BCG, Deloitte)
4. Realistic and Achievable Goals (BCG, Bain, McKinsey)
5. Adequate Resources and Capabilities (Deloitte, BCG, McKinsey)

Product management addresses the fact that all change comes with risk and probabilities of success, so it makes perfect sense for organisations to start taking a product management approach to transformation.

Many organisations have realised the benefits of this approach and are now taking a product approach to most of their technology efforts, internal and external.

This shift to embracing a product management approach is covered in the recent publication by Marty Cagan, Transformed, which describes this overall shift to embracing a product operating model. This approach was previously branded as product-led, but this term is being abandoned due to the misconceptions it stirs up, especially that the product team will “take over” the business.

A product approach to transformation sounds promising, but there’s one well-worn lesson that can be hard to swallow. Transformation throughout an organisation can bring significant benefits, but you must start small, given the risks.

The key tenant of product management to continuously test and learn is the secret weapon to reducing risk. By reducing your unknowns through curiosity and continuous learning, you never stop finding ways to unlock the benefits of change and never stop looking for new benefits that transformation can bring.

By starting a transformation effort in a relatively small area, you limit the risk and variables while learning about the cultural, people, process, and technological changes it enabled. Those learnings can be fed into the next iteration of the transformation journey. As you work through this, the unknowns and assumptions will reduce, and your strategy for affecting the outcomes you’re shooting for will increase.

If you’re a senior leader reading this, you probably want to know whether the transformation will be worth it before you start. If you spend millions bringing about change, how will you know it will be successful or worthwhile? Again, start small. What is the biggest pain point in your business? Transform that area. Hedge the bet that transformation will pay off by reducing the blast radius while increasing the potential upside. If you empower teams to solve the problems and own the outcomes, then they will be motivated and incentivised to find the best risk-balanced outcomes to shoot for.

Conclusion

If you're considering a transformation of any type, avoid the misconception that delivering new software features, installing a tool, or launching a product will automatically yield your desired outcomes. Understand that real risk is associated with all these efforts that go far beyond the risks of delivering new technology.

Be clear about the scope of your transformation: Is it purely operational, or does it affect your business model and strategy? Is your leadership aligned on the journey you’re embarking on?

Are the leadership and teams delivering the transformation taking a deterministic or probabilistic approach to delivery and risk? In other words, does your delivery management factor in the need for continuous learning and adjustment to deliver your desired results? Dare I ask, is it agile?

Do you have the right people, skills and experience to take a product management approach to leading and delivering transformation?

Will you start small and grow the footprint of your transformation?

If you’re set up well for success, the good news is that by iterating more frequently, you can look forward to learning and celebrating more frequently, building insights, momentum and a culture that can continuously transform and win.