Why Your Transformation Keeps Stalling

And How Product Thinking Can Fix It

You've been hired to make changes.

You've done your homework, you know what needs to change, and how to go about it.

You just need support from the very people who hired you to make changes to build buy-in from their teams and get started.

You present your plan.

But instead of support, you get resistance.

You press on, aiming for small wins to create the proof that will build momentum.

The resistance builds.

Six months later, your team is burning out fighting the same battles every week, your best people are interviewing elsewhere, and the cynics are saying "I told you so."

Then there are demands for reports and features that distract from the real work.

To add insult to injury, you start to get questions about your competence from people who clearly don't know much about product management and hired you because you do.

The momentum is building, but it's going in the wrong direction.

If that sounds familiar, this article is for you.

The Wrong Approach: Treating Change Like Implementation

I struggled with a very similar problem in my first ever management job, at Google.

I cut my teeth in a team of engineers who served Google's largest and most important partners, each of which brought in tens to hundreds of millions of dollars in revenue annually.

Most companies would hire non-engineers for this sort of role. Google's strategy was to hire engineers who would do the work manually, get frustrated, and then build tools so the partners could self-service. It was high touch to enable low touch. Constant productisation, operationalisation, and scaling. It worked.

I was hired from this team into the DoubleClick organisation, recently integrated but still relatively independent. I was to build a Client Services team for a newly acquired product called Invite Media (later DoubleClick Bid Manager, now Google Display & Video 360).

It was clear to me what needed to be done - the work was incredibly manual and repetitive, and the same playbook would apply here.

But I was not allowed to hire engineers. The team was supposed to be semi-technical at most, and I could not get them access to the code base, which required full Engineering interviews.

I presented my case for hiring engineers to my manager. It was rejected.

I presented it to the director. It was rejected.

So I hired the best I could, including some who were engineers in a past life, but didn't pass the Google Engineering interviews. At least they would have the capability to deliver some of the tools I knew were needed, even if they couldn't get to the core product.

We got started building tools and automating, and made good progress.

But my manager started asking for ticket metrics. Close rates, time to first response, customer satisfaction.

The last thing I wanted to do was to implement a ticketing system and track ticket metrics.

Google Engineers hate the thought of being seen as ticket monkeys, processing tickets all day and being measured and compared on how many tickets each of them were closing. I didn't even want to learn about ticketing metrics, because I saw them as a distraction from the real job of serving clients and building systems.

So I resisted, fighting to create more impact and deliver more value without letting administrative overhead get in the way.

It didn't work.

It took a bad performance review for me to concede and start delivering the metrics they were looking for.

And here's the thing: Once I started to understand and deliver what my manager valued, he became open to listening to my ideas on automation, and I was invited to present a proposal to the director, which then informed his presentation to the VP, and which influenced the vision for the whole organisation.

The harsh reality was that I was solving the wrong problem entirely. I was treating organizational change like a technical implementation when I should have been treating it like a product launch. And just like any product launch, success depends on understanding your market—in this case, your colleagues—and building something they actually want to adopt.

The Right Approach: Treating Change Like Product Development

If you're struggling with implementing change, the problem you're solving is not a technical one about what to change, it's about finding a fit between the change you want to make, and the needs of your customers - the people involved in the change. And what you learn about those people should inform and change your product itself.

Taking a product manager's approach to change, your organization IS your customer. And even if they say they want the change, they will resist any aspect of that change which is different to what they expect, need, or think they need.

What does every successful product manager know? You don't build what you think users want. You listen to what they actually need, understand their constraints, and iterate your value proposition until it clicks.

Stop trying to convince your organization to adopt the the product approach. Start applying product thinking to your organization itself.

The product leaders who successfully transform organizations don't do it by being more persuasive about their vision. They do it by treating change like a product that needs to find product-market fit with their own company.

In my case, I needed to first understand what the customers of my desired change (my management chain) wanted, how they thought, what they valued. I needed to build trust with them, prove to them that I could deliver what they thought I should be delivering, so I had credibility to be able to offer them a new direction, one which would deliver more value that they cared about, not just meet my ideals of how such an organisation should work.

If I had delivered the metrics they needed, proven I could do the job they expected competently, and then used those very metrics to demonstrate the value of the changes I was making, things would have gone differently. But I first needed to listen and learn. It wasn't that my idea was wrong, my approach was wrong.

Here's the uncomfortable truth I had to face: I was demanding that my organization change while refusing to change my own approach. If I wasn't willing to adapt my methods to fit their reality, why should they adapt their reality to fit my vision?

Start With Deep Listening

Here's the counterintuitive truth: before you can change your organization, you need to understand it well enough that your stakeholders feel understood.

This isn't about gathering their objections to your plan. It's about understanding their world so deeply that you could represent their perspective better than they could.

Learn how they really make decisions. Your sales director doesn't just care about revenue—they care about predictable revenue. Sit with them through a pipeline review. Understand what makes them confident in a forecast versus nervous about it. Learn their language for discussing deals that will close versus deals that might slip.

Understand their real goals and constraints. Your CMO's job isn't just "drive leads." It's drive leads while managing brand perception, coordinating with agencies, staying within budget, and keeping the CEO happy with awareness metrics. What's the hardest part of their job that nobody else sees?

Master their preferred path. Watch how they approach problems. Do they start with data or intuition? Do they prefer to test small or go big? Do they need buy-in from above or below? Understanding their natural problem-solving style is as important as understanding their problems.

Prove you understand by explaining it back. The test isn't whether you understand them—it's whether they feel understood. Can you explain their challenges, goals, and constraints in a way that makes them say "exactly"?

Only when they believe you truly understand their world will they be willing to understand your perpective.

Think of it exactly like earning trust with customers. You listen first, understand deeply, then—and only then—do you propose solutions. Your internal stakeholders deserve the same respect.

Earn their trust by delivering results they care about

Once they know :

Change your definition of success to adapt to theirs. Your definition of transformation success might be faster time-to-market. Theirs might be fewer late-night emergency calls. Your win is customer-centric features. Their win is stable systems that don't break. They are the customer. Start with their defintion.

Find the job they're hiring the status quo to do.Why do people resist change? Because the current way of working solves problems for them. Engineering's manual processes ensure quality control. Finance's lengthy approval cycles prevent costly mistakes. Understand the job the status quo does before you try to replace it.

Prototype small changes and get feedback.Instead of rolling out your full transformation, run small experiments. Pick one team, one process, one metric. See what breaks. See what works. Iterate based on what you learn.

Iterate your change approach, not just your strategy.Your strategy might be perfect, but your approach to implementing it might be wrong for this organization. Be willing to change how you drive change.

What this looks like in practice

Let me show you how this plays out in real client work.

When clients resist implementing OKRs as 'more process,' I start by asking about their current planning frustrations. I typically discover they're drowning in status meetings and confused about strategy. So I address those problems first. Later, I introduce OKRs as a natural part of the solution to their pain points, not an additional burden.

The Bottom Line

The changes you want to make might be perfect. But if your organization isn't buying it, the implementation isn't the problem.

The product is.