4 Different Ways To Transform a Product Organisation

You can't just keep saying "Outcomes over Outputs" until the exec team gives in

Hi there, loyal reader! I would appreciate some feedback on my newsletter in general. It will only take a couple of minutes and will help me to provide you with the very best content that resonates with your needs - please be honest!

---

A couple of short weeks ago, I found myself giving talks at two events in the same week. Thursday was a ProductTank in Cardiff, but on Monday, I was speaking at a conference in Amsterdam. I was privileged to share the stage with Marty Cagan. You’ve probably heard of that guy, right?

I don’t know what the collective noun is for conference speakers. but this is one of those

Marty took the stage and held court for over an hour, talking about all his favourite topics and never flinching from a question. Before and after his talk, he was bombarded with fans asking him to sign copies of his book or grab a selfie with him. Some keyboard warriors on the internet may unfairly complain about him these days, but there’s no denying his star power in product management circles.

Which is why it stung a bit halfway through his talk, he dismissed the exact approach I was planning to present at ProductTank on Thursday as something that just doesn’t work!

Now, to be clear, Marty didn’t know what I was talking about in Cardiff in a few days time, or probably that it was happening at all. He was simply responding to an audience question about product transformation. His response did get me thinking about my life choices, though, as well as thinking about product transformation in general, though. Let’s dig into it.

On “Product Transformation”

When considering product transformation, it’s important to define what we’re transforming into. What is a product transformation? What’s it for, and does everyone need to transform? Obviously, Marty’s book Transformed goes into this a lot (and my podcast interview with Marty, too).

From my perspective, I’ve started boiling it down to 4 key areas (with a non-exhaustive list of sub-areas called out):

1. How Are Decisions Made?

Is there a product vision and strategy to guide decision-making? Are decisions made reactively based on who shouts loudest or the next biggest deal in the sales pipeline, or are they made proactively based on evidence? Is the product management team responsible for deciding things, or just for implementing someone else’s decisions?

2. How Is The Product Built?

How is the work scoped and delivered? Are the product, engineering and design teams fully involved as equal partners in the product development process? Is the work done in the shortest possible cycles appropriate for the company and its customers? Is there sufficient transparency so people understand what’s coming up? Are technical deployments independent of customer releases? Is engineering work managed by the engineering team itself?

3. How Is The Product Released?

How does the product get into the hands of customers? Are the product management team in lockstep with the marketing and sales teams, and have they informed any go-to-market and sales activities, or did they just throw some features over the wall and move on to the next thing? Are the product management team involved in pricing and packaging decisions? Do they even know how the product is sold?

4. How Is Success Measured?

Does the product management team define success and guard metrics ahead of time? Do they have observability so they can track what happens after things are released? Do they proactively monitor these metrics to understand the impact of the work they’ve done and use it to feed into the next decision-making cycle?

There’s actually a fifth, all-encompassing element, which is the importance of alignment. It’s no good doing all this good work if no one knows what you’re doing: The decisions you’ve made, why you’ve made them, and how those decisions are panning out. I’ve spoken to enough leaders in enough organisations to realise that this is the most crucial part of all - it’s hard to run an effective product organisation if you’re constantly being bombarded by escalations, queries and random requests. It’s almost always the lowest hanging fruit when going into an organisation.

Why is change hard?

If transforming into a perfect product organisation were easy, everyone would have done it by now. This stuff is really hard, and anyone who says it’s easy is trying to sell you a pack of Notion templates. But, on the other hand, why’s it hard? Surely, people should be able to read about this stuff in some good books, see sense and get on with it?

Obviously not. There are a bunch of cognitive and organisational biases that get in the way. Every company out there has evolved a working culture over time that is the sum total of the pre-existing biases of every employee, and especially of the leadership team. Status quo bias is an obvious contender here. Fear comes into play. Fear of change, but also a fear of a loss of control or a fear that this stuff won’t work here. Organisations have a gravity, or rather a spring-loaded tension - the more pressure you try to exert, the more pushback you can get.

It’s also fair to say that, very often, product leaders are terrible at selling the message about why the change is a good thing. They resort to quoting books without making a strong case. They can then get frustrated and increasingly bitter when people don’t listen, eventually stymying their chances of making any changes at all.

So, how do we do it?

There are many ways to skin a cat, but here are 4 ways that you might go about trying to transform into a “proper” product organisation:

1. Just Give Up

No law says you have to be a product organisation, and plenty of decent companies aren’t. If every instinct of the founders is to turn the handle and churn features out while getting constantly randomised by incoming feature requests and side-quest one-off builds, that’s cool. I wouldn’t want to work in “product management” for that type of company, but I guess there is a certain excitement to it. The problem isn’t so much that companies stick with this, but that they stick with it while expecting the benefits of being a product company.

2. The Big Bang Theory

Let’s go to the other extreme and just change everything at once! Rip off the Band Aid, gut all of the old teams, implement new operating models, probably fire a few people and bring in some hot talent from Amazon (although not from the Amazon when they were the same size as your company, of course).

I personally don’t see this as an appetising transformation project in just about any scenario. Even if you can get past the ill will, political infighting and sabotage attempts, trying to change everything at once is an incredibly risky move. It’s unlikely to pay off in the timescale that you want it to, and just leave a tangled mess of a company hanging out the back of it.

Maybe it’s a valid approach as a last resort emergency solution, but if you have time, avoid it.

3. Apply Product Management to Product Management

This involves taking a horizontal approach and building a backlog for change. The idea here is that it’s too risky and difficult to change everything at once, especially when there is suspicion or lack of buy-in from the leadership team, so start small.

It’s kind of like taking a product management prioritisation approach to product transformation: Identify the biggest limiting factor, break it down into smaller, valuable increments and deliver impact in those areas step by step.

You’re not going to transform the entire company overnight, but if you can make sustained, compounding changes, then you’ll be surprised where you end up, and generally with no broken bones. On the other hand, the pace of change can be slower, and you may not see immediate, exceptional results.

4. The Golden Team

This is the vertical approach. Rather than taking a step-by-step approach and fixing one thing at a time, you create an exemplar team - either hired in, formed from members of other teams, or an existing team that you want to change.

The goal here is to do all the things “properly” in that team. Everything. It’s a limited surface area, so you’re not risking the entire company on something that might not work, but you’re also able to demonstrate the awesome power of product thinking in an enclosed fashion.

In theory, this can allow you to deliver outsized results and get permission to start implementing this approach in other teams. On the flip side, it can cause discord inside the other teams (“why can’t we work like that?”). There’s also a risk that, if it doesn’t work out, you’ve shot your shot and missed.

What’s the right answer?

Well, the approach that Marty prefers, and called out in his talk, was “The Golden Team” model. He explicitly doesn’t believe that the iterative approach works.

For reference, my talk in Cardiff a few days later was called “Applying Product Management to Product Management” 🫠

So who’s right? Well, I would never go against the Jedi Master, but I do feel that each approach can work in different circumstances. Marty’s point was that, if the clock is ticking and you need to show results, iterative change is not going to cut the mustard. You’ll run out of time before you’ve delivered the true benefits, and the leadership team will give up on you.

It’s a compelling point, and I’d perhaps refer to it as answering the top-down transformation question. Maybe the leadership team are explicitly driving the need for transformation. Perhaps they’re curious after speaking to some CEO friends, or their investors have been pressuring them. Whatever the instigation, they want to see results, and they want them soon. In this case, you absolutely need to show results as quickly as possible, and the golden team approach is almost certainly the best option. It’s also a fantastic option to try if you’re creating a new zero-to-one initiative with no baggage and few barriers.

On the other hand, what if no one’s telling you to change? I often speak with leaders of companies who are conscious that something is wrong, but “product transformation” is the last thing on their minds. They just want everything to be the same but better. There are almost certainly talent gaps and perhaps no obvious candidates to fill a golden team, or budget to hire anyone.

If it’s a bottom-up transformation effort, where you’re trying to advocate for things to be better and the pressure is coming from your side, you can probably afford to take a more measured approach. This doesn’t mean you can’t take a big swing if you see the opportunity, but that you are more likely to make sustained progress if you don’t upset the apple cart, and that any changes in the right direction are better than no changes in the right direction.

You could, of course, also try elements of both: Create a golden team while iterating changes with the rest of the organisation, which means that they’ll have less distance to travel if the exemplar team does its job and gets you the wider buy-in you need.

It’s become a bit of a cliché to say “it depends” to every single product management problem, but it really does depend. It’s important to assess the appetite for change, the urgency that is being felt, the timeframe you need to deliver it in, and the pain being felt on the ground before choosing a method that you believe will work in your particular circumstance.

I’d love to hear your stories of trying to implement change! Drop a comment or send me an email if you have a story of any of this stuff working well for you, or crashing and burning.