Product Leaders can have a little Dogma... right?
Actually... no.
I’ve been thinking a lot lately about what happens when leaders get too precious about how work gets done instead of focusing on whether it actually moves the needle.
And as a former dogmaholic, I’ve come to the conclusion that it’s never helpful.
I remember joining a fairly traditional B2B SaaS company working on NLP way before AI was cool, bright eyed and bushy tailed, ready to transform the product org from the bottom up.
“But we’re supposed to do lots of discovery!”
“But the CEO can’t just decide what our priorities are!”
“But we’re meant to be measuring things!”
And of course, I was right. The way product work was done left much to be desired.
But I was also wrong. Because all my shouting did was drive people away. And sure, we did have some wins here and there - we got more honest about what our prioritisation practices actually looked like, we defined what was inside our circle of influence and what wasn’t, and over time, we even got better at measuring how people were actually using our product.
But I always had to take it a step too far. As the chief creator of templates I felt personally responsible for making sure everyone followed them to the letter. As the newly appointed JIRA admin I’d be up in arms when someone didn’t follow the right workflow, or - gasp - shipped an improvement with no ticket at all! 😱
Everything needed to be documented, everything needed to follow the same process, everything had to be just like it was in the stack of product books I had on my desk.
After all, if it’s worth doing, it’s worth doing right, no?
It’s only after I left that company and was blessed with hindsight that I realised that there were a whole lot more effective ways of affecting meaningful change inside an organisation than pure, unadulterated dogmatism.
But here’s the kicker - during the entirety of my tenure, I genuinely thought I was being helpful. I thought I was “maintaining standards”, or “ensuring quality”.
But what I was actually doing was teaching folks that compliance to a process matters more than outcomes. That looking right is more important than being effective.
That the ceremony matters more than the result.
The Seductive Appeal of Dogma
Let me be clear: I’m not arguing against all frameworks, processes, or standards. Product Operations exists precisely because how we get work done does matter. But there’s a world of difference between having a point of view on how things should work and being dogmatic about the exact execution of that view.
Dogma always looks like rigour at first. It feels responsible to say “we need consistency across teams” or “everyone should follow the same template.” It feels like leadership to enforce standards. It feels like you’re doing your job well when everyone’s OKRs look uniform and every PRD follows the same structure.
But over time, dogma teaches people to optimise for approval instead of impact. And that’s how you end up with teams that are very good at filling out templates but very bad at building products that actually matter.
And taken to its conclusion, it’s exactly how you get product management theatre.
The cruel thing about all of this is that we’re simply following our instincts. Humans have evolved to always strive for certainty. Because in uncertainty lies danger.
When we know what happens, we feel safe - even if that knowledge itself is an illusion. This is precisely why people will always want some level of confidence in timelines, why we spend so much time debating estimates, why roadmaps look the way they look, and why true product transformation requires a true shift in mindset.
We want to know. Deeply, intrinsically.
Now imagine being a product leader who knows exactly how her teams discover, build, and ship products. Among all the unknowns and uncertainties you’re already battling every single day, wouldn’t that be the smallest and most welcome comfort? Wouldn’t that feel like paradise?
To be able to say: “I can’t predict what the market is doing nor what our competitors are doing, and I don’t know where the next funding round comes from, but what I do know is that we have a damn good process for getting things out the door”?
The Problem With Product Work
Here’s the thing: Good Product Leadership is not about control - it’s actually about the exact opposite of that. It’s a lot about giving things away, about not having every minute detail, and about being comfortable with trusting your people to do the right thing.
Now, this doesn’t mean that as a Product Leader you’re absolved of all responsibility. Because every system operates in its unique context. And it’s the context that makes the system succeed or fail.
As a Product Leader you don’t own features. You don’t even own the roadmaps.
You own the long-term strategy, and you own the context.
The work you do on the strategy and context, and the way in which you talk about that work are pivotal to your company’s success. They are non-negotiable.
You literally have the most important job in the whole product organisation. And that’s to set your teams up for success by giving them the “why” and the “where to”.
But the what and the how? You don’t own that. You have a stake in it, but your teams own the what and the how. And if you don’t trust them to own those, you need to find out why you don’t trust them, and what you will do to change that.
👉 Spoiler alert: The answer cannot be “more process”.
The Uncomfortable Truth
I’ve seen the same story play out so many times: A product leader reads a book, attends a conference, or works at a company where something worked really well. They become convinced that THEIR way to do OKRs or run discovery or write PRDs is the only legitimate path to success. They’ve already seen it in action - they know for a fact that it’s true!
They roll it out with the best intentions. And then they become the dogma police. 🚓
Every deviation becomes a teaching moment. Every adaptation becomes a sign that “people aren’t taking this seriously.” Every team that tries to tailor the approach to their specific context gets pulled back into line.
Shape up or ship out. You’re either with us or against us. It’s my way or the highway.
And look - I get it. I really do. When you’re trying to transform an organisation’s product maturity, consistency matters. When you’re introducing new ways of working, you need people to actually adopt them. There’s a genuine fear that if you give teams too much flexibility, everything will devolve into abject anarchy.
But that fear is a symptom of a different problem entirely.
➡️ Is it more important that the objective is perfectly aspirational and inspirational? Or is it more important that we have the means to measure whether we’re making progress?
➡️ Is it more important that every team follows the same product review template? Or is it more important that teams have meaningful conversations to unblock each other and surface risks early?
➡️ Is it more important that discovery follows the same three-step process every time? Or is it more important that we genuinely understand our users’ wants, needs, and pains?
When I work with product organisations, I see this tension constantly. Leaders who are so focused on the format of the work that they lose sight of the purpose. Teams who spend more time debating whether something fits the framework than whether it’s actually solving the problem.
If you’re a Product Leader who recognises themselves in the above, take the following to heart - I say it with all the love that I have:
Your templates don’t make bad thinking good.
Your frameworks don’t replace good judgment.
Your “standards” often just mask your own insecurity about letting your teams own their own work.
What Good Looks Like
Let’s assume that you’re a Product Leader who has their own dogmatic tendencies and recognises that it doesn’t work as well as you thought. Or that maybe you recently joined a new company and were tasked with implementing “The Product Operating Model”. Where do you go from here?
In Product Operations, I firmly believe that the day we lose sight of pragmatism is the day we start failing. The same can be said for Product Leadership.
The best Product Leaders I know actually care very little about what their teams are up to day-to-day. But they have very strong opinions about outcomes.
They care deeply about whether teams are solving the right problem and measuring the right thing - but couldn’t care less about whether they used the approved Miro template or wrote their hypothesis in the exact phrasing they prefer.
They ask questions like:
How do you know this is the right problem to solve?
What will change for our business if this works?
How will you measure success?
What assumptions are you making?
How are you testing you’re on the right track?
Not questions like:
Why didn’t you use section 4 of the template?
Where’s the JIRA ticket for that?
Why was your weekly demo only 15 minutes long?
These leaders understand that operational systems are scaffolding, not the house itself. They’re there to set the context for the work, so that their teams have all the information they need to do their best work - not to oversee the work itself.
The Maturity Paradox
Now, I know what some of you are thinking: “But Antonia, doesn’t this require teams to already be quite mature? What about organisations with junior PMs who need more guidance? Those for whom agile is new? Non-digital natives?”
And yes, you’re absolutely right. This way of working does require a certain level of maturity. But here’s the thing: Any meaningful change motion (even the most foundational!) also requires flexibility. It requires the ability to set a standard and then approach each deviation with inquisitiveness - not the hammer of Thor.
When someone deviates from a new way of working, don’t take it as dissent - or even worse, a lack of talent for the job itself. Take it as valuable information. Because it might be telling you things you don’t see:
It doesn’t work in their context
They don’t understand the purpose behind it
They’re solving for something that’s not accounted for
There are flaws you haven’t considered
If your first instinct is to correct rather than understand, you’re teaching people to hide their thinking from you. You’re training them to perform compliance rather than develop judgment. You’re literally breaking down psychological safety.
And that’s the paradox: The more dogmatic you are about process, the less your teams actually learn. Because they’re focused on getting it “right” rather than understanding why it matters.
Finding the Balance
So how do you maintain standards without becoming dogmatic? How do you ensure consistency without crushing autonomy? How do you elevate teams to building better products without prescribing exactly what they should be doing?
Here are the principles I follow:
Be opinionated about the why, but flexible about the how: Care deeply about whether teams understand their customers, measure their impact, and communicate their intentions. Care much less about the exact format they use to do these things.
Focus on capabilities, not compliance: Instead of asking “did they follow the process?”, ask “can they articulate their reasoning?”. Instead of “did they use the template?”, ask “do they understand what information matters?”.
Approach deviations with curiosity: When someone doesn’t follow your framework, your first question should be “tell me about your thinking here” not “this is wrong”.
Separate signal from noise: Some variation matters (teams making decisions without data, releasing features without success criteria, not validating hypotheses). Some variation doesn’t (using different communication cadences, preferring different formats, structuring documentation differently). Learn the difference.
Trust, then verify: Give teams the benefit of the doubt that they’re trying to do good work. If you see patterns of poor judgment, address those directly rather than creating more process constraints.
And for the Product Ops folks reading this, the following might be a tough pill to swallow, but I have to say it: The exact ins and outs of how work gets done matter much less than you think. What matters is that good decisions are consistently made.
Don’t build for standardisation. Build for better thinking.
In Conclusion
Product dogma doesn’t just slow teams down or frustrate people (though it does both of those things). It fundamentally changes what your people optimise for.
When compliance becomes your measure of success, people stop thinking critically about whether their work actually matters. They stop asking hard questions about whether they’re solving the right problem. They stop adapting their approach based on what they learn. And so do you!
As a Product Leader, that should terrify you. Because your job isn’t to create process zombies who mechanically follow frameworks. Your job is to set the context for excellent product work - to provide clarity, set the direction, and ensure conditions where good judgment can flourish.
If you’re finding yourself in a transformation right now (and let’s be honest - who isn’t), take a moment to reflect on the following questions:
Are you building an operating model designed for better decisions, or are you building a library of templates?
When someone deviates from your framework, do you get curious or critical?
Are you measuring success by how well people follow the process, or by whether they’re building better products?
Do your teams spend more time formatting documents or understanding customers?
And finally…
Are you building an organisation centred around trusting your teams to get their best work done - or are you trying to exert control through process?
These are uncomfortable questions. I know because I’ve had to ask them of myself, too. It’s so easy to slip into dogma, especially when you care deeply about doing things well - it feels righteous, and it feels responsible.
But the best Product work isn’t about perfect consistency. It’s about creating clarity, building capability, and enabling better decisions. And sometimes, that means having the courage to let go of the perfect format in your head in favour of the meaningful outcome in your teams.
Because at the end of the day, nobody remembers whether your OKRs were perfectly wordsmithed. They remember whether you built something that mattered.