[00:00:00] 

Trisha Price: If you build software or lead people who do, then you're in the right place. This is hard calls, real decisions, real leaders, real outcomes. Hi, I'm Trisha Price, and welcome back to Hard Calls where product leaders come to talk about the business outcomes they're accountable to and the hard calls they have had to make to achieve them.

Today's guest is one of the most influential voices in modern product management. Marty Cagan partner at the Silicon Valley Product Group. Marty has spent decades shaping how the world's best tech companies build product. He started with executive roles at eBay, AOL, and Netscape, and he's continued his work advising product leaders across the globe.

He's the author of three foundational books in the product world. If you haven't read them, you should. The First is Inspired, How to Create Tech Products Customers Love, the second, Empowered Ordinary People, Extraordinary Products. And the third, my personal favorite, and one [00:01:00] we're gonna talk most about today, Transformed Moving to the Product Operating Model.

Through Marty's writing, coaching, and speaking, he has helped redefine the role of product teams moving from feature factory to strategic driver of innovation and growth. His work is read, taught and referenced by product leaders everywhere. Marty, welcome to the show. Thanks very much, Trisha. Thanks for inviting me.

I'm so excited to have you here, and as you know this is the Hard Calls Podcast, and so I like to kick off each one of these sessions to just hear from you. If you look back over your product career, what has one hard call that you've had to make and what made it so challenging? 

Marty Cagan: Well, first of all, you probably people who could do the math.

Man, I've had a very long career, I mean, literally 45 years doing tech products. So a lot of calls and a lot of mistakes for sure. Honestly. Um [00:02:00] I'm guessing what you're really looking for is hard calls that you kind of regret. The hard calls that went well make you look smart. But hard calls that don't go well are humbling for sure.

And honestly, they're the ones that really stick in my head. The other thing I'd probably admit is the first half of my career was as an operator really running product organizations and, the calls for that are a lot harder than the second half of my career, which was is as an advisor and coach where I give my opinion, but really it's whatever the person wants to do and I try to support 'em.

That's much easier. So the calls I do, you could say, well, I make some hard calls on what to call the product operating model in a new book. But really it doesn't matter that much in the world whether or not you get that right. I would, I mean, we all have scars. I have scars that my last real [00:03:00] job was running product at eBay.

And at the time we were actually twice as big as Amazon, so it was a very major property for the internet. And I remember that one of the, and the good news is it was young and it was growing and there was opportunities everywhere and we did a lot of very good things. But there was one big product called, that I remember, that I personally made.

It was a huge mistake and I really learned a very hard lesson. I don't know how much I could spend an hour telling you about how, what made it hard and stuff, but fundamentally, we had just acquired PayPal. And, the hardest part for people on early eBay was just paying for something. They were literally sending checks through the mail.

I mean, a lot of people were born after what I'm describing, so it was a long time ago, but it was, this idea of integrating a real payment solution. There was some crummy ones before, but this was good. [00:04:00] Was something that we were really excited about and it was one of those rare eBay's, a marketplace.

So there's buyers, sellers, and then eBay. It was one of the rare win win-wins. Buyers wanted it. Sellers wanted it. We wanted it. It was just a great win, and we tested the hell out of it because this was a big change to the workflow to list something, a big change to buy something we did. We tested the hell out of it.

We did all the practices that, you try to advocate. Because of other mistakes earlier you learn that are really important to do. And we did it. And I remember, 'cause we got in this, right before we launched, we had a, we all sat down with the CEO and said, are we ready? And I'm like, we're ready. This is gonna be, this is, we're, we're so excited.

The community knows about it. They're excited about it. The people that tried it loved it. Anyway, we launched it. It was a disaster. And it was a disaster. It's one of those things, whenever you launch something big, you're kind of looking at the data because it's normal that [00:05:00] there's a little bit of a dip because it's basically people are learning how it now works and then that's normal, but you expect it to go up again and get better.

And it wasn't. And I'm like, finally, oh my God. I know, I know what happened. We screwed up. I screwed up. and, and this was a lesson that I've got so many scars. I share this with so many companies even today, that it's not enough that people love your product. It's not enough. They also have to be able to digest it.

And what was going on was, even though these buyers and sellers were screaming for this solution, that doesn't mean they were screaming to change how they work. And, I remembered that very early when I met the co-founder of eBay, Pierre Omidyar. He had warned me about this. I don't even know, I actually haven't told this story in probably more than a decade.[00:06:00] 

I'll tell you the story just 'cause it's hilarious, but feel free to edit it out if you go because it's very old. But I thought this boy, I should have listened to him harder on this. He was explaining to me that, 'cause I had only done products for developers before eBay. So I was a platform guy, developer platform, and I love developer tools and eBay's this weird marketplace with all these crazy buyers and lots of crazy sellers.

Just very different personalities. Very fun, but very different. He was trying to explain to me, they're not like developers. They're like, they're very, they view it as their website. They view it as their solution, and and we are just the custodians. 

Trisha Price: Mm-hmm. 

Marty Cagan: And he was telling me right, in the earliest days, he had no idea it was gonna take off.

Like this, but, he just whipped together. He was a front end developer. He whipped together this website that just looked hideous. You can find out on the [00:07:00] way back machine just how hideous eBay used to look. It was really, really ugly. Probably one of the ugliest sites ever. But it worked, right? So it was taking off and, he was surprised because, news.

Crew. Actually, the San Jose Mercury News, for those of you that know, your internet history, they were like the regional newspaper. They said, this is, we'd like to interview you. And, and, and they took a picture of the screen and he was embarrassed because now he sees on a newspaper this hideous screen, so he says, oh my gosh, we just have to fix this.

And like, like they hired their first designer and they just. All he actually did was change the visual design. They literally just changed the color. Uh and because they had this hideous background, yellow background, it was just, you don't do that. Right? And, and anyway, he, all they did was change the color and they had their first online riot.

They literally the the [00:08:00] buyers and sellers made petitions online to get eBay to change it back. And he was like, I, I'm not trying to pick this fight. This this, and so we just said whatever. And they rolled it back. They rolled the whole thing back and he, but he was still very embarrassed. And, the comp, the company kept growing and then a TV station wanted to interview him and he said, well, this is, I just can't go public like this again.

But he said this time he was smarter. This time, what he did is over the next two weeks. Every two days, they rolled out a slightly lighter shade of yellow. Wow. And in two weeks it was gone. There were no yellow and nobody said anything. And he was trying. And I laughed, I thought it was funny. But he was trying to con explain to me that change for a community like this is really, really hard.

And I, I learned what he was [00:09:00] really trying to explain to me when I made that mistake. Yeah, on the payment stuff. But it's true. And Facebook has made this mistake. Twitter made this mistake a lot of people do. It's it's a hard lesson to learn. But anyway, when you do it this long, you acculate lots of lessons.

Of course, learned like this. 

Trisha Price: I mean, Marty, that story is still so true for all of us today. I'm sure. Very true for the companies you advise and help. Change management's hard and if we're in the business of not shipping features and celebrating, but getting outcomes, thinking about how people can consume what we're changing and putting out there is, is a super important part of what we do.

So that's still super relevant. And, and so with that, Marty, one of the things I'm really excited to learn from you about today and talk to you about today is operating models, frameworks, and you and I both know we, we see product leaders, [00:10:00] product teams all across the world, and almost all of them, not all of them, but almost all of them have some sort of an operating model, a cadence, a framework.

But a lot of times it's still falling short in terms of driving the outcomes that they're trying to achieve and accountable to. So, Marty maybe you could just kick us off with why that is. What are most people getting wrong? Because I know you seeing this time and time again was very influential for your most recent book.

Marty Cagan: Yeah. Well, I mean obviously everybody works some way, and, that way, they often will call their framework or their SDLC or their, their operating model. So, but if you look closely at most how most of them work, it's all around projects. It's all around features and projects in particular. It's not around [00:11:00] outcomes.

Now sort of easy to understand why it's not around outcomes 'cause outcomes is hard. Outcomes is super hard. What it's about, and honestly, even when they don't acknowledge this, it's about predictability. They're trying to optimize for predictability, so they wanna predict how much money they're gonna make.

They wanna predict when things are gonna happen. These are, and these are not crazy things to wanna know. 

Trisha Price: when you're running a business those are important things. 

Marty Cagan: Those are, they're running a business and so they're reasonable things to wanna know. the, part that gets so many companies is they don't realize that these are things they can't know at that stage.

So that's a different issue. But they, they set up their whole way of working around this. Though we, we call that the project model. So you fund projects, you staff projects, you build projects, you ship projects. That's waterfall basically is all around that. The whole, the [00:12:00] whole formal lifecycles, software development lifecycle, product lifecycle, stage gate, phase gate.

These are all just names for the same basic thing. You staff a project, you figure out requirements, you design the solution, you build the solution, you test the solution, and finally you ship the solution. Right? 

Then you 

Trisha Price: have a big party, right, Marty? Yeah. Then you have a release 

Marty Cagan: party and you, you kind of feel like you need it by then and, but unfortunately you've sort of given up by then on outcome.

Because you've had to make real trade-offs on what you're gonna do. And so, and of course when the company decided to do it, they only funded it for a certain amount of time. And there's all these, there. The, the consequences of the project model are so well known because we've seen it for 40 years. So it is really well known.

So many people all write an article that talks about it and they're like, how did that's what's going on in our company? Are you listening? No. It's like, this is what so many [00:13:00] companies do. However, if is not all the companies, many companies figured this out many years ago that that, that's actually all about output.

And what matters supposedly is outcomes. And what would we do differently if we're trying to optimize for outcomes? Well, okay, that's a very different thing. Just shipping and not achieving an outcome is an empty victory. And the irony is, the teams that actually ship for outcomes develop for outcomes are much more likely to predict an accurate date than those that are doing projects.

So it's, it's counterintuitive, but anyway, that's, that's the case. And so what we have been. I mean, honestly, Silicon Valley Product Group, I started it almost 25 years ago, and it was just about sharing these techniques I would see in the best companies because I was, lucky enough to work at some really good companies that had worked this way, and yet [00:14:00] then I started visiting.

Because I was told you I was doing tools for developers. Yeah. I started visiting customers. Yeah. Early on I'm like, oh my God, how come you work this way? It's crazy. Where did this come from? And they're like, what do you mean? This is how everybody works in the Midwest and the East and Europe and I'm like

Wow, that does not look good. And you're, you're not happy with the results. You don't seem to even like your jobs and your customers are not happy. Why do you keep doing it this way? And it's like, well, this is how we've always done it. This is what our leaders know. And again, there's a real desire for that predictability.

So what, what the latest book is all about is just sharing the, the techniques that we see used in the best companies. 

Trisha Price: And when people are starting to move from this project model to a product model, what do you think the hardest [00:15:00] hurdles for them to get over? Is it the trust, the the giving up control and empowering their teams?

You know what is it that is like the thing that just catches everybody every time? 

Marty Cagan: A lot of things. So everything you mentioned for sure, but more, so there's a lot of things. In fact, the way I've really started framing it as very much like a product. What does it take for a product to be successful?

Mm-hmm. A lot of things have to be done right For a product to be successful. It's gotta have a good design, it's good experience. Of course, it's gotta be technically feasible. It's gotta provide real value. It's gotta have a lot of things right. And all it takes is really one of those to go significantly wrong and you've got a failed

product just like you'll have a failed transformation. So there are a lot of things you've gotta get right. The hardest things for, I'd say for most of those companies to get right. Probably starting right at the top. So many people want to think of everything we're talking [00:16:00] about as just a tech thing, an IT thing, but it's not, it's a company thing.

Trisha Price: Yeah. 

Marty Cagan: And so because it's a company thing, it impacts finance, sales, marketing, services, legal, fine, compliance, all of these. And so all that means if the CEO is not on board. Most of those people are gonna be, passive aggressive. They'll just wait, they won't do anything or they'll get in the way literally.

So the CEO really has to have, they don't have to be experienced in it, but they do have to understand what's going on and step in and show some leadership at times. Mm-hmm. And so that's a key one. Another key one is, and it's one of those things when I look back over the years, I kind of regret.

Never tackling the problem of the name, title, product manager because the title product manager means so many different things to so many different people. Mostly [00:17:00] because they're describing the project model companies. Or even worse, 'cause there is even worse, when you talk product owners, there's even worse.

Out there. So I always like, I don't wanna fight that battle. I don't care what it's called. Let's just call it a product manager. It's fine. It's just a different job definition. But the job definition is so different for the product manager on an empowered team in the product model than a project team or a feature team that that's one that constantly get wrong.

They get wrong because HR just wants to retitle people. It's so much easier to just retitle people, but it is much harder to upskill them. And these are very different skills. At its essence. A feature team product manager is much more project manager, which is important of course, but it's not this job. 

Trisha Price: Same, it's, it's funny you say that, [00:18:00] Marty, because of my role at Pendo, I get to also go in and talk to product teams all over and, I was with a very large company last year, and they literally took their entire workforce and took everyone who had a title of business analyst and titled them Product Managers. Yeah, that was it. Classic. They didn't train them, they didn't see who had the right backgrounds and skillset sets. They didn't say, here's the difference in the job.

They just said. Business analyst, not even product owner, not even project manager, business analyst to product manager. 

Marty Cagan: Yeah. So I see that it's a classic one. It's a classic one. And that's the, that's the, that's a big problem, obviously. Another big problem is the way they treat engineers. Mm-hmm. So many of them treat 'em as

outsourceable people. Mm-hmm. And they literally are outsourced in a lot of these big companies. And we have to explain to them, no, in the product model, your [00:19:00] engineers are front and center. In fact, they're the, they're the best source of innovation. If you care about outcomes, they need to be the ones coming up with the things that go on the roadmap, not your stakeholders, not your customers.

It's a, again, a very different model, which is sort of what we're really describing now is probably the hardest thing for most of these companies is it's essentially a cultural change. So we are talking about things around culture, about who makes decisions, how do they make decisions, how do they make progress, where do ideas come from, that's different.

And so, I've never been surprised at why it's so hard to transform. Because, I mean, these are big changes. These are not, they're big changes. Changes, but, but the good news is there are companies that manage to do it. 

Trisha Price: Yeah, 

there 

are. And do it well. And you're talking about you, you were talking about the change and a lot of the change you were talking about [00:20:00] is sort of in the ideation and prioritization phase, which is obviously wildly different when you're prioritizing and empowered in support of a goal versus being told to go ship something and now you're breaking the problem down and trying to ship it.

But I equally see the problem in terms of change on the backend. And what I mean on the backend is iterating, launching, constantly tweaking, experimenting, figuring out what's working and not working. And one of the problems I see is they have an idea, companies teams have an idea of the big goal, right?

Like, I want to get revenue in this new product, right? But like, how do I break that down into something manageable and achievable this quarter, [00:21:00] this month, and then prioritize against it is something I just see people sort of get frozen in. 

Marty Cagan: Do you see that, Marty? Yeah. Well, to continue from your last question on all the things that have to be done right, a whole other big question is how do you decide what to work on?

Yeah. And that's, that's usually framed as prioritization when you get down into the teams. But at the higher level, how do you decide what to invest in? How do you decide what you're gonna do? And, most companies in the project model are used to doing that with their stakeholders. And they kind of all sort of make a bunch of proposals for how much money they think things would get and all this stuff.

The spreadsheet, 

Trisha Price: the best Marty, like the weighted spreadsheet, that's like the death. When I see that, I'm like, no. Oh no, you don't have a voting weighted spreadsheet. Yeah, please no. 

Marty Cagan: So that's [00:22:00] what so many do in one form or another. I can't tell you how many I've seen. Now, of course, if you're in the, if you're using the product model.

That's a very different way of working. Your job, of course, is, for the product leaders, is to make sure you're pursuing the most important opportunities and responding to the most serious threats, but more generally, instead of top down, roadmaps. Instead of that, what we're trying to do is in two big things, product vision.

Which is, how are you going? Product vision is not about you, it's about your customers. How is it gonna make you the lives of your customers better? Because if you don't manage to do that, you're not gonna sell anything. You're not gonna, so everything, there are no outcomes. That's right. You derives from the product vision.

And most companies, of course, don't do product vision, so it's only. In my experience, it's really only the companies that are trying to do the product model [00:23:00] that actually do a serious product vision. If a team company tells you, we do a vision for every team, it's like they don't even know what a vision is.

Right. That doesn't even make any sense. So a great product agent, at least they probably have a feature roadmap for each one of their teams. Absolutely. They do. Right? So when they do a real product vision, that's a, for our organization, maybe even for our entire company, this is what we're trying to do.

It's gonna take somewhere between five, 10 years to do this product vision, but that tells us how we're gonna make our customers lives better. That's the first part, the product leaders have to do. The second part then is you can't just go away for five years and do this. I wish. We wish we could, but we can't.

We have to actually pay the bills along the way, and that's the product strategy. The product strategy says, okay, we've got probably only order of five to seven years, it's gonna take us to make this vision a reality. We've got [00:24:00] 20 quarters between now and then. Now we've gotta figure out what problems do we solve each quarter.

Mm-hmm. And what we're trying to do there, like I said, is pay the bills and get us closer to the vision. The product leaders need to prioritize those critical problems to solve this quarter. That is prioritization. Once they've done that, now they have a set of problems to solve and a set of teams that are equipped to solve them, and that's what they do.

They assign the problems to solve to the product teams. They discover a solution worth building and deliver that solution. It's not complicated or anything, but it's very different. The product model from how, the spreadsheets we were talking about, it's very different. And most importantly, it requires product leaders that are skilled in vision and strategy.

This is referred to as the strategic context, like Netflix likes to say, lead with context, not with control. Because [00:25:00] command and control down, this 

Trisha Price: is truly the opposite of command and control and requires a level of trust with your team that most people are pretty uncomfortable with. Yeah. 

Marty Cagan: think you talk about that.

Yeah. Yeah, we do. Because that's really, if you had to pick a single theme undercurrent for the whole successful transformation is probably trust. Because, and I don't mean trust, like somebody gets a blank check. No. It does mean that there's, instead of the leaders making all the decisions, even the ones that are really not in a good position to make, like enabling technology and the what this customer needs right here.

They are making strategic decisions about the most important problems to solve, but then the teams are making the decisions on the best way to solve those problems. 

Trisha Price: Yeah. 

Marty Cagan: And that though is still a, significant degree of trust. And [00:26:00] one of the mistakes that a lot of companies make when they try to transform is that they think somehow a CEO of a billion or very, large company is just gonna

Give them that trust works. It doesn't work that way. And it, in fairness, it shouldn't work that way. Shouldn't I agree? What if that company just renamed all their business analysts to product managers, they're gonna fail. Any CEO that just trust them is, is getting what they deserve, right? Yeah. So, no, we have to earn that trust.

And so the way we often frame a transformation is it's all about winning the hearts and minds of the leaders of the company and the way we do that. Is safe, small, low cost, low risk experiments, which it's really using the product model to move to the product model. Mm-hmm. In other words, don't make a big project to move to the product model where you have, you plan out a year of all this [00:27:00] training and all this nonsense, instead

we pick a pilot team. It's basically like an MVP Yeah. Of what this is gonna look like, and that pilot team is meant to show your organization and your leaders what good can look like.

Trisha Price: You pick an outcome for them. Yes. And then you start doing modern product discovery. Yes. Then you show them 

Marty Cagan: experimenting. Yeah. Now once they see it works, especially a couple times, it's a different situation. Now for, lots of more teams want to move. It's that whole technology adoption curve. We're working through that and the company starts to feel like we should apply this to different areas.

This is a good thing, but they know what it is. And by the way, they also, at that point, they know you can't just retitle a business analyst because they seem what good looks like. Yeah. [00:28:00] So that's why it's so important to do these small, low cost, low risk pilot, show the company what success looks like. You are earning trust each time you do that.

Trisha Price: So Marty, it sounds like, just the way we were talking about, you can't set a vision and wait five years to deliver when you're working with these companies that are moving to the product operating model. They can't wait five years to show progress and deliver against that model either. So tell me like, how, how long does it take for these companies to transform?

How long does it take for them to quickly start seeing wins and, and start building moment 

Marty Cagan: Good. Well, there's two parts to that. Two answers to that . The first one is, how long does it take an entire business unit to change, for example. And the honest answer to that is typically one to two years for a business unit, and which means it's one to three years or [00:29:00] so for a whole big enterprise with multiple business units.

However, the real question is how long does it take to see results? Because for the trust point, that's the real question. And that's usually a quarter, maybe two, because that's why what we do is if you try to change a whole company, like I said, it's gonna be years. Nobody's gonna give you that blank check.

If you try to say, let's pick one product team in this business unit, that you've said is very important, let's give them a problem to solve that you believe you couldn't have solved this before, but is something that really is meaningful. And let's set them up the way we, best companies have sort of shown that you need.

In other words where you don't have these competencies, you're gonna get these competencies, you're gonna coach these people, you're gonna show them how good team works, and then let's run that for a, a few weeks, few months. Yeah. 

Trisha Price: [00:30:00] When, you talk about measures of success or outcomes, one thing I see people get tripped up on, on moving to this like, Hey, let's just try something and experiment is

what's the measure? Is it revenue? And if they're in a sales led company or a company, even with a sales, large sales organization. How can I be accountable to revenue? because I'm not the one selling the product. So maybe give us a little bit of your opinion on is revenue the right metric? Does it depend on the company?

And if it's not revenue, what are other good outcomes that product teams can begin to set as their north star and experiment to achieve? 

Marty Cagan: It's kind of a tricky one because, the higher order point is that it's not always revenue, that that is the right thing, but it is a business result. That's [00:31:00] the higher order point a business result. I'll give you some real examples in a minute so this is not ambiguous. However, sometimes it is revenue. Yeah. And, and that, and sometimes it should be revenue. I'll give you an example of that in a minute too, where it's like that is the business. So, that's the result everybody cares about.

So whenever you 'cause that same objection, you hear that all the time, it's like, well, we don't control. First of all, nobody controls everything except the CEO, right? Right. Nobody controls everything. So if you, unless you're willing to just. Push all the decisions to the CEO.. Yeah. You're gonna have I say the same.

Trisha Price: How do you think the revenue team feels? Yeah. When they get a crappy product and they still have to make their quota. 

Marty Cagan: Well, well I explained because a lot of these product teams don't even know that salespeople are commission based and they are like, they're completely dependent on their paycheck goes whether that product is any good.

Yeah. It's like how would you like to sign up for a quota when you can't even control the product? Right. [00:32:00] So. And I was taught, I mean, this is one of the very first things I was taught, and this is why management by Objectives OKRs, are so powerful, is I was taught, look, a lot of times revenue is the issue and, the biggest driver on that is the product.

So if the product is not selling, don't you think we need the product manager to get their ass out of the building and go sit with sales and figure out why they can't sell? I mean, like that's what I was literally, I was, it was more colorful language than that. That was explained to me. But I was like, and I'm like, you can't say it's not, you don't control the sales people.

You don't control finance. You don't control marketing, but you control the biggest single factor of the product. And the whole idea of a cross-functional team is we should go figure out what it takes. Who else is gonna do that? So, so don't run. I tell people don't run from revenue as a key result if that's the right [00:33:00] result.

Just because you don't control salespeople, that's like a very lame excuse. and by the way, I've made so many friends and sales because they're, they love nothing more than a product person that understands. Yeah. Yes, for sure. And they also know there's nothing us product team can do more important than give them happy customers.

It's all about happy referenceable customers. So this is not a bad thing. Now that said, one of the product coaches that we work with just published an article, and I was particularly interested in this one because it was a company that we did not do a transformation engagement with. So most of the successes I can point to are the ones my partners did transformation engagements with, because that's why they're my partners.

They're the best in the world at this. However, the idea is that why can't you just read a book, like Transformed, and maybe get the help of a product coach in and do [00:34:00] the same kind of success. The product coach is Gabby Bufrem. You may have heard her name. Yeah. Oh yeah. A terrific coach. I recommended Gabby to this company because she was one of the very few coaches coaches I knew that speaks Spanish and she's in Mexico.

And anyway, so she shows up at this company in Mexico, it's like, 40,000 employee company, some travel services company, and same thing, they had tried to transform for years. It was a disaster. They finally, it's like she's, she's like, you have to demonstrate that this works. Let's pick a product team and let's show a real result.

They picked a pilot team and in the first quarter they showed a 40% increase in conversion rate for their bookings. Like, and now for those that don't know, that's basically revenue. That is everything. That is revenue comes from that. Yes. And that's the kind of thing that, yeah. That's what the business needed to see.

The power center in that company was the head of sales. No surprise. It's right. [00:35:00] Yep. That's what they sell bookings at a resorts. So, and it wasn't until he saw that this really worked, that anything really changed. So that, and they did that in a couple months. Yeah. So so's amazing. So that's what we do.

That's, and that's a real result. Now did her team, did the product team have control over sales? No. But did they go out to the resorts and actually test? Yes. That's what they did. 

Trisha Price: Yeah. That's amazing. That's a great story and super helpful. 'cause I hear that a lot from my friends in product, from customers that I talk to.

It's just, I'm not in control of revenue. I'm like, well, you kind of are. If you build a great product. Marty, earlier when you were talking about the transformation from project to product, you talked about needing at least CEO support because it is more than just a product and an engineering way of thinking.

This is [00:36:00] something personally I call whole product, which is instead of thinking about shipping product as engineering and product. It's, does my sales team know how to sell? It is the skew in my CPQ and, moving to this whole product mentality. And, and for me, like I remember my early days of Pendo and I'm, I know we all have this bad story somewhere.

We've worked. I came in. And I looked in Jira and it said something was shipped and I had seen release notes about it and I went into the product, 'cause I use our product all the time myself. And when I went in I couldn't find the feature to play with it and I, oh well that's because it's fine to flag and we've only rolled it out to so and so because we haven't actually taught sales and support, doesn't know how to support that feature yet.

So. It's not done. And I'm like, well, then it's not done. And, but then I went to [00:37:00] engineering and they were like, no, it's done. Look in Jira, it's done. how much of that. Is a part of this transformation in your coaching and move to outcomes for you? 

Marty Cagan: Well, partly we just need there, there's the model, which is really a set of principles, and then there's people executing.

Yeah. And knowing how to do their job, you're of course class talking, classic product marketing. Right. so, and, and in a world of continuous deployment, it's normal if things are tested behind feature flags. Sure. And we make sure that's all good rigor. But like you said, that wasn't done. Then maybe there was a product marketing person that said, well, it's not done because it's not ready.

We're on week two of a three week rollout, or whatever they might have had. But if there's no answer to that question, then it's just hanging. Right. Yeah. And, and this is a, a good question because that's really execution. There is not [00:38:00] rocket science here. I mean, this normally happens every single day. So then there's a question, so who is responsible for this consistent, reliable execution?

There are two ways companies address this. One of 'em I think is the beginning of the end, and the other is what good companies do. The first is they say, well, oh, we need a formal process. So we need a release process. And so clearly the product marketing person didn't follow the release process and if they would've only, checked their whatever check 

Trisha Price: box.

Yeah. On template four A in the file, 

Marty Cagan: Then of course the product marketing person said that this is a different kind of thing. The template's not for that, blah, blah, blah. And, and so processes. I, unfortunately, it's true that processes in big companies, especially used as a substitute for thinking, because what you did is just common sense, right?

You came in and said, where [00:39:00] is this thing I, I am supposed to be able to play with it. It's not here. What's going on? All right. The real, the second approach is how do you ins, how do you ensure consistent execution? And this comes from constant weekly coaching of your people. So, for example, in that scenario, and I've been in exactly your scenario there, I mean, that's not that unusual.

Everyone, 

Trisha Price: everyone has at 

Marty Cagan: Who is in this case, who's the product marketing person? I probably would've said, no, let me talk to the product manager first. And I would've said, all right, well, do you consider this done? Maybe they say yes, but I said, but I can't see it, so let's agree it's not done right.

So then the question is, all right, so, so why not, let's, let's figure this out. And then we may realize either the product manager didn't, do something they should have, or product marketing shouldn't have. But the point is, somebody needs some coaching here. And that's what we're doing one-on-one coaching.

We're helping people get better [00:40:00] at their job. And what's special I think about product is that, it's so tempting to write up something as a process, but everything we build is different. The risks are different, the scenarios different. The data is different, and this is only becoming more true when you build a feature on a foundation model.

So this is, even more of the case. So the point is what we wanna do is help people get better at their job. And there's always areas people can get better and better, and then they of course become the ones coaching other people on how to be better at their job. So the real key to scalability that I believe in was taught and is, is coaching.

Trisha Price: I love that. Earlier you mentioned, and I'm, I'm curious for, for my own purpose too, that product managers are not project managers, but project managers are still necessary. Where do you think [00:41:00] that fits in, like when you talk about good execution? If you have technically, if you have all the right accountable people who have the right coaching and are communicating regularly.

Do you need a project manager? But in reality, most of these organizations that you and I are talking about are fairly complex and large, and it's not that simple. And they would spend their days chasing things if someone wasn't there to help them. So tell me your philosophy on that. 

Marty Cagan: Yeah, and this is pretty common, what I'm about to say in so many companies is there is a crossover point.

At most startups honestly don't need project managers. They don't if, if you've got less than a handful of teams, there are so few interdependencies, and the easiest way to see this is impediments and just dependencies. But at a certain point it's usually around a half a dozen product teams, the number of dependencies, the number of impediments becomes such [00:42:00] that could the engineering manager do it?

Could the product manager do it? Of course. But is that their best use of their time? And are they able, because one model is - some companies say, well, we don't wanna hire project managers 'cause Agile doesn't like them. So what we're gonna do is we're gonna, just make our product managers work 60 hours a week.

So that's one way, but I, that's okay. I don't actually think, 'cause what happens even to those project managers that are willing to work that long is then they're forced to choose between urgent and important every day. And they choose, they can't help but choose urgent most of the time. And that's project management.

And then they don't do the product management. So normally I am for anything but a small startup. I'm a big advocate for project managers. Now there are program manager type project managers, product project managers and delivery managers. They're all project managers of a flavor. We like the kind that are more service based than the kind that are top down program [00:43:00] control types. But

Every great product model company I know has project managers. It's nothing wrong with that. The key is they're not the product manager. 

Trisha Price: Yeah, yeah. And the key is they're not just checking check boxes because there's a process to say, right. They deeply understand and are aligned in the outcome you're trying to drive, and they're a part of the team.

Marty Cagan: Yeah, 

Trisha Price: pretty critical. Well, Marty, I have one final question for you, before we finish up today, and just coming back to hard calls, we've talked about, making hard decisions and prioritization and empowering your teams. And we've talked about driving towards an outcome. But for you, when you're coaching and looking at some of these great product teams and the best product teams around,

How do you think about that fine line between gut instincts, taste, [00:44:00] and true data-driven decisions that need to be made to support hard calls? 

Marty Cagan: Yeah, no, it's actually a great topic, which is so I don't really even believe in the whole concept of gut decisions. I think that's just a phrase we use to represent

experience and, and that we, the term a number of people use, Shreyas Doshi is the one who finally kind of convinced me to adopt the term product sense. The reason I didn't use it originally was because it sounded a lot like something you're born with. But you're not born with it. You, you learn it, you develop it.

So we had talked about coaching a minute ago. The main goal of coaching is to develop good product sense in your product people, good product sense. They understand the customers, they understand the data, they understand the business, they understand the constraints, they understand the industry. This is product sense.

This is what helps you [00:45:00] make good decisions. Now, even when you have great product sense, sometimes you're gonna want enough data that you know this is right. Yeah, sometimes we even want proof. Sometimes we just want evidence, but you have enough product sense to know what you need for each of those decisions.

Some decisions are minor. You can reverse. You can correct a mistake in a few hours. With a hot fix. Yeah. In other decisions, they're like, oh my God, we're gonna be sued. Right. Or kids could be harmed or the environment could be harmed. So really bad consequence. So those are things you're not gonna take lightly.

Mm-hmm. So this is the kind of stuff we coach them on, and this is really product sense. Yeah. And I explain. For a lot of the coaching I do. That's what I'm doing. I'm, I'm kind of helping them understand what is the right level of rigor and analysis for this decision. They need to make the decision, but they need to make sure they've got the right input.

They also need to understand some of those stakeholders have a vote. [00:46:00] Some of them just have opinions, right? Some of them, it's not a democracy. They can say no, and you can't ship anything. So you need to understand the difference and you need to make sure that you understand their constraints and their concerns so that we product is solving for the customer and solving for the business.

So this is the kind of thing we're developing in people. And when you meet a great product person they typically have great product sets which they have earned. Yeah. And that's, it's not 

Trisha Price: because they're just smart. I mean, they might be, and it's not because they were born that way. It's, it's the part you kicked off today's episode with, which is learning from the mistakes.

When we made a hard call that didn't work well, that backfired. It's learning from the wins, it's watching other people who have coached us and invested in us. It is something that we just earn over time. and I think for some people it comes more naturally than others. And it [00:47:00] also probably depends where we've had the good fortune.

Of being able to spend time in, were we empowered and were we able to learn at the micro level before we were forced to make the macro decisions too? 

Marty Cagan: Yeah. Such a big, like I know, I'm so grateful every day I started as a product with somebody who was coaching me and he told me his job was within three months to get me to competence.

And that was a lot of work, but it was doable. I mean, if somebody's there to guide you. It's amazing how fast you can get to where you need to be. So, you've gotta put in the work, you've gotta talk to customers, you gotta spend time with the data. But this is what product people do. It's absolutely doable.

What I think is really interesting going forward is, that's kind of what's left with product management. With gen AI and the tools, the, those other things are, 

Trisha Price: the busy [00:48:00] work is gone. 

Marty Cagan: Yeah. 

Trisha Price: Now you've gotta have product sense and make decisions and be accountable to outcomes. 

Marty Cagan: That's right. 

Trisha Price: Now you gotta spend time with customers, right?

That's right. It's exciting. It's an exciting time. I think personally, it's the best time ever to become a product manager if you're working in the right organization because a lot of the more operational aspects. Are gonna be automated or already automated for us, and now we can spend our time thinking and driving outcomes.

Exactly. Well Marty, thank you so much for joining us today. I know our listeners appreciate your advice. A reminder for everybody if you like what you heard from Marty, but wanna learn a lot more. Marty has three great books out there, that you can read and learn and get a lot more detail. Or you can obviously engage with, Silicon Valley Product Group as well.

So thank you, Marty. Well, thanks for inviting me, Trisha. I enjoyed the conversation. Me too. Thank you for listening [00:49:00] to Hard Calls, the product podcast, where we share best practices and all the things you need to succeed. If you enjoyed the show today, share with your friends and come back for more.