Why It’s Time to Forget the Project vs. Product Operating Model Debate
A Conversation We're Still Having in 2025 (And Why That's Okay)
I know, I know. You saw the headline and probably rolled your eyes a little.
"Product operating model versus project operating model? Really, Petra? In 2025? Haven’t we moved past this already?"
I hear you. And honestly? Part of me wishes we had.
But here’s the thing: Teresa Torres and I decided to dedicate an episode of our podcast, All Things Product, to this exact topic because it keeps coming up. Not just occasionally—constantly. In my coaching sessions. In Teresa’s courses. In DMs from product leaders who are stuck between the promise of empowered teams and the reality of their day-to-day work.
So yes, we’re having this conversation again.
And I’m writing this post to make sure a bigger audience can read it, reflect on what they see in their own organizations, and maybe find a path forward.
If you’re part of the 20% thinking, “Finally, someone’s talking about this!”—I hope you feel seen. This one’s for you.
And if you’re in the 80% who just sighed deeply? Stick with me. Because even if you’ve got this figured out, someone on your team probably doesn’t. And they need better tools to navigate the tension between these two models—without losing their minds.
Can a company run both a product and a project operating model at the same time?
The question that often comes up on this topic is: Can a company run both a product and a project operating model at the same time? The short answer is yes. But the better question might be: When should you use which mindset—and how do you know if you’re using the right one?
This was the focus of our recent podcast episode. Teresa and I explored the nuances, edge cases, and practical realities of companies shifting from project-oriented software delivery toward more empowered, product-centric ways of working. You can watch (or listen to) the full episode here.
But instead of recapping our conversation, I want to extend it. Because many organizations aren't choosing between the two models. They're navigating both, simultaneously. And product teams need better tools to do that well.
Getting on the Same Page: What Are We Talking About?
Before we go deeper, here's a quick refresher on the two models—just enough to align terminology.
Product Operating Model:
Continuous value delivery through durable, cross-functional teams.
Products have a lifecycle and someone needs to take care of them. They evolve, mature, and sometimes retire, but they rarely just “end.”
Teams are organized around outcomes, customer problems, or products—not tasks.
Focused on learning loops, long-term ownership, and iterative improvement.
Examples: Improving sign-up conversion, reducing churn, increasing active usage.
Project Operating Model:
Temporary teams formed to deliver a specific output within defined time, scope, and budget.
Projects follow the “fire and forget” pattern—the work is completed, handed over, and there’s no longer an active owner.
Once the deliverable is done, the team is disbanded or reassigned.
Focused on delivery predictability and clear, scoped objectives.
Examples: Implementing GDPR compliance, launching a partner integration, migrating to a new tool.
As we discussed in the podcast, these aren’t competing ideologies. They’re different lenses. Being able to shift between them—and know when to—is part of product maturity.
Why This Conversation Still Matters
If you’ve been following my blog, you’ll know I’ve written a lot about the product operating model. From highlighting Marty Cagan and SVPG's recent work in Transformed in this blog post, to asking whether your company is truly ready for product operating model coaching here, the message is clear:
Getting serious about product thinking is not about adopting new terminology. It requires new behaviors, new structures, and clear expectations.
And yet… many product people are still being pulled into project-shaped work.
Legal needs help implementing a one-off compliance initiative (hello, GDPR!).
A partner integration needs to be completed by the end of the quarter.
A product manager is asked to support a CRM implementation.
A team is spinning up a rebranding initiative.
A security audit is due and might require urgent changes that need product input.
An internal analytics dashboard is needed for Ops.
In all of these, the work is finite, output-focused, and often disconnected from a durable outcome. It’s project work. And pretending otherwise doesn’t help.
It’s Not Either/Or. It’s "Yes, And."
As Teresa put it in our episode: "Even the most empowered product teams sometimes benefit from thinking in project terms."
The reverse is also true. If you keep getting pulled into "urgent project" mode again and again, it might be time to zoom out and ask: Is this actually a recurring problem that deserves a durable team and product-shaped ownership?
One of the clearest examples of this is hiring. If you're hiring once, treat it like a project. If you're scaling headcount over the next three years, maybe it's time to think about your hiring process as a product. What's the repeatable value you're creating? What are the metrics that tell you it's working? Who owns improving it?
Feedback Loops Reveal the Right Model
In the episode, I shared a mental model I use when I’m coaching leaders: "It ain’t over till it’s over." If work you thought was finished keeps coming back like a boomerang, you’re likely facing a product challenge.
Projects are done when the output is delivered. Products are done when the outcome is reliably achieved—and that usually means "never."
This is why feedback loops are so critical. If the work delivers a single result (e.g., a compliance PDF, a training session, a bug fix), great—you might be in project territory. But if the same work needs to be improved, maintained, or expanded over time, it’s probably a product.
This is where tools like my Opportunity Assessment come into play. It's a simple method to stop and ask: Is this worth investing discovery time in? Is it a one-off request, or the beginning of something bigger?
Operating Model Awareness = Product Maturity
If you're an IC PM, you might not be defining your org's operating model. But you're living inside it. And understanding the mindset behind product vs. project models helps you frame your work more effectively, especially when working cross-functionally.
If you’re a product leader, you have even more responsibility:
Helping your team zoom out.
Spotting recurring themes.
Challenging assumptions when everything feels "urgent."
It also means protecting your team from being stuck in endless project churn, while still respecting the legitimate needs of departments like HR, Finance, or Legal. Operating model fluency isn’t about purity. It’s about flexibility and framing.
TL;DR for Product People
Project models work best for one-off, compliance-driven, or output-focused work.
Product models are best for evergreen challenges, continuous improvement, and durable outcomes.
You don’t need to pick one. You need to get better at switching between them.
Feedback loops reveal which model you're in. Pay attention.
Use tools like the Opportunity Assessment to make better framing decisions early.
If you're in the middle of a transformation and feeling stuck between old ways of working and the promise of empowered teams—you're not alone. Just keep asking: What model best fits this work? And what would need to be true for us to make the switch?
Let's stay flexible—not dogmatic.