How Not to Introduce Process Improvements (ditch the dogma)

Disclaimer for Medium

This is an early excerpt from a book I am working on that I plan to call "Product Snacks". It will be a concise collection of chapters, each offering practical and accessible advice for product managers and designed to be a desk-side companion, providing quick, digestible tips to guide and inspire when you're seeking clarity or a fresh perspective. I’d love ANY and ALL feedback and if you’d like to collab, let’s chat!

Unfortunately, it’s all too common for product folks to stumble into a well-meaning but disastrous attempt at process improvement. They get inspired by the latest Medium post, that sleek case study from a Silicon Valley darling, or—worse—the frameworks they meticulously memorized while earning their MBAs. They convince themselves that the process must be the problem.

“If we could just implement OKRs, switch to continuous discovery, and run a daily stand-up at exactly 9:07 AM, everything would fall into place.” they think.

And so, they charge ahead like a bull in a china shop—excited, determined, and completely unaware that they’re about to make a gigantic mess and lose almost (if not) all of their credibility. They announce sweeping changes, roll out shiny new frameworks, and expect instant buy-in. But instead of a transformed organization, they find resistance, delays, and baffling excuses. Suddenly, their well-planned process overhaul is met with the corporate equivalent of an eye roll.

Then comes the frustration. “Why won’t they let me do product right?” they mutter to themselves (or to LinkedIn). They either dig in and fight a losing battle or burn out entirely, eventually leaving in search of that mythical utopia where everyone does things the "right" way.

Sound familiar? Maybe you've seen this movie before. Maybe you've starred in it. (Don’t worry, I’ve been there too.)

Understanding the Problem

Here’s the truth: your organization probably does need to change. It’s likely that you’re stuck in a “feature factory” mode, shipping tickets without strategy, and calling it "agile" when in reality, it’s more like waterfall with extra meetings. You’re not wrong to want to fix things. But the key to success isn’t a bigger hammer—it’s a better understanding of why things are the way they are in the first place.

Companies don’t operate the way they do just because they haven’t read the same books you have. Their current systems and processes exist for reasons—some good, some bad, but all real. Maybe leadership is optimizing for predictability over innovation. Maybe teams are working around legacy tech that nobody wants to touch. Maybe past attempts at change failed spectacularly, leaving behind a scar tissue of skepticism.

Before you roll out a grand vision, you need to diagnose the reality. Because if you don’t understand why things are the way they are, your process improvements won’t stick.

Taking the First Steps

Instead of enforcing a framework like a process police officer, approach this like a product problem. Who’s your customer? The business. What problem are you solving? The inefficiencies, misalignment, or confusion that make work harder than it should be. Sound like product?

Start by investigating:

• Why do things work this way today? (Hint: Ask “why” five times, and you’ll probably land on an interesting answer.)

• What are the pain points? (For both leadership and the people in the trenches.)

• Where do people actually want help? (Because forcing help where it’s not wanted is a shortcut to failure.)

Then, form hypotheses. Test them with small, incremental changes. If you were launching a new product feature, you wouldn’t roll out a massive update without validation—so why would you introduce process changes that way?

Instead, think in MVPs:

1. What’s one small, immediate thing you can do today to improve how the team operates?

2. How can you iterate on that improvement over time?

3. What existing processes should you remove instead of adding more complexity?

4. Can you help clarify roles, priorities, or decision-making pathways to reduce confusion?

Less grand restructuring, more thoughtful tinkering.

Embracing Change (Without Causing a Rebellion)

A hard truth about process change: most people don’t like it. Even when it’s good for them. Even when they say they want it.

It’s like exercise—everyone agrees it’s beneficial, but when faced with the reality of 6 AM workouts, they mysteriously lose enthusiasm.

If you want to drive change, you have to work with human nature, not against it. That means:

• Start small. Nobody wants a sudden, company-wide transformation overnight. Introduce changes in a way that makes life easier for people, not more complicated.

• Communicate the why. People resist change when it feels arbitrary. Make sure they understand what’s in it for them.

• Show, don’t tell. Rather than preaching the benefits of a new process, demonstrate its value with small wins.

• Be prepared to adjust. Not every change will work the way you expect—treat it like a product experiment and be willing to pivot.

Providing Clarity

Here’s a secret: most people don’t mind being told what to do. What they hate is not knowing what’s expected of them.

A shocking amount of workplace dysfunction boils down to ambiguity. People are BUSY but not productive—not because they’re lazy or bad at their jobs, but because they aren’t sure what actually matters.

Your process improvements should help fix that. If you can bring clarity—about goals, priorities, and decision-making—then suddenly, your changes don’t feel like extra work. They feel like relief.

When people see that your tweaks make their jobs easier, they’ll stop resisting. In fact, they’ll start asking you for more. That’s when you know you’re on the right track.

Finding the Right Mix

At the end of the day, no single process or framework will magically solve all your organization’s problems. There is no one-size-fits-all approach. There is no perfect agile, no ultimate operating model. There is only what works for your team, right now.

So:

• Borrow from different frameworks.

• Blend approaches.

• Steal ideas from unrelated industries.

• Ruthlessly remove what isn’t working.

The best product teams don’t just follow a playbook—they build their own. When you focus on solving real problems, providing clarity, and iterating thoughtfully, you won’t just implement process improvements—you’ll build a stronger, more effective team.

And isn’t that the real goal?

Key Takeaways

• Avoid Force-Fitting Frameworks: Simply implementing popular processes and frameworks without understanding their context won't solve all your organizational problems.

• Understand Organizational Resistance: Recognize that pushback and resistance from the organization are common when trying to implement new processes.

• Start with Value Delivery: Focus on how to deliver value to your customer (the business) by solving specific problems.

• Understand Current Operations: Deeply understand why the business operates the way it does, even if the reasons seem flawed.

• Hypothesize and Validate: Define and test hypotheses through customer interviews to validate your assumptions.

• Incremental Improvements: Develop an MVP to address problems incrementally, adding, polishing, and removing features as necessary.

• Embrace Gradual Change: Change organizational behavior piece by piece, ensuring clarity on the reasons, goals, and methods of change.

• Measure Success: Continuously measure what’s working and what isn’t, and be ready to make adjustments.

• Provide Clarity: People crave clarity and want to know their work is meaningful and helpful; clarity can enhance productivity.

• Adapt Processes: No single process or framework is perfect. Borrow and blend methods from various industries to find the right mix for your organization.

• Support Best Work: Aim to provide clarity and support for people to do their best work, fostering acceptance and looking to improve the business rhythm.