Moving to the Product Operating Model, w/ Marty Cagan

[Music]

Thanks, everybody, for coming, and thanks to Mike and the crew for inviting me. It's actually my first visit to Cleveland, which is kind of hard to believe after so many trips to the general area. I enjoy being here and seeing this beautiful weather and beautiful city.

Right now, I wanted to talk to you about the product model, which is really just a new name for something I've been talking about forever. I want to give you a little bit of that context. I don't even want to spend any time really on me, other than to say that the reason I started Silicon Valley Product Group was to share the practices that I saw in the best product companies. I grew up in those companies, and then I started visiting other kinds of companies, and you realize there's a big difference.

So I thought, well, I'm going to write. Initially, it was just a desire to share in just blog articles some of those differences that I saw. For many years, I would talk about this as the difference just between the best and the rest. I didn't really want to give it a name, but you know, just the difference between the best and the rest. Mostly, it's practices, its principles. We'll talk about that.

But I will tell you, I wrote the book "Inspired" to share the techniques of great product teams, and I wrote the book "Empowered" to share the techniques of great product leaders. But by far, the most common question I get, in a million different forms, is from people anywhere in the world. That's the cool part. They say, "Well, I read those books. I would love to work like that, but our company is miles away from working that way, just miles away. How can they possibly change?"

So that was the motivation for this new book, which is called "Transform," because basically, in our terms, what they were asking is how do they possibly move to the product model? When I decided to write that book, I couldn't keep pushing off this need for a term. I'll be honest; I don't like introducing new nomenclature. I think that our industry already has too much, and it's very contentious.

But I was going to write this book about how you move to this new way of working, you know, how the best companies work, and I needed a name for that. All I knew for sure was I didn't want to use the term "product-led company." I didn't want to use "product-driven company." You've all heard these terms, and you know it's not like it's the end of the world or anything. They're not terrible, but in most people, it gives the wrong connotation. They think it means product management taken over, which, of course, is just the opposite—not that at all. But I didn't want that baggage.

So I actually wrote an article and shared some of the terms that people were using out there. Atlassian was one of the companies I worked with that was using the term "product operating model," and a handful of others. A lot of companies shortened it to just "product model," and I said, "Well, that's good," because the nice thing about an operating model is it's not a process. If you've followed any of my writings, you know that's a good thing.

To me, it's not a process; it's a conceptual model. In fact, just a few weeks ago, I had a terrific visit to Stockholm, and I had a chance to sit down with several of the product coaches from Spotify. I mean, I will tell you, I'm a longtime Spotify fan, and everybody kind of knows they have something that is often referred to as the Spotify model. But a lot of people totally misinterpret it. They think it's tribes and squads and stuff. That's just—I joke with them—that's just their funny Swedish terms for what we all use.

What's really going on is they are one of the best examples of companies following the principles of the product model I've ever seen. If you separate out the little Swedish isms and you separate out sort of the Amazon religion and the Apple religion and Netflix's religion, if you pull that out, you find a set of very consistent principles. To me, that's always been what defines a good product company—those principles. Even though the cultures can be very different, the CEOs can have very different rhetoric, when you look inside, this is what's going on.

So I chose the term, adopted the term "product operating model," "product model," and that's how I'm referring to this. So this talk is really, "What is that?" That's actually a lot harder question than it might sound like. I've spent the last year trying to force myself to—it's a lot easier just to wave your hands and say, "This is how the best companies work, and the rest don't do that." That's easy.

But to actually enumerate the competencies, to enumerate the product concepts, to enumerate the product principles, and decide what really is a principle and what's just good stuff to do—that was hard. I've been just coming out of a year of doing that with my partners, and I'm now sharing that. That's what I want to do here with you.

All right, so the way I like to describe it is at the highest level—then we'll double-click in—at the highest level, there are three dimensions that really define how a good product company works. Then I'm going to define four competencies that are critical to work this way, I would argue, and then I'll describe five product concepts. This is really what we do in order to create great products.

So three dimensions, four competencies, and five concepts. If I had an extra hour with you, I'd also go through the 20 product principles, but that's a lot more depth. I will, though, give you a sense of those principles. I don't think any of them are going to surprise you, especially if you've had any interaction with any of these companies.

Okay, so let's start at the highest level—the three dimensions of product. When we look at a company, the first thing we look at is how they build. Pretty fundamental: how do they build, test, and deploy product? Now, for so many companies, this is really why they moved to Agile—to get their act together in how they built.

Unfortunately, today, you can't just say "Agile," because so many companies today have really totally hijacked the term. So honestly, if a company tells me they're Agile, I don't know if they're really Agile or they just have fallen for one of the fake Agile stuff. What I usually have to do is say, "Look, forget the buzzwords. How often does each product team release?" Pretty basic, right?

If they're not releasing—well, let me put it this way: if you're not releasing at least every two weeks—good teams, of course, are releasing much more frequently than that—but a minimum is to release each team independently every two weeks. If you're not even doing that, sadly, you don't even have the benefits of basic Scrum.

So I'm speaking to any of you who are still doing monthly or, God forbid, quarterly releases. Ten-week releases? I don't know what those people are thinking, but all I can tell you is you cannot take care of your customers the way you need to, and you can't do the other dimensions of the product model we're going to talk about with that as your foundation.

So normally, the first order of business for a company is to address how they build. Now, for a lot of the companies I know, they did that 20 years ago. That's not an exaggeration. A long time ago, they moved to continuous deployment. It's not about whether you have Agile coaches; it's not about whether you have the rituals of Scrum. It's about whether you are consistent, frequent, small release vehicles. That's really critical.

Okay, but hopefully most of you in the room have already been doing that for a long time. So now the question is, what are you going to do with that skill? That gets into the second big dimension of the product model, which is how do you solve problems? This is really the difference between a feature team and a product team.

A feature team is basically there to implement the features and projects on a roadmap that's usually driven by stakeholders. It could be driven by salespeople; it could be driven by customers, whatever. But you're basically there to implement solutions that have been conceived by normally others. Feature teams can still be useful, don't get me wrong, but that's not where good products come from.

What we're talking about here is introducing the concept of product discovery. In this model, instead of giving teams features to build on a roadmap, we give them problems to solve. This was the original and still real intention of OKRs: to give a product team—not a person—a problem to solve and a measure of success.

The reason we do that, the reason Andy Grove wanted to do that, was to empower the team to come up with the best solution they can. So that's the difference between an empowered team. They're given a problem to solve, and the team is asked to come up with the best solution that meets those needs. It doesn't mean they get to pick what they want to work on; it means that they get to come up with the best solution to the problem they've been asked to solve.

It could be a customer problem, or it could be a company problem. A lot of times, it's both. All right, so building the skills to do product discovery—what does that really mean? It means you've got a problem to solve, you've got a clear measure of success, and we have lots of ideas that might solve them. We try them out, mostly with prototypes.

If you want to know why Figma is worth $20 billion, it's because they're really good at helping teams do this. So they try out ideas, and what we're doing is we're going until we find a solution that's valuable, usable, feasible, and viable. We'll talk a little more about that in a minute, and then we use our building skills to build, test, and deploy.

Okay, so that's the second dimension: how do you decide which problems—how do you solve those problems? But what that doesn't do—and I want to point this out because this is important for a lot of companies that are moving towards what I'm describing—if today your stakeholders are used to driving by giving you roadmaps with features, it's not hard for you to take that feature request and reverse engineer the problem it's trying to solve and have a little discussion with them.

Honestly, this discussion just takes a few minutes—understanding the problem and then understanding what success looks like. You can do that, and it's a good thing to do. In fact, that's called an outcome-based roadmap. You may have heard of that. Unfortunately, very few people use outcome-based roadmaps. I wish more did, but that's all they are. It's super simple: you just reverse engineer the feature or the project to the problem to solve and the measure of success.

But now you have to ask the question: are those problems that we're being asked to solve really the most important problems for the company to work on? Because fundamentally, a company is going to live or die based on the choices it makes— which opportunities your company pursues, which threats you decide to take seriously.

That's how we—if you want to know, pick any of your favorite companies today. I'm so impressed by Stripe. They are hitting on all cylinders. They are doing so well. They are good at all three of what I'm describing, but especially this third point, which is how you decide which problems to solve.

Now, in most companies that are feature team companies, there really is no product strategy. That's not meant as a sarcastic statement or anything; there just is no product strategy. What they've done effectively is that the CEO has basically allocated the resources—the different equivalent of engineers—to different stakeholders.

So marketing might have the equivalent of 10 engineers, and International might have the equivalent of 20 engineers, something like that. Now, that sometimes is referred to as the peanut butter product strategy, as in spread very thin. That's what you're doing; you're sort of spreading the strategy over the company. That's not—doing a whole lot of minor things.

The best product companies are much better at deciding what are the things that really can move the needle for this company. That's what product strategy is really about: making the decisions on what are we going to focus on, what are the threats we're going to take seriously, and all the rest we're not going to do right now.

This takes discipline for sure, but it also takes some skill, and I would argue this is the third and probably the most impactful dimension of the product model: how do you decide which problems to solve?

Okay, so I would argue strong product companies are doing those three things well: deciding which problems to solve, knowing how to solve problems well, and knowing how to build, test, and deploy those solutions. So at the high level, that's what I'm talking about.

So let's double-click now on the competencies. Now, there are lots of different people that contribute to a product team, but there are four roles which I argue, if you have not been running this way and you decide to change your company, transform to the product model, there are four competencies that are probably going to be new.

I will also share with you right now the biggest single reason companies fail when they transform is usually because they don't take this seriously. They think they already have product managers; they think they already have designers, but they often don't, and that's a real problem in our industry.

As everybody probably in this room knows, there isn't just one definition of a product manager out there. There are some very different definitions, and I don't think it's about legit and illegitimate definitions. I think what's really going on is there are feature teams and there are product teams.

In a feature team, all of those definitions you hear that sound a whole lot like project management—that's what they are, because the job is much more about herding cats than it is about defining solutions. On the other hand, if you're talking about a product team in the sense we're talking about here, it's a very different job. Project management is not this job.

So many companies have people—and this has been exacerbated because, frankly, there's a third kind of product manager out there, which is called a product owner. Product owner is not ever supposed to be a job. Unfortunately, this is another one of those—I mean, it's a—I tend to rant about this one, but a lot of Agile coaches thought that never done product thought that they could teach product owners how to be a product owner, and the result is sort of plain to see.

But in a delivery team, which is not even a feature team, there is a role for a pretty close match to an Agile CSPO or PSPO product owner. I want to be very clear, though. I want to believe that if you're in this room, you know that you do not want to be a product owner. That is not interesting; that is not helpful. You're not helping your company; you're definitely not helping your customers.

So the first thing you need to do is promote yourself. You need to become—I mean it—at least become a feature team product manager, at least. If not, I hope more and more of you will want to actually be a product manager in the sense I'm describing, because I meet so many people that tell me once they learn about product management, they really want to do that job.

Then they tell me they joined a company that was feature teams, and they get to do none of that. It's basically just project management. That is not what they signed up for. I don't—I mean, if that's what you want, then I'd say that's great, but if that's not what you want, I want to help you understand the difference, what you need to do.

I will also be the first to admit that it's hard. This is a hard job to be a true product manager in the sense we're talking about here in a good product company. It is a hard job.

Now, it can be still to find lots of different ways. I always like to talk about the risks in product. There are always these four risks: value, usability, feasibility, and viability. The product manager is on the hook for viability, which is the primary thing they spend their time on, which is to make sure the solution works for the different parts of the company.

Think about it: who else on the product team knows whether this is something that marketing is going to be able to market, or sales is going to be able to sell, or finance is going to be able to fund, or the company can monetize, or it's compliant, or it's legal? Do you think your designers got time for that? They've got a big job; we're going to talk about next that is not that.

Do you think the engineers are going to do that? Not even close. They have a huge job. Not that this is the product manager. This is one of the hardest things about becoming a product manager: learning enough about the rest of the business that you can represent those constraints to make sure that everything that's built is viable.

Now, we'll talk about usability from the designer and feasibility from the engineers, but the other big one, which is really the whole team, but the product manager is the one accountable for this, which is value. Value is usually the hardest of all. That says that whatever you build, your customers believe it's sufficiently better than everything else out there that they will buy it or choose to use it. That's the bar.

It's not just usable. Feature teams don't sign up for value; they only sign up for usability and feasibility. But a product team also has to sign up for value and viability. That's what makes this job so hard. It's also why so many people tell you they love the job. They feel like they're really training to be an entrepreneur, because this is really what entrepreneurs do: value and viability in a startup.

So that's the product manager. It's weird to quote yourself, but I still haven't found a better one. That's why I had to write this, because I couldn't find it anywhere clearly. But you know, I think this is true: behind every product, I think you'll find someone that deeply knows the customers, that deeply knows the data, the business—your business, your industry—which includes your competitive landscape. It includes the enabling technologies, and that they are constantly working to create value for your customers and for your business. That's what a product manager does.

So just contrast that with what they teach in a CSPO class. I mean, we're not even in the same planet. So there are some responsibilities that a product manager has that pertain to delivery. Remember, the product manager ultimately is responsible for discovery; this is what this is. But you're also there to make sure it gets delivered.

As part of delivery responsibilities, you have the product owner responsibilities if your team is using Scrum or Kanban, and that basically means you're prioritizing the backlog. You're spending some time in Jira each day. It's nobody's favorite thing to do, but it's part of the job. It's a tiny part of the job. If you've actually done your job in product discovery, it's an easy part of the job. If you haven't, that's why Sprint planning turns into a nightmare when you haven't.

All right, so that's the first role: product manager. If you want to try out, if you're in a company using feature teams today and you want to try to move to product teams, which I really hope you do, the biggest single factor in that success will probably be you and your ability, your willingness, and ability to do this—to learn these skills, to represent these things on your product team.

What I can promise you is that even if your company decides it doesn't want to change, you will have helped your career dramatically. I've never seen a product manager learn these skills and not be better for it, so I really hope you do.

That's just the first competency. The second competency, which of course you know, is product design. But you probably also know that in a lot of companies, they don't take this seriously. To them, this means look and feel; it means graphic design, visual design. It doesn't mean the whole experience in a product.

In the product model, this is one of those very clear things. You go to a good product company; you will see a very strong product manager, but you will also see a very strong product designer. This is a terrific role. About 10 years ago, we had a real shortage because the programs creating these designers weren't that many. Today, it's much better, and I find great designers at companies all over the world.

But the product designer is certainly responsible for ensuring that whatever is built is usable—that's pretty straight. But more importantly, they're responsible for making sure that how our customers experience the value of the product—that's them. Because you experience a product's value, I mean online, offline, whatever it is.

One of the things you'll hear—or you won't hear, I should say—too many people talk about digital experience versus digital product versus the thing is virtually every good product team I know, they don't have that distinction. It's anything. Lots of our experiences are digital and non-digital both. Most experiences—there are some that are pure digital, of course, but most of what we do—I mean, I took an Uber from the airport. Think of how many digital and non-digital experiences are represented in that experience for a rider, for a driver. That's normal today.

So we don't just talk about digital. A product designer is looking holistically at the entire experience. All right, I love this quote from Steve Jobs: "Design is not just look and feel, right? It's how the whole product works." This is what we mean by product designer.

It's probably worth saying this is another one of those easy to tell if you're working in a feature team where the product manager is really a project manager. You probably don't have a professional product designer. That kind of rare, and it would be kind of overkill if you did. So what happens? The product manager likes to play designer, and you get a lot of amateur designers out there.

Now, of course, it doesn't mean—I know some product managers that are also excellent designers, although they're pretty rare. But the big thing I point out to those people is if you're doing the product design, who's doing the actual product management? Because that's a huge job, and you're not doing it. So who is?

So we really want to make sure that we have strong product managers and strong product designers. If you're one of those people that can do both, it's awesome, but I will always warn those people: you're signing up for a lot of work. I mean, it's two full-time jobs.

All right, let's talk about the engineers. This is another one of those huge differences. So many companies I meet—I told you I was just in Europe—so many companies in Europe, their engineers are not even employees. So often, they're outsourced. Let me just put it out to you there: if any of you—if your engineers are outsourced, you're not ready for what we're talking about. You know, this is—that's not really a non-starter.

What's going on is the company does not understand the role the engineers actually need to play. That's what's going on. Some finance person is probably looking at the loaded cost of a developer and saying it's cheaper here versus here. I might as well do it in India, and they're not looking at actually—not just the fact this is one headcount, but they're not looking at how the role is different in a product model company.

The engineers are there to care just as much about what we build as how we build. This is why a small number of actual employees will totally outperform a much larger group of outsourced engineers. It's not even a fair competition. So you need to realize we need the engineers to engage.

This is one of the most obvious differences. I think I've seen this from the very beginning when I first started being exposed to non-product model companies. But the most obvious thing is the engineers are not in the room when it happens. A bunch of stakeholders are, and by the time the engineers see it, it's Sprint planning. It's already way too late.

The engineers need to be there right with the product manager, right with the designer—especially the tech lead—in order to make sure we're coming up with a solution that works. It means it's valuable, usable, feasible, viable. I'll talk about that in a minute.

All right, I think Bill Campbell—he's literally the guy that coached Steve Jobs at Apple, Jeff Bezos at Amazon, and Larry and Sergey at Google, and then several other leaders at those companies. But the same coach told them the same thing: nothing is more important than empowered engineers. An empowered engineer just means that the engineer is not just there to code; they're there to come up with the right solution.

So that's a pretty big statement. Speaking of Andy Grove, because there's one more competency that really is critical, and it's generally missing. Even though companies that are using feature teams have people called product leaders, they don't have this role. It's a very different role.

But the whole product model depends on having product leaders that do two big things. I love this quote: "The only two things that really get in the way of good work: the first is your people do not know how to do good work." This is important to realize. This is not something that's taught in most universities. In fact, it's often not done in a lot of companies. If you hire somebody from another company, you have to teach them.

And second, they do know how to do their good job, but they aren't—they don't care; they're not motivated. Those are the two things leaders are responsible for, and that turns into the two main responsibilities: coaching and strategy, also known as strategy as part of strategic context.

Here's the thing that needs to be—it's not obvious to a lot of people. You probably have figured out if you're going to have empowered product teams, you're going to be pushing decisions down to the product teams. That's the idea. But if you want those teams to make good choices, you need to push more than just the decision to them. You also need to push the strategic context.

How could they make a good decision if they don't understand the holistic strategy, if they don't understand the holistic vision, if they don't understand the team topology, the bigger picture, what teams are working on? If they don't understand the product principles that they have, you have to push that down as well so that they can make good choices.

That's what's required. That's why Netflix has a mantra, which is "lead with context, not control." They want to have empowered teams, but they have to give those teams the context to make good decisions.

All right, so those are the four competencies: product managers in the sense that I'm talking about, and I hope genuinely the sense all of you want to do; second, real product designers; third, engineering, in particular the senior engineer on each team, the tech lead; and finally, product leaders.

And just to be clear, when I say product leaders, I mean the managers of product management, product design, and engineering—those three.

Okay, now you've got these amazing people. What do you do with them? There are five big concepts in the product world that matter. Let's talk about them one at a time.

The first one is product strategy. Product strategy is probably—I mean, honestly, my favorite thing to do is one of the concepts we'll talk about in a minute, which is product discovery. That's, to me, the most fun part of product. That is very hands-on. That's why product teams are creating; that's how they create. It's where innovative products come from.

That said, I have to admit that product strategy is even more impactful to a company because product strategy is how you even decide what are the most important problems to go do product discovery on. So I've been a student of both forever. It's just more fun to do product discovery.

But product strategy partly because product strategy is a whole lot of work. You have to immerse—you have to immerse in insights from your customers, every insight you can. You just heard one of the sponsors talking about tools to help you get insights of what's going on. Product leaders live and breathe those insights.

Insights come from our users and customers; they also come from the data. And today, of course, many of the most powerful insights are powered by data. There's not only—you know, we can use data to make decisions for our products; we also use them to power our products today.

But fundamentally, the data often holds the key to where we need to invest our time. And then, of course, insights from technology—for example, generative AI is a new emerging technology that's being used today in so many different companies for truly helping you disrupt spaces.

It doesn't mean it's for everything; it's not. People are figuring that out, but it also is pretty amazing for many different domains, many different spaces. You know, in product, and this is what I love about product, we are always asking ourselves, "Is there a new way? Is there a new technology? Is there a new insight? Is there a new tool that helps us solve longstanding problems in ways that our customers love but work for our business?"

Product is all about combining that need with what's just now possible. And yes, to insights from the technology are things that are just now possible. There are also a lot of insights coming right now from the industry—the industry representing, depending on what you're working on. If you're working in media, if you're working in retail, if you're working in any of the tech brands, it's all about how—what's going on in different parts of the world. Can you leverage that to help your customers?

So the reason product strategy is so hard is because you're living and breathing all these insights. Once you've done this for several months, people start noticing, and what they'll often say is, "Oh, you have such great product sense." All that really is is a recognition that you have been doing this.

This is why product sense is not something you're born with; it's something you invest in and develop, and it comes from these insights. Insights can come from anywhere; these are just the four main sources.

All right, let's talk about the next product concept. This is probably the most basic concept of all, which is a product team. A product team is small, durable. These are people you don't yank the people off every week—truly cross-functional product design, engineering, empowered with problems to solve, and held accountable to results.

Probably one of the most important principles overall, but especially when it talks about product teams, is collaboration. Because the nature of how the people on the team work is all important. Innovation really does depend entirely on product design and engineering approaching a problem together.

Now, I'm pointing this out because a lot of product teams, they give lip service to things like Agile, but what they really do is some product manager comes up with a PRD or some other enumeration of requirements, and then that product manager will throw it over a wall to a designer.

That designer will be told, "I need—we need workflows; we need comps." They'll come up with interaction design and visual design, and then the product manager and designer will take that whole load of documentation to Sprint planning. They'll sit down with the engineers and say, "We need you to build this." That is literally waterfall. That is literally what made waterfall bad.

So if that's how you're working, you're missing the whole point. The point is product design and engineering are bringing three different skill sets to the table. We need each of those skills. The designer is looking at the experience; they get inside the heads of the user. The engineers are looking at the enabling technology and looking at the different ways they could solve this problem.

The product manager is looking at the implications for marketing, for sales, for finance, and they're making sure that nothing is either violating any of those constraints—unethical, not viable for the business—and they're constantly going back and forth until they find something that really works.

So the essence of product discovery is this: essentially, to be able to try what works. We're trying to very quickly and inexpensively determine whether or not a product idea is worth building. We have lots and lots of ideas; that's never been the problem. The problem is how fast—how good are you at trying out those ideas to separate the good from the bad and get it to be good?

One of the principles around ways of assessing through all these ideas is to assess the product risks, like I said before. You know those risks: value, usability, feasibility, and viability. But it is essential that you look—now, not everything we work on is risky or not equally risky. Some things are no problem, but other things are very risky.

All right, and then the concept of delivery. I alluded to this earlier, but if you're not releasing small, frequent, uncoupled releases—ideally every day, many times a day—that's continuous deployment. You really need to get to the point where you're at least doing it once every two weeks.

Jez wrote the book "Accelerate." If you—even that, though, we're—look what year we're in, and if you're still—if you still doubt that continuous delivery is the way to go, if you still doubt that, read that book. It's got all a theory from years of theory about why that—the truth is continuous deployment is the key to both quality and speed.

Now, continuous deployment won't help you get a better product necessarily, right? That's discovery. But whatever you decide you're going to build, continuous delivery will do the best job at getting that to your customers reliably.

So it really bugs me that we need to talk about this in 2023. To me, this is so proven, so well established. I do want to be clear: it's not just small, frequent releases. Occasionally, I'll run into a company where they're not even instrumenting their software. They're literally not instrumenting. They don't know when they deploy something if it's working or not, and I have to explain to them that they're totally flying blind.

They're absolutely pouring good money after bad. Obviously, you need to—this is referred to as telemetry in the engineering world. You need telemetry at all levels, everything from, "Is AWS working as it needs to?" and they provide that telemetry themselves, up to our application, to our user-level reporting, monitoring—all this has to be in place.

The ability to run A/B tests, the ability to release capabilities dark—I mean, I'm talking about things that should have been in place for many years. But the whole product model depends on these things. How do we prove outcomes if we can't even see if it's working? I mean, this should be obvious, but to a lot of teams, it's not.

All right, and the last concept is really product culture. What is the nature of the company and the teams that you're having? I love this definition from Bezos, because he's really—this is a great definition. I would argue not just of culture but of product discovery: understanding that you need to fail early and iterate until you get it right.

That's a good summary of discovery, but it's also a good summary of the culture you need in place. That's why it's true in so many companies there's a deeply rooted fear of failure, and that leads to risk aversion, which undermines the whole product model. So you've got to tackle this too.

All right, the last point I wanted to mention to you is the whole industry throws around the word "transformation" a lot. It's definitely an overused word. So is "empowered." I know that. But what it means to me, to my partners and I, what it really means is moving to the model I just described.

So to me, if all you're going to do is implement Agile—and let's give you credit; let's say you're really Agile, not fake Agile, right? That's good. But that just addresses one of the three dimensions, which is normally the easiest of the three: changing how you build.

So does that mean you've transformed to the product model? No. I mean, is it good? Yes. If you haven't done that, and now you do it, you should feel good about that. But the product model means more than that.

Now, I would argue it means all three of those things: changing how you build, changing how you solve problems, and changing how you decide which problems to solve. I have seen companies, though, improve significantly even when they've only done two of those three, and I wouldn't want to say that they haven't done anything meaningful. They have.

It's just that, let me put it this way: if you are going to be competing against some of the best companies in the world—and this, of course, if you boil it down, this is the number one reason people do decide they need to transform, because now they're going after Amazon or they're going after Stripe, or I should say those companies are coming after them.

If you want to compete against those companies, I believe you have to be good at all three of these things. So yes, that's a lot of work, but I think the rewards are—look at how the stock market rewards those people. It's pretty impressive.

All right, if you want to learn more, there's the—the one in green is not going to be out till March, but hopefully then you'll give it a try. I hope this was useful, and I am very grateful that you all came. I'm looking forward to answering questions over on the mirror side over there in a minute. But if you do have to leave, you've got my email right there, and I encourage you to send me a note if you have a question and you don't get a chance to answer it or ask it.

Feel free to send me a note. Thank you very much, everybody.

[Music]