Product vs. Project Operating Models - All Things Product with Teresa & Petra

Hi folks, this is All Things Product with Petra Wille and Teresa Torx. And we're so happy you're here. Teresa, I have a question and I already have opinions as always, but I wanted to discuss it with you. Can one company in parallel have the product operating model and the project operating model running? Yes. I think they can. In fact, I think most companies are even companies mature in the product operating model probably still have parts of their business that are running in a project mode. I would have said the exact same thing. I agree. Let's dive into it. All right, we're done. Yeah, all right. Episode recorded. Shortest episode ever. Okay. Let's start by unpacking. Yeah, let's start by actually breaking down these terms. So product operating model. term recently popularized by Marty Kagan, to reflect this idea of empowered product teams that are being tasked with outcomes or customer problems to solve, as opposed to project operating models where we're asking our teams to do an initiative. Here's a project, typically an output, build this feature, it begins and ends. And so symptoms of product operating model versus project operating model. In a product model... our teams are being asked to deliver outcomes maybe in a project model they're being asked to deliver outputs in a product model a team is being asked they're typically working on something that's evergreen like they're trying to drive engagement they're going to do it forever whereas in a project model they're here to stay the products are here to stay a product is here to stay the team is durable they're working on that part of the product over time whereas with the project maybe the team's not durable they change team members every project. A project has a start and an end date. We roll off one project and roll onto the next project and never look at that past project again. So that's just, if you're not familiar with these terms, those are some of the differences. And we're seeing across the industry, big shift from a project operating model to a product operating model. Yeah, big shift is maybe we can unpack big shift a bit because that basically in the beginning of software development, all software development was really, really project based. Yeah. Because people thought and we learned that this is not the case, but people thought that you can collect all the requirements for a particular piece of software. Then you bring these requirements to the developers. Then they work on these requirements for a very well defined slice of time. And then they finished magically with what they actually were tasked to do and they release it and then it's done and people go use it. And a lot of it comes from us working on software that was basically burned and shipped on CDs. So this is what we're talking about, right? So there was a start date and an end date, the date. Yeah, exactly. We were shipping stuff on physical. kind of drives um and i think this is what where a lot of the things come from and a lot of the old reflexes come from and it some of that because it's important to understand some of that most of it made sense in the past yeah so all this project planning it was basically the only way how you could run such a big endeavor to some extent there there could be improvements to that way of working definitely but still just that people understand that's what we're coming from and project operating models are not necessarily bad. Correct. Yeah. And I would argue even today, there are lots of instances where a project operating model is the right model. So let's talk through some of these cases. First of all, we're shifting to more of a product operating model in cases when the thing that you're working on is evergreen. I think this is a really important thing to remember, right? So if you work at Netflix, There's never gonna be a day where you decide, we solved the problem for how people can choose what to watch. We're done. Right? Never gonna happen. It's an evergreen challenge. We can always get better at it. So we put a product team on it. The team is durable. The outcome is durable. Help people find something to watch. And we work on it for the rest of our lives. That is what's driving- Company life maybe, but yes. That is what's driving the shift from project to product is we're recognizing there's evergreen challenges. Now, there's still going to be challenges that are not evergreen. GDPR just became law and we have to comply with it. Okay, great. Unless GDPR changes every year, which it doesn't seem to be doing, we don't have to assign a durable product. A dedicated standing team, yeah. For this forever. We're going to just create a project team. go figure out what it's going to take to comply with this new regulation. Now, to be clear, there are some regulations that are constantly evolving and we might have a product team working on regulatory work. But if we're talking about a one-time regulation that's fairly simple to comply with and it's just a project, a project team is fine. Yeah, and the EU currently accessibility, for example, is such a topic. So accessibility becomes a mandatory thing for websites. That's something every company needs to look into right now. And this is a one-off thing to some extent. Maybe. So I think accessibility is in the gray area, right? So I would argue with accessibility... No, but complying with the newest regulations, accessibility-wise, on your website, that's maybe a one-off thing. Bingo. Okay, so I have this example in my own business. I'm trying to improve the accessibility of my courses. This is an ethos of value that is evergreen for me. But right now I have a one-time project of I have a backlog of course videos that don't have subtitles. That's not evergreen. It's a backlog that I have to just get through. It's a project. But this ethos of I want my courses to be more accessible is an outcome that I can iterate on indefinitely. And so in all of our work, we have projects and we have evergreen outcomes. And even an outcome-driven team. might take on a project that has a beginning and an end. Right? So I think what's helpful about these models is they give us a way to think about... It's a framework. It gives us a way to think about our work. And with any framework, we did a whole episode on the value of frameworks, we can look at where they work and we can look at where they fall apart. And I think what's most important that we do is we don't get dogmatic and... turn this into like a dichotomy that's not there it's a spectrum we have projects we have products yeah i was about to add exactly that because i particularly see product teams that are on the edges stakeholder management wise often are interfering with teams departments that are more used to the project operating model sometimes hr for example they have a lot of projects going on and they do have an end date to it and sometimes they're done right so if they have an open position to hire somebody and then the position is filled and so there's not much more to do there and there are various for example finance oftentimes if they create their annual report and they need a lot of reporting for that so for them that's a project once the annual report is printed or in a pdf format then they're done with this project but still they need to drag in some of the team members, maybe the product person, because they need some data. And then I see often product teams, product people being so confused about this different modus operandi. And that's basically what you were saying, like we should not get too dogmatic about how people run certain initiatives. And product people should still, even if your product is a product and you are subscribing to the product operating model. you still need to be flexible enough to work with other teams and other departments in a more project oriented manner. And I actually think for any type of work, it can be really helpful to ask, what would it look like to work on this from a project mindset versus what would it look like to work on this from a product mindset? And even your HR example. So if I need to hire somebody, if it's an urgent hiring need, I might look at it as this is a project. I need to get it done as quickly as possible. But I also could look at it from a product mindset and say, okay, well, this is urgent, but I do need to hire. I'm a four person company and I'm going to have to hire 50 times over the next three years. And what's my process for that? And this is an evergreen challenge. And how do I hire well? And so even the same piece of work can benefit from a project mindset and a product mindset. And I see a lot of product teams working in a product operating model that sometimes could benefit from a project operating model. where like let's say that you're integrating with an identity management system and you're trying to figure out how do we do usernames and passwords. This is a one-time project. You're not going to change this on a regular basis. Like we don't have to suddenly think about well what's our outcome and let's go explore the opportunity space. Now maybe you do. Maybe there's something unique about your product that does require that you innovate around identity management. But for most of us We're going to go use a tool like Okta or we're going to go do a single sign-on solution. Right? Like we're not or we're going to use Outlook's directory or whatever that product is called. We're not reinventing the wheel here and we can think about it from a project mindset. And maybe that project lives in a under the scope of an outcome and you're still an empowered team. Like empowered teams still do projects. Right? So I actually like to think about this as two different lenses. We have two different frameworks. How do I think about my work in the context of one framework? How do I think about my work in the context of the other framework? Given what I'm trying to accomplish and the constraints that I'm working with right now, what's the most important model? Yeah, and over time you will see pattern. So for example, if it's partnership work, so if it's kind of including an external party, it's... more likely to be easier handled under the project model or something like that. So that's another thing that over time you can observe in what situation I'm more likely to tend towards one or the other operating model. And then it gets way easier to flip between the two or to know which one is the right one for this upcoming task to pick. Yeah, I think there's some things we can look for, like if I'm operating in a project model, how do I know if I should shift to a product model? Or if I'm operating in a product model, how do I know if I could shift to a project model? So I think for me, project to product is easy. If I'm doing a lot of work over and over and over again, and it's always urgent, it's always a crisis, it's always a project, I'm always hustling, it might make sense for me to take a step back and say, Is there a product mindset I can take to this? We see this a lot with consultants. I'm amazed at how many consultants do a custom proposal for every client. And like they don't have a template. They haven't productized anything, right? They're just, they're scurrying, right? They're hustling for every project. It might make sense to take a step back and say, is there something I can productize here to make the next project easier? But I think we see the opposite problem on product operating model teams where... they turn everything into a product and they over engineer things and they over design things and they over systemize things for something that's going to occur one time yeah i totally agree if it's going to incur one time maybe just treat it like a project yeah and i totally agree and to to the earlier explanation i always have this rocky bilboa it ain't over till it's over um poster in front of me Sorry, but that's what I'm kind of having. When you have this moment, it ain't over till it's over moment, then it's most likely that you should switch to the product operating model. Because then it's a project and the project is coming back like a boomerang and you have to reopen your project because the project is not yet finished. And if you kind of in this kind of vicious loop and vicious cycle, then maybe it's a product you're working on. Yeah, you know, this is making me think about feedback loops. Like how do we know when we're done? And I think a lot of the product world, we have feedback loops with customers and customers help us understand when we're done. Yes. And I think in projects, sometimes we're done when the work is completed, but not always. So like if I go back to this hiring model, like if I'm on an HR team and I filled a seat, it feels like my work is done and I'm done with my project. But what if that employee you hired only lasts three weeks? That's a feedback loop that maybe your project wasn't done, right? And then you've realized that the pipeline and the funnel actually is the product that you should be working on and optimizing for. Or how you're evaluating, is this a good fit, is a problem, right? So I think the other thing to think about projects versus product is what's your feedback loop? How do you know you're done? How do you know you did a good job? And that can also help you shift between project and product mindsets. Yeah, I agree. All right. Anything else on this nice topic? No, I love it. All right. Thanks, Theresa. Short and sweet. Thanks, Mitra.

Can an organization operate with both a product and a project mindset—at the same time? In this episode, Petra Wille and Teresa Torres unpack one of the most common operating model questions in product organizations today.

They dive deep into the differences between project and product operating models, when each one makes the most sense, and why the answer to “either/or” is usually “yes, and.” From legacy software roots to modern product teams juggling compliance work and customer outcomes, Petra and Teresa explore real-world examples, practical frameworks, and the importance of staying flexible.

Whether you’re deep in continuous discovery or trying to modernize legacy workflows, this episode offers clarity and nuance around how we frame the work—without getting dogmatic.

In this episode, we cover:
✅ The Big Question
Can product and project models run side by side?
✅ Defining the Operating Models
Breakdown of product vs. project models. Why outcomes vs. outputs matter.
✅ Why the Shift Happened
How the history of software delivery shaped our current challenges.
✅ When Project Models Still Make Sense
Examples like GDPR, accessibility, and other one-off initiatives.
✅ Gray Areas and Edge Cases
Accessibility, internal compliance, and examples from Petra’s course work.
✅ Framing Work as Product or Project
Why even product teams need to think in project terms sometimes.
✅ Working Cross-Functionally
How to collaborate with HR, Finance, and other departments still in project mode.
✅ Dual Lenses, Not Rival Camps
Seeing your work through both frameworks, depending on context and constraints.
✅ Pattern Recognition Over Time
Learning when to switch models based on repeating challenges.
✅ Feedback Loops and “Done-ness”
How feedback loops reveal whether work is actually finished—or just paused.

Key Takeaways:
⚫ Don’t get dogmatic: models are tools, not rules.
⚫ Project models work well for one-time, compliance-driven work.
⚫ Product models shine with evergreen challenges and durable teams.
⚫ You can—and often should—use both lenses.
⚫ Feedback loops help determine whether something is truly done.

Resources & Links:
Follow Teresa Torres: https://ProductTalk.org 
Follow Petra Wille: https://Petra-Wille.com

Mentioned in this episode: 
The Product Operating Model by Marty Cagan: https://www.svpg.com/the-product-operating-model/
General Data Protection Regulation (GDPR): https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
Product Discovery Courses by Teresa: https://learn.producttalk.org
Okta: https://www.okta.com/iam-identity-and-access-management/'
Outlook: https://www.microsoft.com/en-us/microsoft-365/outlook/email-and-calendar-software-microsoft-outlook

Have thoughts on this episode? Leave a comment below.
#AllThingsProduct