Marty Cagan

Episode 17
Brave UX

Empowering Your Product Teams

In this episode of Brave UX, Marty Cagan, the legendary product management coach, thinker and author, shares the story of his career and his thoughts on what it takes to build great products.

Highlights include:

Why is discovery often the poor cousin of delivery?
How do great tech companies think about product management?
What methods are most effective for reducing value risk?
How do you know if someone is an asshole or if they just think differently?
What’s the difference between an empowered product team and one that's not?

April 7, 202101:14:34

Listen on:

Who is Marty Cagan?

Marty is one of - if not the - most influential people in product management. He is the author of two incredibly successful books - Inspired and Empowered - both of which are essential reading for people in product.

Before founding the Silicon Valley Product Group in 2002, Marty held senior leadership roles at HP, Netscape and eBay, where he worked closely with some of the most well-known names in technology, including Ben Horowitz and Mark Andreessen.

Transcript

Brendan Jarvis:
Hello, and welcome to another episode of Brave UX. I'm Brendan Jarvis, Managing Founder of The Space InBetween, and it's my job to help you to put the pieces of the product puzzle together. I do that by unpacking the stories, learnings, and expert advice of world class UX design and product management professionals. My guest today is Marty Cagan, described as a legend by some guru by others. Marty is one of the, if not the most influential people in product management today. He's the author of two incredibly successful books on the field, Inspired: How to Create Tech Products that Customers Love, which is now in its second edition, and recently Empowered: Ordinary People, Extraordinary Products, which was released in December of last year. Both books are essential reading for anyone working in product as they openly share the lessons and best practices from the world's greatest product companies.
Before founding the Silicon Valley Product Group in 2002, Marty held senior leadership roles at HP, Netscape and eBay, where he worked closely with some of the most well known names in technology at the Silicon Valley Product Group. Marty and his team consult with and coach product people around the world helping them to develop the skills and practices needed to create innovative experiences that customers love when he's not inspiring product people. With his insights, Marty can be found recharging his batteries in the Colorado Mountains, but today it's my pleasure to be speaking with him on Brave UX. Marty, welcome to the show.
Marty Cagan:
Oh, thanks very much Brendan. Thanks for inviting me.
Brendan Jarvis:
It's great to have you here. And this was a thoroughly enjoyable conversation to research for, and as I mentioned your introduction, you have a house in the Colorado Mountains, and how often does that get used?
Marty Cagan:
We came here at the Pandemic and haven't left, so I was just vaccinated, fortunately, so I can see the light at the end of the tunnel, but I have spent the last year here, which turned out to be good. There's it's naturally isolated in the middle of nowhere and plenty of time to write. In fact my new book came out three months before it was scheduled to [laugh] because I had so much time to write. All my trips were canceled.
Brendan Jarvis:
Is the house above ground or is it one of these sort of underground bunkers that we hear about in New Zealand that No, no. That you guys love to build?
Marty Cagan:
No, no [laugh], no. There's just cabin in the mountains kind of thing.
Brendan Jarvis:
Sounds ideal. Great place to sort wait out the pandemic and awesome to hear that you've been vaccinated. Thinking about what people describe you, as I mentioned in your introduction as well, that you, you're often referred to as a guru. How does it feel to be called a guru
Marty Cagan:
[laugh]? I always laugh, but the truth is I am known more for product management, but my interest is in great product teams, and it always has been from my first days as an engineer I love great product teams, but the truth is there are many people I think that have great things to write about engineers and about design, but very few, in my opinion, that were useful about product management. So I focus a lot on that on my writing only because I feel like that's the weakest link, but it's not really because I have this special attachment to that. My attachment or my interest is really in teams. I've literally never seen a good product come from a product manager or even just a great designer, a great engineer. It always comes from a great team. So to me that's the magic and that is what I try to get people to focus on when I work with them. It's like, look, this, you might have individuals that are skilled, but they're not coming together into a team and doing something amazing.
Brendan Jarvis:
And so that weakest link that you decided to focus on in terms of product management, what is it about product management that had made it the weakest link and why have you chosen to address that?
Marty Cagan:
Oh, that's really a better conversation over a pint. I mean, it's just one of those crazy there's a lot of different theories. I mean, fundamentally there's a lot of confusion about the role of product management, and I believe that's because there are very different kinds of ways to set up product teams. There's really many, but I focus on in the world, there's three primary ways I refer to those three ways is delivery teams, feature teams and empowered product teams. But one way or another, there are different ways of doing it. And in those different teams, the product designers and engineers essentially are still designing and coding. But product management is very different in those different models. And in a feature team and a delivery team, it's much more of a project manager than what we in sort of Silicon Valley would call product manager. But in an empowered product team, yeah, it's a big job. [affirmative],
The problem is we are all, no matter where you are in the world, they're generally called the same thing. But the way the role is really worked out, played out in that company can be dramatically different. So I think that's the primary source of noise. The other big source of confusion, which was unintentional, but it's been very damaging, is when the world moved to Agile over the last 10, 20 years as, I mean it's been 20 years since, or first teams I saw moved to Agile, but when they moved there, they realized they had this role called a product owner. And of course most organizations they didn't have, most organizations are it just they have developers and that's pretty much it. They didn't really have designers and they didn't have product managers, so they needed this role called product owner. And then a lot of companies adopted Agile of course, and they said, well, we need these product owners who's gonna do that?
And they looked around, they'd find business analysts, they'd find project managers, they'd find information architects, all these sort of different roles. And they'd say, well, you be the product manager. And they'd say, well, I don't have any training. But then the Agile people say, oh, we have training. It's called the certified Scrum product on our course [laugh]. And of course it does. I do recommend that course for the record, if you're on an agile team and you don't know the rituals. But the problem that happened is that people went to that training and they thought that made them a product manager. And so we have had more bad product managers in the last 20 years than any time I can remember proportionally. And I think it's because of that. It's not intentional, but it's real. And it has caused a lot of CEOs that have worked in good product companies before to be to call me and just say, what is going on? These people are not like, well, I'm used to, and of course it's not the people's fault, it's because they haven't been trained, they haven't been developed, they haven't been coached, so they don't even, most of them have never even seen product done well. They have no clue.
Brendan Jarvis:
I mean, let's talk about that role of coaching and what great product product management looks like. And let's wind back the clock a little bit to when you were working at hp, you were there for nearly 10 years. What was that experience? What did great product look like at hp? What did you see?
Marty Cagan:
We have to wind the clock back more than a little for that, but [laugh], yes and I was a great experience actually. I joined HP Labs right outta college, and I was trained in computer science and I was really in the first wave of developers. This is when, this was before the internet, but this is when personal computers were really taking off. And I had great offers from mean the major players of the day, the Microsoft's, the Apple's. But my professor had recommended HP because they had this reputation for coaching and developing great people. And they also had the reputation, kind of the same, similar reputation that Google has today. They were known as the most consistently innovative company. And so that sounded awesome. I joined there as an engineer. You go through their engineering management training program. It's kind of called the HP way. It was a great place to learn how to be a developer, an engineer and lots of great products.
My products were always products for other developers. So same thing, I've always focused on that market, if you will. But after several years of engineering and then engineering management, I wanted to learn product and I wanted to learn design. I knew those were important, but I just could observe them. I never really, it's different when you try to do it. So the nice thing about that culture, in fact, I don't realize how lucky I was until I left hp, but every day during those 10 years, I had at least one manager assigned to coach me to get better at my job. And at times I had two because I was in an engineering organization, but I wanted to learn product and then I wanted to learn design. I had people who would agreed to coach me in those skills. And of course, I've met people to, I meet people all the time that have never had anybody try to coach them through.
They might have been working 10 years already, [affirmative], it's all been throw into the pool and learn to swim kind of thing. But that's not, I think, right, and it's not how most people that are good have learned. Most people I know that I really admire what they've done. They also benefited like I did from somebody who spent the time and effort to actually critique and develop them. And that's what I learned there. And yeah, I was lucky it was a good place to be for a first job. I mean, I think Google's a lot. I tell people that too. It's a good place for a first job.
Brendan Jarvis:
And the role of coach is something that you find apparent in some of the world's best product companies as well. And I believe you've written about a character in particular that was big in the Valley Bill bill
Marty Cagan:
Campbell.
Brendan Jarvis:
Yeah, bill Campbell, you've spoken about how important the role of coaching was and the advice that he gave to the founders of those companies. So when these CEOs ring you and go, oh my God, these product managers are just not what I'm used to, they're not they're not delivering what we need. What do you ask them? How do you figure out what their core problem is?
Marty Cagan:
Well, it depends on the ceo. A lot of 'em, they know what the core problem is. I mean, they know where the bar is. Their problem is the organization they've got is not doing that. Other ones they're actually the root cause of the issue. The reason they have this problem is because the company had been set up around a very different model. And often I'll ask those people, why don't you trust your teams? And it's because they don't feel like they have the skills. And I'm like, well, who hired them? You hired them [laugh], so we need to fix that.
So it depends on the ceo and where they are in that journey. I mean, I don't see a fair representative cross section. I generally see the CEOs that already know they need to get better. They are either because some company like Amazon has decided to come after them or because maybe it's because they see some of these companies that get these amazing valuations and they realize there's something to the way they work. So it's either the, it's usually even either the greed motive, profit motive or the fear motive. But one of those two is usually what motivates them to call. And of course, if the CEO calls and they know things need to get better, then that's one conversation. If the CEO has to be forced to the table then it's often a different conversation.
Brendan Jarvis:
So you spoke before about empowered product teams. What is an empowered product team? How is that different to those feature teams?
Marty Cagan:
Well, there's a number of ways it shows, and it's a little tricky because from the outside they really look very similar. They're both squads in Spotify language, they both have somebody with a title like product manager. They have somebody that's doing some kind of design and they have some set of between two and 10 engineers. So from the outside they kind of look alike. But from the inside they're, it's easy to see the differences. Feature teams are basically given roadmaps of features and projects to build. And their job then is they've already been given a solution. What somebody thinks is a solution, they're not even told a lot of times what the underlying problem is. They're just told, build this feature, we need this feature. Somebody says it's either like a salesperson thinks it or marketing or a stakeholder of some sort, but whatever, build the feature.
So for them, build the feature means do a little bit of design to work it out and then put it on the backlog, do some sprint planning, go ahead and build the thing, qa, test the thing, deploy the thing. It's all about output. So they can't be held accountable to the results. And they're basically building what other people think are the right solution. Now, it's not about smart or not, it's just realistically the numbers are not good. The percentage of things in that model that actually succeed is usually 20 to 30%. So in contrast, on an empowered product team, instead of being given a lift of features to build where each feature may hopefully address some underlying problem, the team is actually given the problem to solve. So you take a step back, they're given the problem to solve. It might be a customer problem, it might be a business problem, sometimes it's both, but they're given that problem to solve.
And then what it means to be empowered is they are given the ability then to figure out the best solution to that problem. So they will build features too, but if that feature doesn't work, they don't talk about, well, we ship the feature, it's not our fault. They try other approaches, they try other features, or they try redesigning those, or they try eliminating features to find whatever works. And the difference is because they're given a problem to solve, they can be held accountable to the results. So fundamentally, it's a different purpose. They are there now to serve customers in ways that work for the business instead of just building whatever the business wants. It also has pretty big implications on the people on the team, because now their job is not just to code, their job is to first solve and that is discovery. So coming up with a solution that's valuable, usable, feasible, viable, that's kind of how I describe discovery.
And then of course they have to build a quality implementation of that and ship it. So that's a much broader job. And by the way, it has, it's a very different job for the product manager because on a feature team, really that's project management. You're herding the cats, getting it designed and built in a empowered product team. The product manager is the one responsible for whether it's valuable and viable. The designer is responsible for usable, and the engineers responsible for feasible, but the viable and value is hard [laugh]. This is why product managers are in such demand, real product managers, because that's hard. It's also why it's a proving ground for future startup CEOs because it's not an accident if you start your company, if you start a tech company as the founder that is the head of product, you are responsible for value and viability, [laugh]. And so it really is practice for starting a company.
Brendan Jarvis:
And if you wanna eat, you're gonna focus on getting those two things
Marty Cagan:
You, otherwise you just got a whole lot of stuff that nobody uses. Right.
Brendan Jarvis:
[affirmative], Marty, it sounds to me like what you're describing is treating people like competent and capable adults. How much of great product as in the outcome of all the effort that people are putting into creating the product depends on the culture that sits around the product team, the wider organization's culture?
Marty Cagan:
Yeah, I mean it is very cultural what we're talking about. When you actually are willing as a leader to delegate to a team, cross functional team of professionals, right? Engineers, designers and product manager. I'm not talking about people off the street, people who have built these skill sets. If you can delegate to them and say, all right, here's the problem to solve, here's how we measure success, you figure it out. That's a big statement of trust and also a confidence that you're saying I, I'm enough as a leader that I don't need the glory. I don't need to be like, let's let the team show what they can do. That is cultural. Now, many of the best companies, that is their culture. I mean, if you look at Netflix, talk to Netflix like all about that, they wanna push decisions down to the teams. They believe they're we better decisions and they believe they'll take ownership from those decisions.
Same with Amazon, that mantra, we want people to think like owners, not employees. So these are cultural statements. And so you're absolutely right, but it's a specific culture. I used to use the term culture more to describe this, but I think the thing that's been pointed out to me, and so I've kind of backed off describing this as culture, is that you can have great product companies. Like Apple has a very different culture than Amazon, which has a very different culture than Netflix. But all of three of those companies, we can add Google into the mix, has a very different culture. Also four different companies with four very different cultures. But they all do this [laugh], they all believe that it's all about the talent of the people. There's a great Steve Jobs that captures so much of this, which is we don't hire all these smart engineers to tell 'em what to build. We hire them to show us what's possible and you know, talk to any of these good companies. That's what they believe. They're not just there to implement the whims of some vice president of what ever.
Brendan Jarvis:
So you talked about it's not necessarily culture, it sounds more fundamental. And when you talk about beliefs, I mean that's obviously something that sits underneath the culture, enables the culture to develop in different ways. But it's more fundamental what you're touching on there. If you're in an organization that doesn't have that belief that we are hiring smart people and they're going to achieve the outcomes for us without us having to tell them exactly what to do. Can you ever hope to create great products?
Marty Cagan:
Well, there's sort of two questions there. One is, can that organization create great products? I don't wanna lie, I have seen it work in cases if that founder or leader or CEO is good enough at this stuff. The hard part is more scaling it. So it works often when the company's smaller, but then it falls apart as that CEO is not there in the room where it happens with every one of these teams. And I often meet these very frustrated CEOs because it's not working. It used to [laugh] when they could be in the room. So I don't wanna say it's impossible, but I do think it's a lot harder and it's very difficult to scale. So yeah, that's going on essentially with an empowered product team, you are making a bet on your people, an investment on your people. So yeah, that's sort based on that belief that if you hire competent people, if you coach them, you can have consistently good results.
Brendan Jarvis:
And you mentioned Amazon, Netflix, Google, apple. You've worked with these companies and observed how they work. How do they think about things like the short term versus the long term and trade offs when they're making product decisions?
Marty Cagan:
Well, there's another good area because it's no secret how many companies, especially American companies have such a short term view of the world. I always cracks me up when I see these companies that have these monster roadmaps of all these things they want to do in a quarter in a year. And I'm like, that is not how product works [laugh]. And for example, at Amazon they typically use a seven year horizon when they look at investing in a new area and they know as do venture capitalists, they know that product is not a project. These are things that we work on and we constantly improve to get help something really reach its potential. So the idea of good product companies, one of the key things is their product vision, which is usually three to five years out for software, five to 10 for devices, it's out there.
So this idea about thinking longer term is important. Now, none of those companies, none ignore the short term. I mean they care about quarter to quarter, but they care more [laugh] that the long term. And so I think that's pretty much a big philosophical difference. A lot of, I mean we have big problems obviously in a lot of the world, but in the US in particular, we have a lot of companies that it's very short term. It's all about maximizing the executive's compensation, which is based on the stock price, which is very short term thing. And so these are issues beyond my pay grade. But if you've ever heard of, there's my favorite thinker on this topic is actually his name is Professor Galloway, Scott Galloway [affirmative], prof G. And he is very eloquent on this point and I think he's spot on.
Brendan Jarvis:
You touched on organizations going agile and it seems that every organization has either gone or is going even long established organizations like banks are adopting the sort of Spotify way of working and trying to emulate what they believe they see in the tech leaders and the product leaders like Google and Amazon and Netflix. But digital transformations don't always work from what you've observed. Why do they often fail to deliver on their promise?
Marty Cagan:
Yeah, they usually fail [laugh], in my experience, they usually fail and what's going on, they don't even understand what they're trying to do. They think it means move to Agile, which of course Agile. I wanna be clear, should the company move to Agile? Yes. But is it gonna solve the problems we're talking about? No, no. The best it usually does is help you recruit better engineers, but that's not really the issue. We have to address much more fundamental issues that go all the way to the top of the organization. Most of those companies that fail in these digital transformations, the CEO knows they have to say something because the press asks them about it, their investors ask them about it. So they hire somebody and say, you're the chief digital officer, [laugh], do your thing. And of course that's a way for them not to actually transform because they're pushing it off. But one of the things we tell, look, if you wanna transform, it impacts a lot more than product design and engineering. It impacts finance, it impacts hr, it impacts your stakeholders, impacts the relationship between the product organization and the business units. So unless you're willing to tackle that, save yourself a lot of time and money, it's not gonna happen. So yeah, it's easy to see on most of those transformations go nowhere fast.
Brendan Jarvis:
And if they're not willing to make those fundamental shifts, it sounds like you're advocating for them to continue the way that they were rather than go through the disruption of going into
Marty Cagan:
I'm not, what I'm advocating is that the market will probably correct things over time. If a company wants to change, then I think they absolutely can. And I'm in happy to help if I can't. But if a company doesn't wanna change, I don't think you can do too much. You can't. And some of those companies that don't want to change, big banks and big financial institutions, big healthcare insurance companies, they don't want to change because a lot of them are in protected industries. Telcos, they, they're in oligopolies, they love things the way they are. They're making tons of money and the main thing is they don't wanna mess it up [laugh]. So I don't know, I've never really had success convincing them that they ought to change. They're like, why? Things are great. Now if that changes, it's starting to change right now in the financial services industry because the rise of some really good startups that are truly disrupting their space then people are changing their tunes. But until they have a motive, [laugh] hard to get them to change,
Brendan Jarvis:
Isn't it? Isn't that true? So who is empowered really written for them? If it's not the people that aren't willing to listen and don't have the incentive to change, who are you really trying to speak to with the book?
Marty Cagan:
Well the good news is there's countless companies that know they need to change and want to change. And that's who it's really for. What the motivation was, I had written the second edition edition of Inspired, which got a lot bigger distribution. It went to a lot more places than just Silicon Valley all over the place. And I would often meet teams that would say, oh, we love this, we wanna work like this. It makes total sense. But then they'd say, but our management won't let us work like this. Literally we're not allowed to work this product. Discovery doesn't even make sense on a featured team. You're already given the solution. So there I realized that it wasn't enough to share the practices of the teams For those companies. You have to share the practices of the leaders. And so that's who it's for. If you've got a company that wants to change, no, they need to change, then it begs the question, how do you change [laugh]?
And that's a fair question and I think it's the right question. I meet a lot of leaders of those organizations that are, at least I'm convinced that they're sincere. They really do wanna change. But when I explain to them their responsibilities as leaders of engineering, design and product, it usually gets two responses. The first is we're not doing any of that right now, [laugh]. So they have a lot of work to do. And second response is, and it's hard, what I'm describing is hard, and they're like, where do I learn to do that? I mean most of us that have done that, learned it from others that have done that. And these people are at companies where nobody may have seen this done well before. So it is a lot of, in fact, I've been giving a talk lately called Product leadership is hard [laugh] because it really is hard and especially if you've never been there, done that. The good news is I do think it's something that is learnable and that was the motivation for the book. It turned out to be a pretty big book because there are a lot of complicated topics there.
Brendan Jarvis:
And you suggested that if your organization's product management or your product outcomes are poor, that that's often a reflection of the product leadership and in most cases that someone like the head of product. What do great product leaders do that their average counterparts?
Marty Cagan:
Well, quite a few things. I mean, I would start with the number one responsibility, which is to coach and develop their people. And in fact, I tell these product leader, I'm really talking here to the leaders like Vice President of product management, the head of people who manage other product managers. I tell them, you will be judged by your weakest product manager, [affirmative] cuz that's how it works in these kinds of organizations. Products come from product teams like we talked about before. And if the product team has a bad product manager, it's really hard to come up with good solutions. So they need to make sure that there are no really weak ones, that the bar is quite high for that that's really the first order of business. If they can't do that, none of the rest is gonna matter. But if they do that, then they have other big obligations like the product vision we talked about. The biggest one is really the product strategy. The product strategy is right at the heart of what good product organizations, how they really leverage the talent of their people. So it's a big job, but I think if people put in the effort, they can learn it.
Brendan Jarvis:
You mentioned before that it's difficult for people to know what great product looks like if they've never been coached or exposed to what that is. If you are a head of product or a VP of product and you are listening to this or you've read Empowered and you've got some insight into what you could do as a start, what do you do next?
Marty Cagan:
Well, the biggest section, if you remember in Empowered is on coaching because that is the most important thing. And one of the things I wanted to do was if your manager's experience, it's pretty straightforward every week you do a coaching one on one and your people get better. But what if that manager has never seen it done well before? Well, you can replace yourself or bring in an executive coach, something like that. Or what I wanted to do was make it so that, okay, I'll give you a topic every week and you can have a different topic every week for a year. And that's how many topics there are. And every week you and your product manager sit down and discuss that specific topic, give you plenty to talk about each time. The topic today is how we make decisions. Topic tomorrow is how do we work with difficult executives, whatever the different topic is, and we'll talk about it together and talk about how you can try this out. And I do believe that works. I've seen that work. So in it's a way, it's kind of given a structure or framework to the manager so that they can get better at coaching along with their people.
Brendan Jarvis:
It sounds like one of the outcomes from coaching is increased competence,
Marty Cagan:
And that's exactly the goal. You wanna increase the competence of your people. That's our first obligation
Brendan Jarvis:
And competence. I mean that sounds like table stakes it, and it sounds really obvious, but often really big insights seem obvious upon reflection. Why is competence so critical in product management?
Marty Cagan:
Well, partly because IT product management is hard, number one. And number two, it's not something people are born with also, it's not something that's typically taught in university. So where do you learn? I mean, engineering, you can typically take somebody who's a recent CS graduate and they do, a lot of times they learn more theory than practice, but pretty soon you can have them doing commits really as a full member of the team design. Similar if they've been through good design education product, not so much product is like where do you learn those things? There is more coaching and development I think necessary for product management because it is so hard for people to get that foundation on their own.
Brendan Jarvis:
I wanna turn the lens onto you if I could, on this topic of competence and coaching. Who coached you on what great product needs to look like?
Marty Cagan:
Yeah, well I'm only here because of those people [laugh], and I was mentioning to you that I didn't even realize how lucky I was when I was getting it at hp. It was just everybody got it. It was part of the benefits of working there is you get this kind of coaching help. And a little while ago I introduced somebody to join Google because they had been in a company where they were very, she was very underutilized, let me put it that way. And she was frustrated and I introduced her and she told me that after three months she had learned more and done more at Google in three months than she had done for the previous few years at this other company was. And this is the same human being, same mind, everything. The difference was coaching and an environment that let her do some work.
So yeah, I think this is exactly right. I mean the first person who, oh, it's hard to say who was all my managers basically have been. Now obviously some managers are a lot better than others, [laugh], and I think that's true of anybody who's worked for a long time. But I will say that my favorite people made a tremendous impression on me. The guy who coached me on product at hp, his name was Mike, the CEO at Netscape Communications. Jim Barksdale was my first exposure to an amazing ceo. I never realized what a difference a CEO could make until I met him. And
Brendan Jarvis:
What made him so amazing? What was it about him?
Marty Cagan:
Yeah, well that's a hard question. I mean professionally, what made him so amazing? He was the original COO at FedEx, so he was there from early days at FedEx and Fred Smith is a legendary CEO there who had, he was awesome. I had met him a couple times through Jim Bartel, but I mean his wife, FedEx became a world name. And anyway, he worked with him side by side for those early years. That's probably where he became awesome. But he had done some other work and then he took over Netscape and he really developed that company. I mean it was a difficult kind of thing competing against Microsoft, but it was an amazing experience. And the guy I just learned so much watching him and I wasn't the only one all so many of us, I learned a lot from Marc Andreessen, the co-founder. I learned a lot from Ben Horowitz, who unfortunately for me, I did never worked for him, although I wished I did.
He is so good at developing people, but he still was kind enough. He would not say he coached me, but he coached me [laugh] because he shared so many nuggets and he gave me feedback on things that his feedback was so valuable because it was so honest and so spot on. So I learned a lot from him. There were several other people there as well that I really learned a lot from. And a lot of companies there are really good people if you're open to their lessons and I really took advantage of that I think everywhere I worked
Brendan Jarvis:
[affirmative]. And after hp, you founded a company called Continuous Software Port that was a went public eventually on the nasdaq. Nasdaq, sorry, and was acquired by ibm. What was it that took you away from a company that you'd founded and pulled you and attracted you to Netscape? What was it about that company?
Marty Cagan:
Well, I mean the reason I joined that startup was because I hit 10 years at HP and I felt like I wanted to go see what I could do. HP was very nurturing, [laugh], you pretty much could, but it was not like you're on your own. It was a massive company, much bigger than it is today. And so I wanted to do a startup and it was another software tools company. I loved that space. It was enabling things that are very common today. So it was a fun thing. But what happened was Netscape started, and I actually got, the first time people reached out from Netscape was some of the earliest developers in Netscape. And I always tell people my biggest mistake was not joining right then at the beginning of Netscape because it was would've been an amazing experience. The problem was I had been for several years at this startup, we were getting ready to go public and getting it.
It was really, and I had recruited almost everybody and I felt like I can't leave. But about a year later we had of reached a point where I felt like I can leave. And so when they called again, I'm like, I'm there. And so the best worst decision was saying no the first time the decision was saying yes the second time it is hard to leave a company that you build like that. But I was there five years and the products still exist today, so I feel real good about what they did and many friends that I worked with there. But Netscape was really a once in a career experience, [affirmative]. And so I truly am grateful that I got to have a front row seat to the birth of the internet.
Brendan Jarvis:
What was it like?
Marty Cagan:
I mean it was for me the dream job in truth, and I'd still be working there if we were still going but I mentioned that I've always loved working on technologies for other developers. And Netscape was in the position of really, I mean in truth, the company that was in that position before the internet was Microsoft. They really provided the tools that most development teams use to build applications. But when Netscape happened, it was very different. And Marc Andreessen's view was that the technologies that people will use to build on the internet will need to come from not just Netscape, it will come from Netscape plus the broader ecosystem. It's too much too soon. No way for one company to do that. And one company shouldn't do that. And so some of the technologies came from, I was responsible for platform and tools. So some of the technologies like JavaScript, ssl, these came from Netscape, but other ones like Flash came from Macromedia, which became Adobe and Java came from Sun.
These were places they were building lots major components for today's internet. And so my job was to put these together into an offering for developers to build startups. That's when I met eBay, the founders of eBay or big companies like FedEx I met and Walmart and companies that were using the internet to solve longstanding problems. So what a great fun place to see and just there were so many terrific people that were drawn to Netscape. And so I could list a hundred people that made a big impact on me because I saw their skills at Netscape.
Brendan Jarvis:
That's great. You obviously mentioned Marc Andreessen and Ben Horowitz, who I would be surprised if anyone listening to this doesn't know who those two gentlemen are. I remember reading a book called The New Thing maybe 15, 20 years ago, and I was just a child and it mentioned Jim Clark and he seemed like quite a character. Did you have anything to do with Jim Clap while you were,
Marty Cagan:
He was the co-founder actually with Marc Andreessen, but the guy has started several, I think four major billion companies. The guy is kind of amazing but he didn't wanna be the ceo. He brought in Jim Barksdale to be the CEO of that company. And so he kind of stepped back, but he was still on the board and I, I'm trying to remember if he was the chair. I don't remember. It was 25 years ago. But yeah, a very impressive guy and I knew it because he had done Silicon graphics before Netscape and I was a huge fan boy of Silicon Graphics. So I mean, yeah, it was pretty much a collection of rock stars there for a while. And in the book I highlighted the vice president of engineering for the biggest part of Netscape. The browser was a woman named Debbie Beeth and she was one of the leaders, the eight leaders I profiled in the book Empowered and I got to see her do her thing, which was fabulous and many more. Yeah.
Brendan Jarvis:
Mm-hmm. [affirmative] such an important part of the Internet's history. Like you mentioned, it really was the birth of the internet or the worldwide web. I'm fascinated to know what it felt like being at Netscape when you realized that you had lost the browser walls.
Marty Cagan:
Well mean the company was the fastest company to a billion dollars in revenue and then Microsoft decided to give away the same stuff, essentially the same stuff for free. So it made that money kind of evaporated very quickly. And now it's not like that totally surprised us and that's why people like Ben Horowitz were working so hard to build revenue products that were server based and that's what then was working on. And that business had a remarkably fast growth but not fast enough to offset losing a billion like that. So really, and that combined with a lot of technical debt on the browser side because of such an intense competition. And unfortunately, I mean tech debt really is the thing that put the nail in the coffin there. Of course the company still lives, half of it went to Sun, which is part of Oracle now, and half of it went to Sun, no to aol, which is part of Verizon now I guess. So it still exists, but not the same of course.
Brendan Jarvis:
So I'm guessing that Bomber and Gates weren't on anyone's Christmas cardless that year.
Marty Cagan:
[laugh]? No, no. But I still really do Microsoft, I like them before 'em better now. I didn't really like them during the bomber is era, but I really do admire what they've done and I really admire what Satya has done in the last several years to turn that company around and make it innovative again to make it, they have their product mojo back and I am so impressed. I love to see that happen to companies that obviously happen to Apple, that happen to Disney. I love when they get their skills back.
Brendan Jarvis:
So after Netscape, you had a brief tenure at eBay before you founded the Silicon Valley Product Group. [affirmative], I was curious about that. I mean that time at eBay, I was curious about that as well, but I was also curious about the decision after eBay not to go into your own tech startup again, not to continue to work for larger organizations in a product leadership role. What was it about founding a service based business over a product based business at that point in your life that you made that decision?
Marty Cagan:
Yeah. Well I wouldn't even really, when you say founding Silicon Valley Product Group, it's not a different kind of company. It's not meant to be a growth company. So I wouldn't even put it into the category of that, but it is what had happened was I had been incredibly lucky at those companies at that time. There was a lot of right place, right time, and so it kind of left me situation financially where I didn't have to do another one. And I had done the startup and I felt like I had sort of checked the boxes of all these things I wanted to do. And what I really wanted to do after that was I wanted to write, I wanted to work with startups. One of the things I learned by the time I had reached my time through eBay was I learned that I, I really fall in love with lots of companies, but when I've worked there a while, you kind of have done the fun part already [laugh]. And I found that I like to work with lots of companies at once, not just one. And so that's what sort of pushed me to this idea of having a portfolio of companies that I advise and that way I get fix with lots of different companies and I'm still doing that. So I mean next year will be 20 years doing that. It's hard to believe
Brendan Jarvis:
And adding a lot of value to a lot of people in the process, which is greatly appreciated by the community. Just shifting gears and talking about something that you picked up a little on a little bit earlier, which was this importance of discovery. And I think you mentioned the four big risks in discovery and we'll come to those soon. I've heard you say that discovery and delivery are the heart of modern product management, yet it seems to me from even on the ground here in New Zealand that discovery seems to be, delivery is much poorer cousin, it's often neglected if it even happens at all. Why is discovery treated that way?
Marty Cagan:
Well, honestly it's because in a feature team company, you only do delivery. That's really why. So if the company is feature teams or delivery teams, even more, it's just delivery, maybe it's not discovery, it's a little design. That's it. If you need an, there is no concept really of discovery without an empowered product team because empowerment means you get to go discover a solution that works. If you're given a solution already, then there's nothing to discover [laugh]. So that's why you're seeing that they go together. Interestingly, and this is maybe not a topic you want to rat hole, you want to go down, but it's the same thing with OKRs. OKRs don't make sense unless you have an empowered team. It's like t you see companies try to say we wanna do discovery, but they're a feature team. So they go, oh, well what are we supposed to do? Same thing with OKRs. They're a feature team and they're trying to do OKRs and they're like, well this doesn't make any sense. We have a roadmap and we have an objective. What are we supposed to do? So the techniques that I advocate are only the ones for empowered teams. Plenty of other people advocate the stuff for feature teams. That's what most of the industry does. And that's fine, let 'em do that. But there are a set of techniques that go along with empowering people.
Brendan Jarvis:
Assume you do have an empowered product team. So we've done hard work of making sure the beliefs of the culture are there to support that and we're actually working that way. Now those big four product risks that you mentioned, I believe they were feasibility, viability, usability and value. What is the hardest one of those to address? Or which one should you be focusing most of your effort on trying to satisfy or juice?
Marty Cagan:
Well, I mean the first thing to realize is if you don't address any one of those and it's important, you'll have a failed product. So any one of those can kill you. So table stakes is to consider all four all, but the truth is a lot of times different risks are not very risky. It's not like we know how to build this, there's not a feasibility risk, we know how to design this. There's not really usability risk. The one risk that is the one that bites most teams is value. Value is the hardest one. Generally speaking I used to say that with a lot less hedging, but today so many of the teams I work with are trying to apply machine learning technology. And in those cases, feasibility risk is like the number one risk for them. The value isn't really the challenge, it's feasibility, but for most situations it's value.
And value is really two things. It's one is does anybody want it at all? That's demand validation. Does anybody, even if you solve this problem better than anybody in history of mankind, will anybody buy it? That's demand risk. But the harder part of value is no, of course we know people need this, they're buying other solutions, they're just not very good. The real question, is it valuable? The question is, is our product solve that problem? Does our product solve that problem better than everybody else? To the point where people will choose us and switch to us? That's the hardest part. In fact, Ben Horowitz likes to argue, the reason product is so hard is because your product needs to be perceived as on the order of 10 times better in order to get people to switch. Well, that's a pretty high bar, 10 times better. It's hard to even quantify that, but it sure is, it's easy to see that it's gotta be perceived as significantly better if you want people to switch to your product. And honestly, in a nutshell, that's why most products fail. That's why most startups fail. They just don't hit that bar. It's not valuable enough
Brendan Jarvis:
[affirmative]. So what methods have you seen that are most effective for reducing that risk or increasing confidence that you do actually have something that's valuable to that degree? The 10 times more valuable than what they're currently using?
Marty Cagan:
Yeah. Well the first thing you gotta do is acknowledge that your pet ideas for solving that problem probably aren't gonna work and probably won't be enough. And so there's a bit of humility that comes into it. One of the things we often say is you want to fall in love with the problem, not the solution, right? Because the problem is what it's about. You're gonna focus on that problem and then you need to, that's why discovery is so important because discovery means you're gonna try many different approaches to this problem and hopefully come up with, if you're skilled and a little lucky, you will come up with a solution that people are like, I gotta have it. But that only comes from discovery. The chances of that solution being on some roadmap from some stakeholder group in a quarterly meeting is close to zero
Brendan Jarvis:
Marty. But this is really so counterintuitive for so many people. A lot of the ego that we have is held on our premise or our ability to be right or at least seem to be right. I mean, this way of thinking for a lot of people is gonna be thoroughly uncomfortable to suggest that you might have 10 solutions to the problem and none of them may work, but your 11th might be the one that works. I mean, how can people really become comfortable with being wrong? So often
Marty Cagan:
We were talking about people that have influenced me before and I mentioned Marc Andreessen. So in my career, which is this year, 40 years in tech, so as long as pretty much anybody I know, but a long time, he is literally the smartest person I've ever met. And I have worked, I've met and worked for some pretty smart people, but he's like, and I worked for him even though he was significantly younger than me. I felt like I was the student and he was the teacher. But it's ironic that the smartest guy I ever knew, the main lesson that stuck with me of all the things he told me was the most important thing in product is knowing what you can't know.
And I really believe that deeply. And I think he was right. And I know that when I was just getting into product, I know I was just as arrogant as everybody else and I was like, I very confident this was what was gonna do it. But it doesn't take too long before you start to realize that a lot of your ideas don't play out the way you thought. So today, of course I have a much different attitude. To me it's like, yeah, I have great, I have ideas and I know that most of them will be wrong, but I know that the real goal is for us to very quickly figure out which are good and which are bad. And so it's like that and you don't get attached to your ideas because their, they're [laugh] not likely gonna survive. So yeah it's really true. Know what you can't know and the corollary there is admit what you don't know.
But if you have that mindset, it's very different. It's like, okay, we got lots of ideas. We're gonna try it out. We're gonna see what really works. We don't know what people will really buy. We're gonna find out what they're gonna buy. We don't know what they're gonna pay. We're gonna find out what they're gonna pay. It's a very different mindset. But that is, and you're right, it is very foreign. The difference between the best companies and the rest is remarkably big. It's amazing how big the difference is. And we are talking about feature teams and empowered product teams are just the manifestation of those beliefs.
Brendan Jarvis:
[affirmative], it's interesting you talk about, you know, were confident, you thought you knew what was going on, and over time you've obviously changed through experience, how you view that. It sounds like Marc had figured out a deeper level of confidence, the confidence to be confident in knowing what you don't know as you've said, and knowing that you need to figure that out. It's almost like he was operating from a lower level, a more fundamental level.
Marty Cagan:
I mean is seriously smart guy [laugh] the truth.
Brendan Jarvis:
So let's shift our focus now and consider some scenario based questions. I've got just a couple here that I wanted to put to you, and it's really the purpose of this is just to help anyone that might be listening that's in a scenario that they could relate to that these questions are about. So you ready to give it a go?
Marty Cagan:
Sure.
Brendan Jarvis:
Awesome. So you've joined a new company as a product manager and have found that your designers and engineers seem to have little understanding of how the business works. What should you do?
Marty Cagan:
Well, as product manager, that's what you're bringing to the team. That's what you are supposed to know. You're also supposed to know how your customers work, but how your business work is very tangible. The designers and the engineers are not expected to know that. Just the product manager is not expected to know how to code. The product manager's expected to know how to design. So we each bring different skills to that table. So your job as product manager is to bring this knowledge, make sure you do your homework and you will. That's a lot of value add for the team. Without that, they can't really make decisions, they don't have the context.
Brendan Jarvis:
So it sounds like you save them from the mental load of feeling like they have to know that stuff by bringing that yourself. Yeah,
Marty Cagan:
And that's right. That's why by the way I talk to developers all the time and are like once I had a real product manager, I will never go back. They see the difference.
Brendan Jarvis:
So you've been head of product for a while and that you've realized that you should be doing a better job of coaching your team. How should you start
Marty Cagan:
Immediately by doing an assessment of every one of your team and then you should put a coaching plan into place for everyone and then you should start at least weekly one-on-ones to help everybody reach their potential? Absolutely. Right away. 1, 2, 3.
Brendan Jarvis:
Yeah, it makes a lot of sense. You're a product manager for a B2B company. Your team is working on a new feature and you want to know how valuable it is for your customers. How do you do that?
Marty Cagan:
Well, there's a lot of techniques we have to measure value b2b, especially if it's enterprise b2b, we may not have a lot of volume, but we do have a lot of names. So we will probably do this qualitatively rather than quantitatively. So what we'll do is we'll typically bring a prototype of that feature which will create quickly in a day, maybe two, we'll bring that prototype and we will test that prototype on what we like to do in an enterprise. B2B have a small set of companies that we're working with very frequently. They're more like, they're like opt-in beta companies that do they want the latest, they wanna see the latest, they want to have an impact. So we're using them to gauge, and we're probably gonna use, in this scenario probably a qualitative technique to measure this, to see if this, we're really looking for two things from them. Can they figure out this feature and would they actually use this feature if we can convince ourselves the answer is yes and yes, we're ready to build it.
Brendan Jarvis:
I've heard you write about, I think it was in Inspired that you can use a technique where you might have a non-binding letter of intent that if what they've seen today is something that they would find valuable and they would use it. Yeah. Will they commit to it by signing that letter on
Marty Cagan:
The day? Yeah, we probably for a feature we wouldn't need something that big, but for a big thing like a major new offering or a major redesign or something, then that's where it applies.
Brendan Jarvis:
Got it. Some rapid fire questions.
Marty Cagan:
Sure.
Brendan Jarvis:
I feel like I'm putting you on the spot here, but I think with 40 years of experience doing what you're doing, you probably know these, the back of your hand, [laugh]. So in the product team, who owns the customer?
Marty Cagan:
Well, that's a dangerous thought. I would argue. Nobody owns the customer and all of us care. Great deal about the customer and need to, that's part of our culture. We need to but we're all looking at different things. The product manager is looking for how does a customer make a purchase decision? Who are the different kinds of people that will use this product? Who buys it? Who influences the buyer, who approves the purchase? They're learning all about that customer dynamic there. On the other hand, the designers are trying to get inside the heads of the different kinds of users at the customer. So they're trying to understand their mental models. They're trying to understand, so how do they think about a purchase for, well, not a purchase, that would be a bad, that could work also, but how do they think about whatever they're trying to do, set up payroll or whatever it is.
And then of course the engineers are trying to understand exactly where the pain points are for those users because often they can see a way to solve it that the designer and the product manager can't see. So we all care about the customer. None of us just owning a customer. I is a weird thing that we wouldn't think of it that way. Sales may own a customer relationship, especially in an enterprise b2b, and we'll respect that relationship. We won't go talking with it, visiting the customer without telling the sales person, but all of us on the product team need to really deal directly with those customers.
Brendan Jarvis:
Yeah, it makes a lot of sense. What is the correct way to think about the term mvp?
Marty Cagan:
Well, that's another loaded one. There are different legitimate interpretations of mvp, but the problem is each one sort of brings along a whole set of definitions. You kind of have to go with what I try to explain to people, because I think this clarifies it more for most people, is think of the MVP as a prototype. The problem with P is it stands for product, right? Minimum viable product. But it should never be a product. It should always be a prototype. And remember we said there's four major risks. Well, there's also four kinds of prototypes depending on the risk and the kind of issue we're dealing with. So the idea of an MVP is what's the smallest way to test some specific risk. And so that's why we create all these prototypes. So if you just think of it as a prototype, things make a lot of sense. Where teams get into trouble is if they confuse MVP with a product. Products are different animals, products are something that you can run your business on that your customers can depend on. If you're doing that in order to do an mvp, you are spending way too much time and money and you will go way too slow
Brendan Jarvis:
[affirmative]. And what's the risk of doing both of those things?
Marty Cagan:
The risk of going too slow is that you run outta money or you run outta management's patience. That's the big problem. Yeah.
Brendan Jarvis:
You've spoken about it's important to not have assholes on your team. You've also spoken about how hiring for cultural fit is a problem. How do you tell if someone is actually an asshole or if they just think differently and it's different to the way that the team currently thinks?
Marty Cagan:
I like to tell the story about the All Blacks in New Zealand because there is a great book called Legacy. You may have heard of it, talking about really the legacy people don't, people outside of New Zealand don't appreciate the monumental achievement the all blacks have done and they have the same policy, they don't use the same term, they use a little more colorful term, but they have that no asshole rule and applies to players and coaches. And they figured something out a long time ago that a lot of us took a while to figure out. But it doesn't matter how skilled somebody is if they're toxic. And that's really what we're talking about is toxic behavior. And so yes, these people are very dangerous to a company. Now there's the challenge of course, is most people, even toxic people are smart enough to hide that toxic nature during an interview [laugh].
So if they can't hide it and you still hire 'em, you've got bigger issues. But if they do manage to high hide it and now you've hired one of these people, that's where it's more difficult. Cuz I really think it's important to correct that. Now, if that person is not contributing a lot, it should be easy to correct that they're not contributing and they're assholes. So the problem is when they're assholes, but they are contributing a lot. Let's say they have some deep skill that's rare. This is where managers often face a real dilemma. And one of the things I've learned and people who've met many other managers who tell me they learned the same thing, it was very painful to remove those people. But once they did, they were so wished they had done it a long time before. Cuz it's one of those things, Google has written a lot about this over the years called Under the title Psychological Safety.
And they talk about how much better their teams perform when they don't have one of these assholes on the team. And it really does destroy this collab collaboration that's needed in order to discover good solutions. So yeah, it's difficult for sure. I find that one of the tips I do is on the assu. First of all, I think I'm pretty good at an interview of drawing this out, but I have been fooled [laugh], so I know that others have been fooled too. One of the things that I find is quite reliable, but I will say in some parts of the world, like Europe, you're not supposed to do this, but they don't care. In the US we look on their social media presence. Usually if somebody's toxic, they're toxic on Twitter, they're toxic on LinkedIn, you can look at what they say in response to ideas, how they interact with people.
It's like, oh my God, there's a good chance if that's they're acting in public like that, they're gonna do it also on your team. So my view is if they're, I mean, I've never done anything like to figure out who they are online. It's like they're self declaring, this is me. They're saying, this is my Twitter handle, this is my LinkedIn profile, so I'll go look. And so I tell people, there's been people that I, companies that I coach, and I'll see them online and I'm going, just so you know, I would never hire you based on your dialogue yesterday, online, you tell 'em that, oh yeah, I say you're coming across as a complete asshole. Do you know that? Do you realize that I think I'm doing this [crosstalk]? Yeah,
Brendan Jarvis:
Yeah. Well, undoubtedly you are. How do people tend to respond to that?
Marty Cagan:
What Most people in my experience don't realize they're doing that. I mean, this is one of the problems with online. This is one of the problems with work from home often, it's a lot harder for me to insult you to your face right now. Like Brendan, you, that's hard. But if we were online, if we were over slack, we say things all the time that are just not well thought. The sensitivity level is pretty low and those people are like, God, I didn't realize I was being such a jerk. And so I'm like, well you, so you need to know that. So stop it or apologize something. And I wish more managers would tell their people that
Brendan Jarvis:
Conflict aversion is to cause so many issues, particularly when you've got someone toxic and you fail to act. What you're saying makes a lot of sense. The last one is, you've got a million dollars to create a new product. How much of that million dollars do you spend on discovery versus delivery?
Marty Cagan:
Oh, there's an interesting question. The nice thing is it's not very expensive to do discovery today but proportionally I mean, realistically, it's usually about 20% of the cost. So couple hundred thousand dollars worth and remember, it's a lot faster cycles and usually a lot lesser number of people. So if you've got an organization of 10, there's maybe three, the equivalent of three doing the discovery work and the equivalent of seven do or eight really doing the delivery work. So yeah, it'd probably be about 20%.
Brendan Jarvis:
So it sounds like the ratio of who's doing discovery versus delivery is similar to the ratio of where you invest those dollars as
Marty Cagan:
Well. And that's just natural that the product manager and designer are essentially full-time on discovery. The tech lead is part-time on discovery and the other engineers a little time on discovery and then in delivery for all the engineers and part-time for the product manager and the designer. So works out. That's about the breakdown.
Brendan Jarvis:
Got it. Got it. So just bringing us down to a close, Marty, thinking about where product management is today in 2021, what's your greatest hope for this profession over the coming years?
Marty Cagan:
Well, my greatest hope, honestly is that a much higher percentage of the organizations out there are actually letting their people do their job. And so would be what we've been talking about is empowered teams. If today, maybe that's 10%, 5%, it's hard to say worldwide, I'm just guessing. But if in the future that was reversed, that was the majority, by far, I think we'd have a much better world as far as products and a lot happier people.
Brendan Jarvis:
Marty, this has been a hugely insightful conversation. Thank you for so generously sharing your insights and experiences today and for your continued leadership in showing us what great product management looks like.
Marty Cagan:
Well, thanks very much. I enjoyed it. Hope it's useful, Brendan.
Brendan Jarvis:
Oh, most definitely. You set a high bar for the field, which I think is hugely aspirational and inspirational for product managers around the world. And Marty, if people want to find out more about you and what you do, read your books, what's the best way for them to do that?
Marty Cagan:
SVPG.com. My emails on there, Twitter's on there and the books are described on there. You can figure out the formats and where they're available and the translations, no problem.
Brendan Jarvis:
Wonderful, thanks, Marty. We'll be posting links to all of Marty's great resources in the show notes on YouTube and everyone that's tuned in, thank you. It's been great having you here too. Everything that we've covered, including a full breakdown of the topics and questions that Marty and I have discussed, will also be in the show notes. If you enjoyed the show today and you wanna hear more of these conversations with world class leaders and design, UX and product, don't forget to leave us a review and subscribe. And until next time, everyone, keep being brave.

Marty Cagan

Empowering Your Product Teams

Subscribe

Who is Marty Cagan?

Transcript