Marty Cagan: Moving to the product model

Andrew Skotzko [00:01:03]:
Marty, welcome to the show. It's great to have you back. How are you doing today?

Marty Cagan [00:01:11]:
I'm good. Thanks for having me.

Andrew Skotzko [00:01:13]:
Absolutely. It's always a pleasure to have repeat guests, especially ones who are so aligned with the topics of this show. So very glad to have you here. So, first of all, congrats on the book. Here we are at last. Transform number three, how does it feel to be at the end of the process?

Marty Cagan [00:01:30]:
Good to be done. It's a year of your life, basically, that you sacrifice to write a book. It's huge amount of time, but it's nice to do one for sure. It's just a lot of work, and this one was a little bit of a surprise. I wasn't intending to do this one. My partners were supposed to write this one, but little children got in the way for each of them, which I totally remember and understand. So I ended up needing to do it. And all done.

Andrew Skotzko [00:02:08]:
All right, well, congratulations. I'm curious, did you end up having to, did you work with them on writing drafts of it, or did you just kind of reboot the whole thing when you took it over?

Marty Cagan [00:02:17]:
Well, neither of them really got that far, so there wasn't a whole lot to leverage. Although definitely those pieces are there in the book. I'm probably more detailed than you're interested in, but for pretty much everything I write, the partner, Chris Jones and I work together on everything, but lots of other sections my other partners wrote, and then Chris and I would review those. So it's really a mix, really, of all of us. There's content there that's original from all of us, but sort know with anything, you need somebody to kind of put it all together, make it happen, go through all the process with publishers and honestly, just getting all the feedback from all the reviewers and going through everything and making sure you rec. It's so funny how literally experts can. Some can either love a section and the same section could be not loved by another one, and you have to try to understand what's behind each issue and come up with a solution that you really think works. So that's the nature of product, and it applies to books, too.

Andrew Skotzko [00:03:36]:
Yeah, actually, I'm curious about that. Do you think about what of your product models do you apply to your books themselves?

Marty Cagan [00:03:43]:
I actually wrote an article about that because I get that question so often from people who do want to write a book, but honestly, almost everything. And the surprise, maybe, is just because I'm not an author, really, I'm a product person. And so naturally, I think I use the tools. But, for example, every chapter is an MVP on a concept, and I publish not every chapter I publish as an article, but most of them get published as an article. And that way I can get feedback on the article itself, on that topic. Sometimes that topic is just clearly not useful. It's not worth putting in the book. But more often than not, it's like, yeah, the topic is good, but because of all the questions I got, I realized I should have anticipated those questions.

Marty Cagan [00:04:33]:
And so you iterate on the topic, and so the articles become basically chapters in the book, and I actually consider the same risks. You want every chapter to be valuable, so that people say, like, that was worth reading. To me, the biggest insult, really, and this is what I fear, is that somebody reads the book and says, it should have just been an article, right? And I read books like that all the time. I'm like, how did they stretch this two page article into a whole book? It's ridiculous. Filler. So to me, you want to make sure that every chapter carries its weight. In fact, my favorite is when people say, this chapter could be a book. You know what I mean? They say like, that's a powerful concept.

Marty Cagan [00:05:23]:
That's what you want. So the value is the highest risk, in my opinion. When you write, obviously, they have to understand it that really speaks to usability, feasibility. It's more about, like, can this concept be represented in a limited number of pages? I like to force myself to make it clear enough that you can describe complicated concepts in a short amount of pages. And then, of course, you have to make sure viability for a book would be like, does this carry its own weight? Is it accurate? Is it even ethical? You have those same kinds of questions. And so a lot of it really boils down to these topics. And the nice part about getting feedback of these I should also mention. Just like with a product, not all feedback is the same.

Marty Cagan [00:06:15]:
When I publish online, it's to get feedback from as broad a source as possible. How could people possibly interpret this? But I also have a small group of expert reviewers that I know what they know. So if they don't understand something, that's a whole different issue. That's like, I have to fix this. No if or buts. If it's somebody from the sort of general online, maybe I'd fix it, maybe not. It depends on where are they coming from. Sometimes they're like an agile coach.

Marty Cagan [00:06:51]:
I know they have a very different perspective, and I have to decide, do I even want to address that? But if they're one of the expert reviewers, in which case we had half a dozen, there's no question I have to get the draft to the point where they think it's good. So anyway, all that takes a lot of time. That's why it takes a year of your life.

Andrew Skotzko [00:07:13]:
Yeah, absolutely. So I recall we were on that coach, the coaches call, I think, about a month ago, and you talked about you really had to agonize. You said you agonized over the 20 principles in the book, and I'm curious. We're going to get into all that here in just a second. But what was the hardest part of boiling this all down?

Marty Cagan [00:07:31]:
Well, the hardest part is boiling it all down, because when you start, you have literally hundreds of things that you feel very strongly about. Otherwise it wouldn't be there. It's really the same in the product world, right. We have all these things that we are very passionate about, but really less really is more. And so you have to ask yourself, is this really a first principle of product, or is this just something that we like? But a year from now is maybe not even going to be there anymore. So to me, the real test of that will be, and honestly, I try hard in all the books. I don't like to write about current topics. I like to write about things that will be relevant, hopefully in ten years.

Marty Cagan [00:08:16]:
That's the window I use. Who knows? It's very hard to know really what's going to happen, but historically that's proven pretty good. Like, you can read the first edition of Inspired, which was from 2008, and there's very little that I would change because I think it's really about those principles. So we try to do that, and that's really what the agony comes from, is that looking at these things and saying, are these really the core principles that define success for these significant leading product companies? And of course, it's also challenging because every one of those companies has their own words for these things, they have their own filter for these things. And yeah, sure, it wouldn't be hard, it'd be much easier to write this book just using Amazon terminology. The problem is Amazon's terminology is pretty specific to Amazon. And I think what's more interesting is, know, you could talk about what's unique about Amazon, but I think there isn't that much that's actually unique about Amazon. What is special about Amazon is just how good they are at doing the basics of product like the best companies.

Marty Cagan [00:09:31]:
So to me, what's more interesting is not what's unique about Amazon, but what's the same about Amazon and the other leading product companies. And I don't think that's an accident. And that's really where the 20 principles come from. We were literally saying, all right, we're lucky enough to have been in these companies. What is the real common thread that really is accounting for consistent innovation? And that's where the principles come from. I think if you look at the principles, if you would have looked at them ten years ago, they would have been the same basic principles. Now the techniques, of course, have gotten way better. And that's why it's tricky to talk, because some people, when they talk about product management per se, they say, well, in one sense it's changed so much, but in another sense, it's hardly changed at all.

Marty Cagan [00:10:26]:
And what's really going on, if you double click on that, is that the principles have not changed much, at least in the companies that understand the principles. However, the techniques have changed dramatically. The tools and techniques that we have to apply those principles. I would never, ever want to go back to what I learned with just because it was so primitive. I mean, literally, we didn't have the analytics tools we do today. Everything was log file analysis, everything. And this was pre Internet. We had to ship data over phone connections.

Marty Cagan [00:11:04]:
But were we doing those things? Absolutely, just like you do today. The difference is it was a whole lot more work. It was slower, it's more painful. But there is a principle about basically instrumenting everything you ship, so otherwise you wouldn't know if it worked. I was taught that principle in the 1980s.

Andrew Skotzko [00:11:23]:
There you go. Well, let's get into the book and some of the core principles in there. So one of the things that you lay out in the book is kind of this high level sequencing. But before we get into the sequencing, I'd love to just kind of set a baseline foundation for people conceptually. So, first of all, hopefully everybody goes and gets the book. We'll put links to all the stuff in the show notes. It's out now. As of this podcast being released, the book is also out.

Andrew Skotzko [00:11:45]:
So please go get it.

Marty Cagan [00:11:46]:
If you could just lay a bit.

Andrew Skotzko [00:11:47]:
Of a conceptual foundation of what is the product model and who is it for? Because I could see a lot of people being a little confused about, like, does that apply to me? Does that not?

Marty Cagan [00:11:56]:
Well, good. All right, well, let's start with who is it for? I think that's a really basic good question because that could go either way. Some people think it's not for them, and it is, and other people think it is for them and it's not. First of all, because some people want to say to the first point that it's like, well, we're not building a digital product. We're not building a pure digital. We have whole combinations. Most products look at Uber. Is that a digital product? I mean, it's got cars, it's got drivers.

Marty Cagan [00:12:27]:
It's got all kinds of real world things. Most interesting products today are a blend. And so I would argue it absolutely applies. The question is not like, is it all software or something silly like that? The question is, do you believe you need to power your solution with technology in order to deliver the results for your customers and your business? And the answer to that is yes. And in my experience, almost every company today, that's yes. However, who it's not for, if you don't have engineers helping you build something, hardware, software, firmware, something, say it's not for you. So there are a number of people that have classic old it, and what they really do is they manage a relationship with a vendor like Salesforce or SAP, and they don't have any engineers. SAP has the engineers.

Marty Cagan [00:13:22]:
Salesforce.com has the engineers. They don't. They're just basically managing a vendor relationship. I don't think the product model is for them at all. I do think it's for the people that build those products. But it's not. And I mentioned that because I think historically we've seen a lot of methods go sideways. The classic one is agile, where Agile was also done for developers.

Marty Cagan [00:13:48]:
On the other hand, a bunch of overzealous coaches said, oh, you can use it anywhere in the company. And they got a bunch of marketing people together and salespeople together, and they tried to say, you should be running in sprints, and here's how you do your stand ups. And it's like, oh, my God, don't be ridiculous. No, it's not for that. So if you do have, though, a cross functional team, especially engineers that are there building solutions. Building solutions, absolutely. This includes hardware. You could argue it's most important in hardware because the risks are so high.

Marty Cagan [00:14:23]:
But if they're building solutions, then that's what the product model is really about.

Andrew Skotzko [00:14:28]:
Okay, that makes sense. So I guess one quick detail question there. You said you think of those classic almost it setups, right, where you have managing a vendor relationship, and it's really not for them. If a company is outsourcing a substantial part of their engineering effort, would they be a candidate for this model in the sense of, like, you should really not do that and do this instead?

Marty Cagan [00:14:49]:
Yeah, I mean, in that case, they are still building things. They're just unfortunately misguided in thinking that they can save money by outsourcing those engineers. That's a different question. But yes, I would argue the product models absolutely for them. But fair warning, if they're not open to the possibility that they're wasting real money and could do much more by working differently, don't bother, because outsourcing is not part of the product model and something you don't see in any of the strong product companies for how they build their products.

Andrew Skotzko [00:15:28]:
That makes sense. So now that we've talked about who it's for, let's go ahead and actually lay the foundation of, like, what is the product operating model?

Marty Cagan [00:15:34]:
Marty, so you can talk about this at a number of levels and probably, Andrew, just stop me when I reach a level that's too detailed for this. Otherwise, we probably go multiple hours.

Andrew Skotzko [00:15:47]:
Okay, you got it.

Marty Cagan [00:15:49]:
But let's. At the highest level, really, the elevator pitch for the product model is like, instead of just building features and shipping output, it's all about delivering outcomes that's at the highest level. That's what it's about, which most people will both acknowledge. Wow, that would be much more valuable.

Andrew Skotzko [00:16:11]:
Totally.

Marty Cagan [00:16:11]:
But also way harder. Okay, so at the highest level, it's about moving from projects and dates and features and roadmaps to outcomes and business results. So that's at the highest level. Now, if you double click on that, the next level down is looking over your organization. What that really involves is changing, really three things. The first is changing how they decide what to work on. Pretty basic, like how do you decide what to work on? Every company does that somehow because they have to decide. Nobody has enough resources to do every little thing they dream up, so they all have to decide what to work on.

Marty Cagan [00:16:56]:
And changing how you decide which problems to solve, that's the first dimension of the product model. Most of us in the product world recognize that's the topic of product strategy. Like, how do you decide the most important opportunities to pursue? How do you decide the most serious threats you need to respond to? That is product strategy. And normally, all I'll say at this level is each of these three dimensions represents pretty dramatic change to what they're doing today.

Andrew Skotzko [00:17:28]:
Yeah.

Marty Cagan [00:17:28]:
So the first is deciding much higher level skill, what we're going to work on, invest in. The second is, okay, you've decided to invest in solving a problem. How do you solve those problems? In the old way, they probably had a roadmap of features usually picked by stakeholders, by high profile customers, by somebody, but there's a bunch of proposed solutions, and the product team, which we would call a feature team in this model, they're basically to design and build that feature. And when we change that now, instead of being given output to build features and projects, we give them outcomes to achieve. And the way we solve for that outcome is what an empowered product team doing product discovery is all about. They have the cross functional set of skills, by the way, first and foremost, including engineers, to be able to come up with a solution that is valuable, usable, feasible and viable. And once they've done that, they believe they have the evidence to build, test and deploy that, which is now leading to our third topic, which is changing how you build tests and deploy. Because really two things.

Marty Cagan [00:18:54]:
The higher order bit here is if you want to prove outcomes, you need a certain infrastructure to prove those outcomes, which means you have to make sure everything is instrumented, you have to make sure everything's monitored, and you have to be able to do things like an A B test to prove that this feature actually delivers the result it needs to deliver. So there's a whole level of infrastructure and more than what I just mentioned, but a whole level of infrastructure that's needed. And more generally, the product model is about seriously taking care of customers. And if you want to take care of your customers, you have to be able to keep. We often say the most important feature is reliability. And the way we do this is small, frequent, uncoupled releases. Instead of, for example, the company is still releasing monthly, or honestly, very common, but way worse, releasing quarterly. Some companies, even worse than that, they are not able to take care of their customers.

Marty Cagan [00:20:01]:
That is well documented, well known. They are running just way too slow, way too slow. In the middle of that cycle, some customer has a serious issue. You cannot take care of them the way you need to take care of them. So there's a lot of reasons, and the irony is that there's years of evidence that show that this model of releasing lots of small releases, it's referred to as continuous deployment, is both faster, which is not a surprise, but the surprise, higher quality. So if you want quality and velocity, this is what you do. And so the third dimension of the product model is changing how you build. Those are the three.

Marty Cagan [00:20:47]:
Changing how you decide what problems to solve, changing how you solve those problems, and then changing how you build and deliver those solutions.

Andrew Skotzko [00:20:55]:
Okay, that makes sense. I want to check one thing here. So when you lay it out that way, that totally makes sense for me as a conceptual model, is that the actual sequence that makes sense to go in, like when you actually go do one of these transformations, do you need to go in that order, or is the order different?

Marty Cagan [00:21:11]:
The truth is they could all be done in any order and they could also be done in parallel. And there are arguments in different cases for each of those. So it is not meant to be do one, two, three. In fact, the order I described them, the most common way companies transform is actually the reverse order. They start with changing how they build. Most engineering leaders will realize that's why they moved to agile in the first place. But somehow that got hijacked and they kind of lost the agile part of moving to agile. Sometimes they have to really get serious about doing that, but hopefully they did this many years ago.

Marty Cagan [00:21:54]:
The second part then they often tackle is the discovery, because you can do that without even changing the bigger questions of how you decide what to work on. And they get their product discovery skills up to par and then they tackle the strategy. So you can do it in that order. I mean, you can do it in any order. If a company is in trouble, we'll usually recommend that they focus on one business unit first. If this is a big company of one business unit and do all three of those in parallel, there's so many situations when it comes to transformation. In fact, the second half of the book really talks about the different techniques and approaches depending on their situation. And, of course, the real way you answer that question about what is the best way to approach this is by starting with an assessment.

Marty Cagan [00:22:49]:
You have to figure out where they are, and we never know until we do that assessment. You can have a high level conversation with an executive, but unless you go in and look like, where are their skills? And that, you have to talk to individuals, you have to talk to engineers and product managers and designers and their managers and their executive team to really know where they're at. And then you can say, all right, now I understand your situation. I understand the people, the talent you have to work with. I understand the kinds of products you're doing because different kinds of products impose different demands. Right. So all these things have to be done. And then you can say, all right, we think the fastest way to get you to the outcome you're looking for is this particular approach here.

Andrew Skotzko [00:23:41]:
Yeah, that makes total sense. I want to zoom in on the assessment a little bit more. So, first of all, I know there's a section about that in the book. Folks can go check that out. But just for the sake of this conversation, I'd love to hear a little more about what you look at specifically. And one question that came up in a recent conversation I was having with another one of the coach, the coaches. Coaches is, we were talking about this yesterday, actually. And the question that came up was, you could show, let's say, an executive, a list of competencies, of skills.

Andrew Skotzko [00:24:09]:
Okay? You need to have a clear focus strategy. You need to have empowered teams. Whatever the list is, there is a list, and it feels like the risk there is that a lot of folks could look at such a list and be like, oh, yeah, we're good. We're doing that. We got a clear strategy, but absolutely not have those things in reality. And so I'm curious to hear how you think about that both in the context where you go in there and actually do an assessment. But then how do we think about solving that where the person doesn't bring in someone external such as yourself?

Marty Cagan [00:24:39]:
Well, first of all, you're unfortunately spot on. Right? I don't know if you've seen, but my last three newsletters have actually been about this. They're framed as theater. In fact, the one that just went out yesterday is called transformation theater because a lot of companies, they check the boxes, go through the motions, but they don't change anything. They're not taking this seriously. And there are many different, like you said, there's a list, but for each item on that list, and that's what we do in an assessment, of course, is to try to understand what's really going on. In fact, one of the things we warn people of at the beginning of the list is you need to talk to people up and down the organization because you will not get an accurate picture just talking to one. It's so funny because sometimes I'll start by talking with the CEO and I get one view of the world.

Marty Cagan [00:25:43]:
You talk to people, it's not like, honestly, most of the time they know I'm talking to the whole organization, so they're not trying to pull the wool over my eyes or whatever. But the truth is, everybody has their own lens, right? And I have a lot of sympathy for the CEOs because they only see what their organization lets them see. Totally, right? They can't be everywhere at once. I am a big fan of management by wandering around, but that's become virtually impossible in distributed teams. They're not to blame for this. Nobody's really to blame, but you have to talk to people at all levels. And we also say, don't just take one data point. You have to go and circle around and make sure that you're getting an accurate view.

Marty Cagan [00:26:32]:
And then what I like to do, especially when what we learn is so different than the perceptions of, say, one of the key leaders or something, is I like to give them a preview and say, this is what we found. If you think we were really off, you should tell us right now. But here's our evidence. Here's what we found, here's what's really going on. And you can see why we think that. So far, nobody has ever said, I've had a lot of CEOs be like, stunned, but I have had none of them say, like, this is know I don't you talk to, but it's not the case or anything like that. Usually they say things like, I mean, here's one I bet money you have heard many times, Andrew, the CEO says, oh yeah, we have a product vision. I share it all the time.

Marty Cagan [00:27:19]:
Talk to everybody else like, we don't have any kind of vision.

Andrew Skotzko [00:27:21]:
I'm like, what are you talking about?

Marty Cagan [00:27:23]:
We'll sit down and we'll say, I know you believe you have a vision. You probably know your people don't think we understand where that disconnect is coming from. Let us show you what they're looking for. Out of this is very different than what you are looking for out of this. So you can hopefully understand for them to do what they need, they need something different. You're trying to share this and what we're really getting into is probably one of the hardest parts about transformation is you have to win over the hearts and minds of the key people and that you can't just say you don't know what you're talking about or anything like that. That's going to go well, right? You have to say, here's what's really going on and I think this will make sense to you. Once you can see what they need and why they need it.

Marty Cagan [00:28:11]:
They haven't necessarily had the words to explain that or show that. It's not the kind of thing that shows up in a status report or something like that. So you have to double click in on how people are really trying to do their job to see where these disconnects lie. We shared our assessment that we use ourselves, just the partners at SVPG in the book, so you could see the questions we ask. And obviously, once you've asked these questions a hundred times, you get good at knowing what to listen for and how to check, but there's no reason that you can't do this yourself for your own company. I think I do tell people it'll take a few days longer than it takes us, but it's good. You should do this. And if you do it honestly, I think you'll get a lot of value out of it and you'll get a much better understanding of where you are now because that's essential.

Marty Cagan [00:29:05]:
The book describes where we think you want to get to. The assessment is where you are now. And that's the part in a book. We don't know where you are now. We can make some broad assumptions, but they're so different in every company. And then of course, once you've got a good understanding of where you are now and hopefully good understanding of where you want to get to, then you can talk about a transformation plan.

Andrew Skotzko [00:29:29]:
Yeah, that makes a lot of sense. The area, what you're talking about, this disconnect between top leadership and the rest of the organization, it can happen in any of the main topic areas or competencies. The one that I think I see the most frequently, where they think they're doing it one way and the reality is quite different, is in strategy. That's probably the one that I feel like I'm seeing the most frequently. And the two symptoms I'm seeing are they think they have a strategy when they don't actually have a strategy. And then secondly is they think that the strategy is clear and it's been sufficiently operationalized within the organization. But then when I go around and I ask five different people on five different teams about the strategy, I get twelve answers.

Marty Cagan [00:30:14]:
Well, look, the truth is what you just said could apply to all three of those areas, strategy. But you've all seen the discovery issue, where they think they're doing product discovery, but really everything they do, quote discovery on they're building. So it kind of shows you all they're doing is design and code. They're not doing discovery. And the same with agile theater, right. If they think they're doing agile but they're releasing monthly, you don't understand.

Andrew Skotzko [00:30:41]:
You're not doing that at all.

Marty Cagan [00:30:43]:
So we have this theater or this misunderstanding on all three of those areas very commonly, and strategy is a big one. I feel strongly about all three of those dimensions. I do not know a single strong company that's not good in all three. That said, I think strategy is the highest leverage. You can get away with being not so great on the other two. But if you aren't picking the right battles, good luck.

Andrew Skotzko [00:31:19]:
That's where a lot of my work has shifted over the last six months, is helping the leaders I work with to work on that, because it just feels like the biggest weakness that's out there right now. The way I frame it is strategy almost sets the ceiling of value, right? It's almost like the maximum potential value that you could realize with your organization because it's directing all of your resources and then discovery and delivery, how much of that potential value will you actually realize? And so you could be incredible at discovery and delivery, but if you have a local maxima problem and you're just missing the giant opportunity, like, well, you're going to get ten out of ten, but you should actually be getting 1000.

Marty Cagan [00:31:53]:
I like that framing because I think that's spot on. Just to share it with you. I usually take an opposite framing. Still consistent. Just here's where I am often coming from. Most of the companies I work with, they're kind of like the David going against the Goliath, and they're going after these huge companies with literally thousands of engineers. And I tell them the way you beat them is product strategy. If you're smart about how you might have one 100th the size of the organization, the way you make that an advantage for you is that you get the most possible out of those people you have, and that is all about product strategy.

Marty Cagan [00:32:44]:
And I'm like, I can tell you most of those big companies, they do not know anything about product strategy. They don't do it at all. It's just stakeholders all doing their thing local. You can absolutely disrupt them if you put all your wood behind the arrow right there so that you can really make an impact. And the best companies know that Apple, they live this every day. Their products always have far fewer features than everybody else. But they just decimate the industry because they hit the target. Right.

Marty Cagan [00:33:23]:
And same thing, Amazon, I love anything. Their view is if it's a short term thing that we could better use the money to improve the customer experience. That's going to pay off a lot more. They're just so disciplined about that. Filters like, is this really the best use of our talent instead of just chasing 1000 things like so many companies do?

Andrew Skotzko [00:33:49]:
Yeah, because most of the companies, it's the famous peanut butter strategy and it's not even a strategy ultimately it's theater, but it's kind of a budgeting exercise. Right. It's like, okay, how are we going to divvy up some pot of money across these teams? But there's no actual strategy.

Marty Cagan [00:34:05]:
That's right.

Andrew Skotzko [00:34:07]:
The way I often frame it for people if they're kind of with it is sort of similar to what you were just saying of like, hey, if you want to beat, if you're David and you want to beat Goliath, this is the point of strategy because it's a force multiplier. Right. And you have to be able to focus force and bring it to bear on a point of leverage to overcome a challenge. That's the point. So if you want to do that.

Marty Cagan [00:34:26]:
That'S exactly how I try to frame it. I think your original framing is a good one, too because that's another way of describing the same thing from the other.

Andrew Skotzko [00:34:35]:
Yeah, yeah. We're going to come back to your book in a second, but just while we're on the strategy topic. Funny, on my desk here I happen to have the crux by Richard Rummelt, which you and I are both fans of his work.

Marty Cagan [00:34:46]:
I was just going to mention if you like him, the other book that's really good is called the Art of Action Bunke by. Yes. And that also, I think there's some core truths there about this force multiplier idea. And yes, love to see more people read that stuff and do that.

Andrew Skotzko [00:35:08]:
Yeah, those are two of the seminal influences. I'm working on a big strategy framework right now. I'll send it to you and those are two of the big influences on major pieces of that framework. So hopefully it helps people. But anyways, back to your book. So let's talk a little bit more. I want to zoom in on the process a little bit more. So the thing that I have heard from you consistently and also matches my experience, what I've seen with clients and from everyone I've talked to who I think knows what they're talking about is basically like, if you don't have top leadership bought in and personally driving the change, basically, don't bother.

Andrew Skotzko [00:35:47]:
And so my question is, assuming you do have that, then what? And maybe perhaps more importantly, where does it go sideways? Because I feel like there's so many places where there's pitfalls and landmines all over the place that maybe most people can't see.

Marty Cagan [00:36:00]:
Yeah, well, first of all, we should clarify top leadership because some people will think like chief product officer, but I think you and I are referring here to the CEO or the general manager of a business unit. So very senior leadership as opposed to product leadership. Product leadership is usually one level under that and is responsible, of course, for the product and the technology sides of delivering this stuff. So I do think one of the hard learned lessons is without some level of real support from the top and you're in trouble. And the reason for that is because changing to the product model absolutely starts with product design, engineering. It absolutely does. But it very quickly goes beyond that, goes into finance, it goes into HR, it goes into all the stakeholders, compliance, all that. And so if the CEO is not providing that level of support, then it's not going to happen.

Marty Cagan [00:37:11]:
The part that I think I need to talk a lot more about, honestly, this is something I'm really trying to address more aggressively is a lot of product leaders, they're just immediate to blame the senior leaders. They just put all the blame there. They're just like, they don't know how this works. We can't do our job. And they don't seem to realize on too many of these product leaders don't seem to realize just how much of ability they have to change the organization. They think they need everything teed up by the senior leader. But really most of the time the senior leader is like, I've never done this before. I don't know.

Marty Cagan [00:37:59]:
I will provide the support, but I don't even know what. I don't know. And they are looking for the product leaders to show them what their organization can do. And not enough of them have that sense of agency. They don't realize that they can and need to do this. So, for example, if they don't make sure that they have very strong people in the product teams, it's all going to fall apart. That is on them. It is absolutely on them.

Marty Cagan [00:38:31]:
They have to make sure the people on the product teams are competent, which most of the time they've never done this stuff. So the product manager role is totally new. Even though they may have had people called product managers or product owners, they don't have this. It's a new role with very different definition and very different responsibilities.

Andrew Skotzko [00:38:52]:
You can't just retitle somebody.

Marty Cagan [00:38:55]:
Yeah, that's right. The retitling, the title theater is a real problem. So the first thing they have to make sure they do that. They also have to make sure those teams know how to do what they need to do, how to do product discovery, how to do product delivery. Otherwise they're not going to be able to do what they need to. And then they have to really show the stakeholders that they can be a competent and trustworthy partner. They have to earn the hearts and minds of these stakeholders. And the stakeholders, some of them are open, some of them are very skeptical.

Marty Cagan [00:39:36]:
It's all natural, but they all want to know that that partner is there. And too many of these product leaders are not. Either they're not willing to do it or they just don't know how to do it. So I would say more of the transformations go sideways of this than because of the senior leaders. They're not doing what they need to do. That's really good to hear because I.

Andrew Skotzko [00:40:04]:
Feel like folks, amidst so much change inside of a transformation, it's really easy for people to feel lost, confused, like a diminished sense of agency. And so I think bringing some sense, like kind of bringing the locus of control back home a little bit can be really helpful for a lot of these folks who might feel a little bit out of their depth, even if they are experienced leaders. So that makes a lot of sense to me.

Marty Cagan [00:40:28]:
That's really where usually the first place that the role of product coaches become so important, because very often in these companies, the product leaders want to do the right thing, but they've never done it before. So they need help to learn how to do their job while they're doing that job. And that's where, I mean, obviously the company could just replace them with leaders that have been there, done that. And that is what some companies do, but more often, because even if you do that, it's usually at the top and then it takes you a year or two to build the structure. So what usually happens better, works better is for them to get a product leadership coach that can spend a few months with them to really say, let me show you how you coach your people. Let me show you how we do a product strategy. Let me show you how we do a team topology. And after doing that a few times, the person is able to do their job properly.

Andrew Skotzko [00:41:32]:
Yes.

Marty Cagan [00:41:33]:
So I like product coaches for this. The challenge is now I realize I'm getting a little off track, but the challenge is these very same companies that need the help. If they really knew what to look for in a product coach, they probably wouldn't need a product coach. And so they don't know. And it's a really sensitive one. It's a difficult one. I mean, this is, I think, a problem with agile coaches. Most agile coaches today have never actually built.

Marty Cagan [00:42:06]:
They have never done, say, CICD. I would never hire an agile coach that has not done that. But most of them haven't. So we have this issue just because somebody calls themselves an agile coach, and of course, the certification is nothing short of ridiculous. And so anybody can call themselves a product coach. What I'm trying to do, and you might have noticed this in the book, is show people by example. Like, these are real product coaches. We know them.

Marty Cagan [00:42:40]:
We have no financial ties with any of them, but they're real product coaches. Look at these people. Look at what their experience is. This is what you want to find. There's lots of other ones besides them. But you want people with real experience working at a serious product company to be able to help you with this. It's like if you wanted a golf coach, you want somebody that knows golf and knows the mechanics. Like you wouldn't hire a life coach to be your golf coach.

Marty Cagan [00:43:15]:
Well, it's the same thing.

Andrew Skotzko [00:43:16]:
Yes. That makes total sense. As you were talking about the leadership challenges, I was like, yeah, those are most of the calls I get. I usually get the call from one of those people saying, please help my person raise their game. So I'm obviously unbiased, but I'm fully in support of what you're saying. So I want to ask you one thing, and this circles back a little bit to something we were talking about earlier with a little bit of the theater. Right. And the fact that folks can.

Andrew Skotzko [00:43:45]:
My observation is that folks are almost everybody I meet is well intentioned. Right. They're really trying to do a good job. They usually just don't know what good looks like or just haven't done it before. Never got good mentorship, something like this. And going back to that idea that one of these folks could look at a list, right, and say, oh, yeah, I got a focus product strategy, or we're doing discovery. Right, et cetera. Curious.

Andrew Skotzko [00:44:06]:
In those three parts of the model of essentially discovery, delivery and strategy, let's assume for the moment that they don't have access to someone who can actually coach them on the stuff. And so they have to self assess. Is there an objective criteria or some acid test they could look at in each of those three categories to say, yeah, we're really doing it, or maybe I'm kind of falling into theater.

Marty Cagan [00:44:30]:
I wouldn't frame it as a litmus test like this. However, there are real signs. And of course, in the book, in the chapter, we list those signs that we look for. There's no secrets there. It was all out there. Like, this is really a good sign or this is really a bad sign. Here's what you're looking for, and it's all about this point. It's all about to see, are they just sort of saying it or are they doing it? I don't know.

Marty Cagan [00:44:57]:
My partner Christian likes to say the difference between being agile and doing agile. Right. You can go through the ceremonies, but that doesn't mean you're actually being agile. So we have to look at what's really going on. And, yeah, I think there are lots of. For different things, lots of different tests. One of those clues almost, if you're the cool kid today, you say you do some kind of product strategy. If you're in product, my simple question is, all right, how many of the ideas you're trying do you actually build and how many do you discard? And I just know if they're not discarding at least half, then they're either like the smartest people ever born or they're just not doing it.

Marty Cagan [00:45:49]:
So these are clues. Right? And so if you find out that they've tried out seven ideas this month and they built seven things, then, all right, it's probably not product discovery.

Andrew Skotzko [00:46:02]:
Yeah. And just to clarify that for the listener, when Marty says built seven things, he doesn't mean like seven prototypes. He means actually putting into production, doing full delivery on really putting production engineering resources. Like, I just want to carve out a distinction between prototyping and testing, which is discovery and doing it for real.

Marty Cagan [00:46:21]:
Yes. And so the point of discovery, of course, is to separate the good ideas from the bad as fast as possible. So we know if you're doing discovery on seven things and then building in delivery, all seven things. Then how are you separating the good from the bad? You're not going to know they're good or bad until after you've deployed it in that model. So you're just basically doing like the project model.

Andrew Skotzko [00:46:48]:
I think the phrase I've heard you use a bunch of times is that you're moving from time to market to time to money. Right. It's like, yeah, we're trying to get to value here as fast as freaking possible.

Marty Cagan [00:46:58]:
That's just another way to frame that. Moving to outcomes. Yes, but the reason we do discovery is so that we can accelerate all that by failing fast. And that's why we know if they're not actually removing the bad ideas, it's probably because they're not testing them there.

Andrew Skotzko [00:47:19]:
Yeah, that makes total sense. So I want to talk about a section of the book that I was really surprised and delighted was in there, which was the objections section. Right. And I know you've collected so many of these objections over the years, but I'd love to hear a little more about that for the listener of what are some of the big categories of objections? Where are these things coming from? And I'm also curious to give you three questions at once. Did any of them really surprise you?

Marty Cagan [00:47:48]:
Well, I mean, sort of. By definition, I wasn't too surprised, because I've been collecting these forever, but probably the first time I'd seen some of these were surprising. But I don't even remember at this point. I have been collecting objections forever because those are prime inspirations for articles. And I make the point, some people don't want to change just because they hate change. But most people, they have legitimate objections. Legitimate objections. And that's what this is speaking to.

Marty Cagan [00:48:22]:
And I think it's probably the least glamorous part of the book, a bunch of objections. But I think that any company that's serious about this will run into many objections. And you want to make sure that you need to respect those objections and they deserve a quality answer. So I wanted to do that. That's why that section is in the book. It's also, you know, this. But most people haven't got the book yet. It's a big section because there are objections from the CEO, there's objections from finance, objections from HR, objections from marketing sales.

Marty Cagan [00:49:06]:
Another big one is the PMO.

Andrew Skotzko [00:49:10]:
Yes.

Marty Cagan [00:49:11]:
When you are moving from a project culture to a product, you get a bunch of objections from program managers. And by the way, it's also important to acknowledge there is a very large set of objections that can come from inside the product organization, inside the product teams. You'd think that they would be not the source, but a lot of them have real objections because they've never worked this way before. It's not because they don't want to work this way usually. It's because they never done it. And so they have questions. Yes, all kinds of objections. I think everyone is a legitimate objection.

Marty Cagan [00:49:52]:
Everyone is an objection I've seen multiple times. And in fact, I would argue if the people are sincere and trying and thinking they're going to have these questions just because where else would they have seen an answer to those questions? I mean, it's not like you go to some source for this. I don't know. Companies struggle through it. And so I do think it's important to both acknowledge the objections and to make sure you have good answers to those. Yeah, so that's where that section came from. Some of the feedback during the process was, oh, that's so like, do we really have to talk about all the negative we do? Because those are the things that will. It's kind of like death by 1000 cuts.

Marty Cagan [00:50:42]:
If you don't have good answers to these objections, eventually the company goes like, well, if you don't have answers, we're probably not going to do this.

Andrew Skotzko [00:50:51]:
In related to that, I realize there's an important topic involved in this whole thing we haven't actually explicitly talked about, which is power and the shift of power dynamics within an organization, which seems like, at least I won't say the root cause, but a serious cause of.

Marty Cagan [00:51:05]:
A lot of these issues.

Andrew Skotzko [00:51:06]:
So let's talk about power a little bit and how we should think about it. Because I don't know what your views are here, but I personally am a little bit allergic to the popular phrase over the last 18 months of quote unquote product led because it feels like both a political landmine and also not what we're actually going for. We're not saying we want one function to run everything and everyone just get in line. So anyways, talk to me how you view the power dynamics inside this whole situation.

Marty Cagan [00:51:34]:
Well, we view same as you, some people call it product led, some people call it product driven, but that really gives all the wrong message. We didn't come up with the term product operating model. We got it from companies that use it that we knew and we liked it because it's a conceptual model, it's not a process. It's not like it doesn't talk about who's got power. It's just a different way of running. And we don't usually frame it as power, although it is. We usually frame it as control.

Andrew Skotzko [00:52:12]:
Okay.

Marty Cagan [00:52:13]:
Because that's what the stakeholders, if you say they're giving up power, they'll take it a little personally maybe, but control, they're like, yeah, that's right. I'm accountable to this PNL number. I feel like I need the control. So they often frame it and think of it as control. And what we're trying to say is, yes, no question, this moving to the product model, the control shifts. But it's not like it goes from you to some product leader. It goes to the model where the product teams are there to do what you say to a model where you do it collaboratively. It really is a collaborative model between product and the business.

Marty Cagan [00:53:01]:
And we emphasize over and over. And I always advise this to product coaches. You can never say this too much because it's so right at this point. It's all about coming up with solutions that your customers love but work for the business. That second clause is so important and so many people don't understand that. They don't even think they have to worry about that. That's just naive.

Andrew Skotzko [00:53:26]:
Yeah.

Marty Cagan [00:53:27]:
So if your stakeholders keep hearing that, that makes them feel a lot better about this. It's like, okay, you are saying you care about working with the business. I know that means that we're going to have to work together.

Andrew Skotzko [00:53:43]:
Right.

Marty Cagan [00:53:44]:
And yes, that is right. It's just a different dynamic. So all I knew for sure when we did this book is that I didn't want to make up a new term. I call it the XYZ model or whatever.

Andrew Skotzko [00:54:00]:
Right.

Marty Cagan [00:54:01]:
I wanted to take something that hopefully didn't have the bad connotations.

Andrew Skotzko [00:54:07]:
Right.

Marty Cagan [00:54:07]:
I definitely didn't want it associated with process. And so conceptual models have that virtue. There is no perfect phrase for this, and to be honest, Andrew, you probably know, but for 20 years, I avoided naming talk around it. I'd say, look, all this is really about is moving how to work like the best. That's all. Just work like the best. That's good enough.

Andrew Skotzko [00:54:35]:
Yeah, the best, not the rest.

Marty Cagan [00:54:37]:
When you write a whole book on what that means, you kind of need to name it something that makes a lot of sense.

Andrew Skotzko [00:54:45]:
One thing I was curious about, this came up in a lot of the research I've done over the last few months around this topic was, it seems to me like a lot of things have to come together into this operating model, right. And I think it's kind of what you're speaking to earlier of when you start to change how you work this way and really transform the organization, it has knock on effects across the organization, across every level, every function, like across the board, including processes. Right. So it goes all the way from leadership through strategy, through all the key processes that run the. And then everything has to come together is how I kind of think of it in the tip of the spear, which is the operating model, which actually is how you go out and do things in the world. How do you think about that in terms of when you want to move this way? Processes are going to have to change. Like you just said, it's not a process. Right.

Andrew Skotzko [00:55:35]:
This is not a process model. Fair enough. But I'm wondering about how you think about the changes to processes within the organization that have to change in order to do this.

Marty Cagan [00:55:45]:
Well, I always resist that framing just because the vast majority of processes in a company will be completely untouched. Untouched. So, for example, except for one company, every other company I've ever met, they have processes for travel expense reporting that.

Andrew Skotzko [00:56:06]:
Has nothing to do with this.

Marty Cagan [00:56:09]:
The one company that threw it away was Netflix. But everybody else has processes for travel expense reporting. You think that's bothered? And that's one of a million processes they have around their customer service stuff, around their manufacturing stuff, around their service. Call all these tons. Those are irrelevant, orthogonal. No worries. So I think process is so vague, ambiguous, I don't even know that it's helpful. We can talk about something like, here's an example.

Marty Cagan [00:56:47]:
In the real world today, your legal officer or your compliance officer may have very specific rules prohibiting you as a product team member from talking to customers. Do we need to get those policies to change? Yes. Do we need to change them, though, in ways that are still legal and compliant? Yes, absolutely. Yes. We don't even need to talk about process, but that's actually a very tangible example of what we're talking about. We need ways to get in front of our customers and to tackle the risks in product, but we need to do that in ways that respect the legalities and the constraints. And that's what good companies do. That's what's going on.

Marty Cagan [00:57:39]:
I don't think, as you go and do move to this model. Yeah, lots of things are going to change. For example, how about this? When a customer runs into a serious issue, we could usually respond now within minutes. And in those cases, we will find and fix the problem before the customer even finds it. With the right monitoring and infrastructure in place, obviously lots of different deployment processes, monitoring processes, alert processes.

Andrew Skotzko [00:58:10]:
Right.

Marty Cagan [00:58:11]:
Who cares? Those are all support of this goal. So we kind of have to talk about what kind of process is even interesting because obviously going to lunch together is a process. Who cares? It's irrelevant. So I don't know what kind of process might be interesting. The most common processes we deal with are how developers build, test and deploy. Grum is a process for that. Kanban is a process for that. And there are some far worse processes for that, too.

Andrew Skotzko [00:58:47]:
Indeed there are. Indeed there are. Very good. Well, Marty, I want to go ahead and say thank you so much for your work. You've been at the forefront of our field for so long and you're continuing to push the edge of the field. So thanks for doing that and bringing us all along for the ride. And it's a pleasure to have you here. And just in closing out, is there anything you'd like to leave the audience with and how can folks be useful to you?

Marty Cagan [00:59:11]:
I thought this was a great conversation, Andrew, just like last time. So I don't really have any real ask. I hope people, if they do get the book, I hope they find value in the book, and I hope it helps them. First of all, I hope it helps them realize how much they can do, even as an individual contributor, even if you feel like you're trapped in one of the worst companies on the planet when it comes to product, just how much you can do, and at the minimum, I believe it will improve their career. At a maximum, they could change the course of that company. So I hope people realize they can do so much more than they thought they could. I also hope, because I do think a lot of the people today watching these conversations are very nervous about their jobs. I've been saying for years that the vast majority of the industry does not work the way we've been talking about this past hour.

Marty Cagan [01:00:16]:
And one of the biggest ironies is how much waste there is in those companies. Frankly, I'm surprised it's taken so many companies so long to realize how much waste there is and to sort of do something about that. But of course, I want the people who care about this stuff to make themselves as valuable as they can and least vulnerable as they can. Sometimes, no matter what company you're at, they overhired, they have a big change in their industry. There's nothing you can do. But in many cases, most cases, I believe there's a lot you can do. And so I hope people will read the book and see what they can do to improve their situation and whether that's at their current company or at a future company, they want to be as valuable as they can.

Andrew Skotzko [01:01:10]:
Amen. Well said, Marty. Well, thanks again for doing this. Thanks for the book and appreciate everything you're doing. We'll see you out there.

Marty Cagan [01:01:18]:
Take care, Andrew.