I have a confession to make: I love processes. But I only love them when they are right and help me, and process for the sake of process usually doesn’t.

My business runs on process. We’ve built clear systems for operations: onboarding, communications, client management, and program delivery. These processes are great – not because they’re perfect, but because they help us run fast and reliably. My team loves them. They make work smoother, safer, and more consistent. And when you’re doing operational work, not missing anything is a worthy goal.

But product work isn’t operational. And real transformation doesn’t come from process.

When clients seek my help in improving and transforming their product management, strategy, culture, and other areas, they often request a process definition. Let’s define how teams should work. Give us the process and we’ll follow it. 

They assume the process is the solution. But that’s backwards. In product, the process is the outcome, not the goal.

The goal is transformation – building better products, making sharper decisions, working better as a team, and delivering business results. And that only happens through doing the work. In real life. With all its ambiguity, tension, tradeoffs, and learning. 

Process doesn’t cause transformation – it formalizes it once it’s already working.

Trying to lead with process before you’ve earned it is like trying to scale a prototype that never worked. You can document it, teach it, enforce it – but it won’t help, because it never delivered results in the first place.

So yes, process matters. But only after you’ve figured out what actually works.

To create real change in your org, don’t start with the process. Start with people, teams, and problems. Start with trying, learning, adjusting – and then, only once it’s working, write it down.

Here are the most important guidelines for doing so. A process for process, if you will, based on real-life learnings and patterns as suggested.

Transformation Starts Small

Leaders who want to create change often have good intentions. They see what’s not working – the silos, the chaos, the unclear priorities – and they want to fix it. They honestly believe that what the company needs is a big bang: a new operating model, a fresh framework, a shared playbook rolled out across the org. One bold move to get everyone on the same page.

But here’s the problem: the big bang rarely works. Not because people are resistant to change, but because transformation doesn’t work that way.

Real change doesn’t come from introducing a new process. It comes from achieving better outcomes. You’re not trying to transform the way you work just for the sake of it – you’re trying to generate better outcomes. Maybe your teams aren’t collaborating well. Maybe decision-making is slow or unclear. Maybe strategy isn’t translating into execution.

You need to start there – with a clear sense of what you’re trying to improve, and why. Then, instead of launching a company-wide process, pick one team. Work closely with them to identify the gaps and then come up with solutions. Try them and iterate on them long enough to see results. Then do the same with another team. You’re still exploring, not replicating.

Then you can start identifying the patterns that work across teams and situations, and slowly turn them into shared practice.

Change doesn’t happen instantly. You must be patient.

The Real Work Is Figuring Out What Works

Once you have defined what you want to improve and chosen a team to work with, roll up your sleeves, since the real work only begins.

Figuring out what works takes time and isn’t always easy. It’s especially not easy because you are not starting from scratch. People already work a certain way, and this mode of work probably has its benefits too. Otherwise, your team would have changed it already.

The hard work is figuring out what works in real life and not just in theory. Your experience matters, but you shouldn’t copycat what worked at your last company. It’s important to learn common practices, but adopting common frameworks isn’t necessarily right for you.

The real test is what actually improves outcomes in your current context – with your people, your structure, your goals, and your constraints.

And that takes time.

You have to sit in the mess with a team. Observe closely. Try things. Ask questions. Adjust. Understand what feels better – and why. What makes things easier, clearer, faster, and more focused? And just as importantly, what breaks down when things get hard?

It’s easy to confuse activity with progress here. Teams might enthusiastically adopt a new ritual or tool, and it might feel better for a while. But are the right decisions being made? Is trust increasing? Is execution more aligned with strategy? Are you solving the original problem, or just dressing it up?

This is why change can’t be driven from a slide deck. It has to be lived. You need to be close enough to the work to see what’s really happening.

What You Should (And Shouldn’t) Formalize

Once you’ve seen something work more than once, across different teams or situations, it’s tempting to lock it in. And you should. That’s how shared practice is created. But formalizing success doesn’t mean turning it into a rigid rulebook. If you want the process to scale, it has to remain useful. And that means being thoughtful about what you fix and what you leave flexible.

When you’re scaling, you’re no longer just helping one team – you’re trying to support many. And that’s where good intentions often go wrong. You want to help, but you end up constraining. That’s why the question to ask isn’t just “What worked?” but also “What part of this needs to be consistent – and what can stay adaptable?”

Start with guiding principles. These are non-negotiable. If the thing that made it work was, say, surfacing hard tradeoffs early, make that a company-wide principle. It’s not about how you surface them – it’s that you do. Principles give people the freedom to adapt while still pointing everyone in the same direction.

Next, formalize interfaces. If multiple teams are syncing with the same stakeholders, you probably need a shared format or rhythm for how that happens. Otherwise, you create confusion and inefficiency at the boundaries.

You can also standardize shared language – common terms, definitions, and named phases. This cuts down on misalignment and wasted cycles.

But resist the urge to formalize every behavior or format. Teams don’t need identical rituals to be aligned – they need clarity, trust, and autonomy. Let them choose how they work, as long as they’re upholding the principles and delivering the right outcomes.

Remember: the goal of scaling with process isn’t to get everyone doing the same thing. It’s to help everyone succeed in their own context, without reinventing the wheel every time.

One last thing: even the best process will need to evolve. Teams that struggled to find out what works will, understandably, want to stick with it. But over time, things change – people, the market, company scale – and what used to work no longer does. 

Keep an eye out for this. Process should be stable, but not static, and staying adaptable is part of the job, even after you’ve figured it all out.