#102 - Building Inspired & Empowered Product Teams - Marty Cagan

[00:01:18] Episode Introduction

Henry Suryawirawan: Hello, my friends and my listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. And you’re listening to the episode 102. If this is your first time listening to Tech Lead Journal, make sure to subscribe and follow the show on your podcast app and on LinkedIn, Twitter and Instagram. Every day, I post interesting quotes from the episode to inspire us and to spark a discussion within the community. And if you’d like to support my journey creating this podcast, subscribe as a patron at techleadjournal.dev/patron.

My guest for today’s episode is Marty Cagan. Marty is the founder of the Silicon Valley Product Group and the author of the amazing books “Inspired” and “Empowered”. In this episode, we discussed how companies ought to build great products by learning from the best product companies. Marty explained the importance of building the right product, and he shared the two inconvenient truths about building products. Marty then elaborated on the traits a good product team has and how to create an empowered product team by ensuring ownership and alignment with a clear product vision, strategy, and focus. Towards the end, Marty shared the importance of coaching and nurturing people, how to hire better, and how to structure product team topologies.

I hope you enjoy listening to my conversation with Marty. And if you find it useful, please share it with your friends and colleagues who can also benefit from listening to this episode. It is my ultimate mission to spread this podcast to more people. And I really appreciate your support in any way towards fulfilling my mission. Before we continue to the conversation, let’s hear some words from our sponsor.

[00:05:04] Introduction

Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today I’m really excited to have a guest who I admire by reading his books. His name is Marty Cagan. He’s the founder and partner of Silicon Valley Product Group, or SVPG in short. Well, before founding this SVPG, Marty has served in few successful companies as the executive leading the products development, including HP Labs, Netscape Communications, and eBay. So if you haven’t heard about Marty Cagan’s book, those two books are titled “Inspired” and “Empowered”. Those two books are really, really good if you haven’t read it. Today I have a pleasure to talk to Marty. So Marty, welcome to the show. Thank you so much for spending your time.

Marty Cagan: Oh, thanks very much for inviting me, Henry.

[00:05:48] Career Journey

Henry Suryawirawan: So Marty, I always love to start my conversation by introducing the guests, asking them to tell their stories, any highlights or turning points in their career.

Marty Cagan: Well, be careful what you ask because I’ve been doing this a very long time, actually. I just hit 40 years exclusively doing tech products. So for a long time. I studied Computer Science in school and I was sort of in that first wave of developers. I joined what was considered today is sort of like the Google of the day. HP was considered the most consistently innovative tech company in the world at the time, and so my professors at school told me that’s the great place to work. And I spent 10 years there as an engineer.

I started by writing software, and then I got promoted to tech lead. Speaking of which, that was the first time I was a tech lead. HP had an engineering leadership training program. So I went from tech lead to an engineering manager. And then I wanted to move over to product. I’ll tell you about that in a second. But what I should say is through really my entire career, with really just one exception, which was eBay, all the products I worked on were products for developers. So I love developer products, developer tools. I worked on languages. I worked on operating systems. I just like doing tools and environments for other developers. I think a lot of developers like doing that.

So, I did that, but what happened was about halfway through my time at HP, I worked on a product that was very ahead, very advanced product. It was called the HP Artificial Intelligence workstation. But you have to realize this was a good 30 years before AI technology was ready. We had got this in technology from universities and we were way too early. But anyway, we built this product. This is before the internet. Products took one to two years generally to do a product. A long time. Anyway, we finally released it and nobody wanted to buy it because there was no market for this at all. Some university researchers, but then they wanted everything given to them for free. So there was no market at all. It was the first time I really asked the question who decided we should do that product? I was so excited about the technology, which was really cool technology. It was the first time I got to use object-oriented languages, and we did rule based language. It was very cool technology. But it was the first time I asked the question, why should we do this product? And I learned that there was a whole other side to the product, which is figuring out what to build, product managers, product designers. I had been introduced a little bit to that when I learned to be a tech lead, but not much. And so, I asked my engineering VP. I told him I wanted to learn product management. And he said he didn’t know it himself as an engineering leader, but he would find somebody at the company who would agree to coach me, and he did. For the next product, which was another set of tools for developers, I was both the tech lead and also the product manager. And I had this person guiding me to make sure I did a reasonable job.

So that got me interested in more than just engineering, more than just the development. I’ve always been interested in both. In truth, the rest of my career, I kind of have a reputation for talking a lot about product managers, but it’s not really by choice. My interest has always been product teams. I’m interested in engineers, working with designers, working with product managers to build something great. That’s what my interest is. It’s true though, that I know a lot of very good people that write and talk about engineering, tech leads. I know a lot of good people that write and talk about design, but there’s not many people that talk about product management. So I find I have to talk more about it because it’s the weakest link in a team, often.

Anyway, after 10 years of doing products for developers, I was very lucky because, for those that don’t know, the original internet company was Netscape Communications. I got to work for the co-founder, Marc Andreessen, and I was responsible for, again, the development platform and tools. So now people were asking how to build large-scale applications that could serve millions of users. Nobody had ever done that before. And so, I was having a great time. We had JavaScript team in my group. We had SSL. We had application servers. We had Java, all these. Java came from Sun, as you probably know. Flash came from Macromedia, just all these pieces came together and we put together a platform for building internet applications.

One of the first ever applications built on the internet was eBay. I got to meet the founder of eBay, Pierre Omidyar, and I really liked what he was doing. When I joined, they had developers, but I was brought in as the original head of product and design to kind of bring those skills to eBay. And then after eBay, I just wanted to work with startups and growth stage companies. So that’s what I’ve been dealing ever since, which is really, I’m not providing tools anymore for developers, but I do share techniques. So it’s the methods, the ways of working and that’s really what I do for the last 20 years, actually. Yeah.

Henry Suryawirawan: Thank you for sharing your story. It’s really interesting. Fascinating, actually, to hear that you started from engineering, became tech lead, the normal engineering route, and then switching into product management, and now well known more for the product knowledge. But putting that aside, also, you worked on developer tools, mostly. So this is, I think, also a very interesting story. Thanks for sharing that.

[00:11:38] Writing Inspired & Empowered

Henry Suryawirawan: So, Marty, I think because of your history, right, working with products, including experiencing failed products, I think that led you to writing these two books, right? It started by “Inspired” and followed by “Empowered”. Inspired subtitle is “how to create tech products customers love”. And for Empowered, it’s like “ordinary people, extraordinary products”. So from these two themes, it seems like product is the main theme, including customers and also the people working on the product. So tell us more, maybe why you had the idea to write these two books? And what kind of problems do you want to solve with these two books?

Marty Cagan: Yes. And you’re making a good point too. My whole world has always been products. Either building products, designing products, product managing products, but always products. I’ve never actually been interested in custom software solutions. So like what Accenture does. Accenture has a fantastic business, but I have no interest in that business. I’m interested in creating a single product that millions of people want to use, not create one product for one company. So that’s the difference. And there’s nothing wrong with custom solutions. It’s just my interest is in commercial products, building real products. I’m interested in everything about products though, whether it’s the engineering or the design or the data or the user research. Anything about product is interesting to me.

So what happened was after I left eBay and I started talking to friends' companies in other places, I started realizing that there was a big difference between how the best companies created software products and how most companies were creating products. I was confused by that. I didn’t really understand why wouldn’t they want to work like the most valuable companies in the world. Why wouldn’t they want to work like the Amazon or like Google or like Apple? I didn’t understand why they wouldn’t. So I talked to a lot more of them and I realized that, for the most part, they didn’t know how. Nobody had ever taught them. They had managers that never worked at those companies, so they didn’t know how. So, I realized there was a need to share the techniques that good companies use.

In both of my books, there’s nothing in there that I invented or my partners invented. It’s all things we find at good companies. All I’m really doing is sharing that. Look, all the good companies seem to do this. They call it different things sometimes. One company will call it product discovery. Another one will call it “fake it before you make it”. Another one will call it “build things that don’t scale, then build things that do scale”. But they’re all describing the same thing. So I realized we needed to share that. And so, that’s what “Inspired” was. To share the techniques of good product teams. Especially, how does a good product team figure out what to build? There’s already a lot of books, many books on how to build the product. In other words, how do you get consistent, reliable releases? How do you do continuous integration, continuous build, continuous deployment? There’s lots of books on that. By the way, if I find a company that doesn’t do that, I’m like, you have to do this. This is critical. But even more critical is making sure you’re building something worth building. So I’m interested in that side and that’s what “Inspired” is.

I did two editions of “Inspired”. The first edition was really just for my little bubble in Silicon Valley sharing with friends, but the second edition, a bigger publisher took it and took it all over the world. And so I heard from a lot more people in places all over the world that are far beyond Silicon Valley. And one of the things they told me is that they love this. They want to work this way, but their managers won’t let them. And so I realized that it wasn’t enough to share the practices of the teams. That we also needed to share the practices of the leaders. And the practices of the leaders are even more different than the practices of the team. So the book “Empowered” came out to be even a longer book than “Inspired”. In truth, the techniques are harder.

The things I talked about in “Inspired”, I don’t think they’re very complicated. They’re more fun than anything else. They’re fun techniques. But in “Empowered”, when you talk about what a good engineering leader does or what a good design leader does, that’s hard. Those are hard topics. Those are not topics for 10 minutes on a whiteboard. You’re all done. It’s hard. So that was the motivation for the book “Empowered”. That’s really my books, and then I have a partner that just turned out a marketing book for product marketing people. And I have another partner working on a book about big company transformation. That’s another hard problem for sure.

[00:16:23] Building the Right Product

Henry Suryawirawan: Those two books are titled “Loved” and “Transformed”. I think some of it are not published yet. Marty, you mentioned that you have seen it, right, how the best companies build products versus most of us who probably had very little knowledge about how to build products properly. I think also coming from your experience last time in HP Labs, building that AI workstation. So you mentioned in the book that it doesn’t matter how good your engineering team is, how sophisticated the technology, if they’re not given something worthwhile to build. I think this is something really important that maybe we can dive a little bit deeper. Why do you think that building the right product actually matters first, regardless of other techniques?

Marty Cagan: Well, just common sense that if software is garbage in, garbage out. If the product backlog is full of nonsense, then what do you expect will be shipped? That’s what happens in so many product teams. The things that they’re asked to build make no sense. They’re feature chasing or they’re just doing what different parts of the business are asking them to do. There’s nobody really looking at what is the real problem for the customer and how do we come up with a solution that’s technically possible, but also works for the business, and also the customer would love. That’s a much harder assignment. It’s much harder work. But that’s really what good products have always been about.

[00:17:45] Two Inconvenient Truths

Henry Suryawirawan: And you mentioned there’s this concept, two inconvenient truths about product. When I read it actually is very insightful. Can you tell us what these two inconvenient truths are?

Marty Cagan: I think the reason I use the term, the two inconvenient truths, because in most companies that aren’t very good, the biggest problem, the source of a lot of their problems, is really the product roadmap. From the engineering point of view, the roadmap is just these are the features they want us to build. The problem is we have decades of data now that show that most of the items on those roadmaps are not going to deliver any results. I mean, realistically between 10 and 20% of the things on a roadmap for most companies actually produce a return where they actually provide the benefit the company was hoping. 80%, 90%, whatever it is, wasted. So why is that? That’s what led to the two inconvenient truths.

The first inconvenient truth is that we know at least half the ideas on that roadmap is just never going to work. We just know that. Now, it might fail because the customers don’t want it. That happens a lot. Our CEO wants it, but our customers don’t want it. So that happens all the time. Another problem is that they do want it, but it’s so poorly designed, it’s too complicated. They can’t figure out how to use it. And sometimes, they never even get to see it because it turns out to be much harder to build than was originally anticipated. The two sprints turn into 20 sprints and eventually, people say, “Forget it. It’s not worth it”. So these are reasons why most of the items on the roadmap are not worth building.

And then the other inconvenient truth is, let’s say you have a good thing on the roadmap. Something that really is people really do want it. It turns out in order to get that to the point where it really makes money, it takes several iterations. Usually takes 3, 4, 5 iterations until it’s profitable. Basically, we say in product that it’s not so much about time to market, it’s about time to money. Time to actually delivering whatever the value is. And that usually takes several iterations. So if you just think about your typical company with quarterly roadmaps that they fight about at the beginning of every quarter and they have all these features and projects that they dump on the teams and say, “Build them.” Only a small percentage of those things actually might work. And then a small percentage of those get the several iterations they need to make money. So, this is what I mean by so many companies are so bad at product. They don’t understand those two inconvenient truths, that lead to most of the waste in a typical company.

Henry Suryawirawan: So you brought up an interesting point about product roadmaps. I think still many companies, if not most companies, are still doing product roadmaps either yearly, quarterly, or at least every sprint, there’s some kind of a, they call it product vision or product goal. What do they want? So if you are saying that the first inconvenient truth is that at least half of those products from the product roadmaps will be wasted, is there a better way how to execute this kind of a plan to build the products?

Marty Cagan: Oh, absolutely. And this is what good companies do is they know the difference. The truth is, a product roadmap does not have to be the disaster that it usually is. The key is this. When do you put an item on the roadmap? Do you put it on the item before you’ve done any product discovery or after? If you put it before, the problem is you don’t know. You just have these hopes that it’s going to make all this money, but you don’t know if it’s going to make any money, and you don’t know how much it’s going to cost to build.

On the other hand, if you do product discovery, and I haven’t really defined that, but in general, what that means is we have to make sure our solutions are valuable, usable, feasible, and viable. We do that with a lot of quick prototyping and quick testing. So that’s how we do that. Now, if you do that first for the ideas that work, you put those on the product roadmap, that’s fine. Then it’s just a communication tool.

[00:22:06] Traits of Good Product Teams

Henry Suryawirawan: And you mentioned also another aspect of the product, so called the product roadmap, you should not aspire to just build features on top of features. But you also should focus more on the outcome. People usually call this output versus outcome. So tell us more about that.

Marty Cagan: That’s right. That’s another difference. When we talk about good product teams, there’s really four things that matter. I’ve hinted a couple of them so far, but we should just get these on the table. Because the truth is, it doesn’t really matter what process the team is using. It doesn’t matter if they’re using Kanban, if they’re using Scrum. Really doesn’t matter. And as you probably know, a lot of the best team don’t use any of those. So it’s not important. What matters are these four things.

First of all, is the team given a problem to solve instead of a feature to build. We want to give the team problems to solve. They can be customer problems. They can be our company’s problems, but they’re problems to solve, not features to build.

Second is, are they addressing the risks, value, usability, feasibility, and viability before they have their engineers build something, or are they addressing that after or never? So that’s the second thing.

The third is how do they actually solve problems? If they think the way you solve a problem is somebody with a title product manager defines requirements, and gives it to a designer who’s supposed to do workflows, and who then gives it its sprint planning to the engineers. That’s waterfall. Even though I just said sprint planning, that is literally waterfall. So, instead, what we want is product management, product design, engineering to come up with that solution side by side collaboratively. In fact, this is the little secret in product. Consistently, the best single source of innovation is not our product managers, is not our customers, is not our executives, it’s the engineers. Because the engineers are working with the enabling technology every single day. They’re in the best position to see what’s just now possible. And so the point is great product ideas come from them. Let me just make this very explicit, Henry. If the first time the engineers or the tech lead even sees a product idea is at sprint planning, that is a bad product team. Okay. They should have seen the idea way before that. From the beginning of the idea. Anyway, that’s the third.

The fourth one is what you brought up. Outcomes. Good product teams measure themselves against outcomes, not output. In other words, good teams ship every day, multiple times a day with continuous deployment. What matters is not shipping a feature. What matters is achieving that outcome. Whatever that problem we were trying to solve. Did we solve it?

[00:24:53] Engineering Involvement

Henry Suryawirawan: So I think the point where you mentioned that engineering should be involved even earlier. They should not be involved only during sprint planning or maybe backlog grooming. That is probably too late. And you mentioned in the book that if your engineers are used just to produce code, they actually bring half a value. I think that’s a very insightful thought because all along, I think in many companies as well, engineers, maybe they also treat themselves like, “Oh, I just want to code. I don’t want to involve in this product discovery or product management.” But actually, the best companies would involve these technical people early in the process.

Marty Cagan: In fact, I mean, literally at the best companies, they consider the single most important thing, are engineers doing more than just coding. They refer to it as this notion of an empowered engineer. An engineer that cares just as much about what they build as how they build it. So that is a huge difference between good companies and the rest. In a lot of Silicon Valley, the way they talk about this is they’ll say, do you have teams of missionaries or teams of mercenaries? Mercenaries basically build whatever they’re told to. They don’t care. If you tell them to build the stupidest feature in the world, they will build the stupidest feature in the world. They don’t care. They don’t care. So they’re like, just pay me. I’m fine. And in fact, in a lot of those companies, they’re not even employees. They’re outsourced.

So, no. In a good company, they would never do that. In fact, when they interview for engineers, they’re trying to see that they’re not like that. That they really care about what they build. You know, in a good product team, in a good product company, the engineers don’t have to build what the product manager says. If they don’t agree, they don’t build it.

Henry Suryawirawan: Wow. So I think that’s very interesting finding. Engineers also have a say what to build or what not to build. I think that’s really key.

[00:26:44] Empowered

Henry Suryawirawan: So you mentioned these keywords about empowered. I think that’s the title of the second book. Empowered teams. What are some of these attributes of empowered teams? So maybe if you can explain what does the term mean? Because so many teams also they feel like they’re empowered. They can do whatever they want. That may be one interpretation of empowered. Yeah. But maybe there’s something else.

Marty Cagan: No, that’s a fair question because there are different interpretations. The most common concept that it’s confused with is another important concept, which is referred to as an autonomous team. So there’re autonomous teams and there are empowered teams and some teams are empowered and autonomous. But the difference is an empowered team is given a problem to solve. So they don’t get to pick what they work on. That’s a Fantasyland. Because imagine having all these different teams and all these different engineers, and they all pick whatever they want to work on. Nobody would get anything done for our customers.

So they don’t get to pick what to work on. But what an empowered team means is that they get to figure out the best way to solve that problem. So instead of being given a roadmap of features that say, we want you to put this payment method, we want you to do all this, they instead say, “Here’s the problem. You figure it out. Here’s the problem. You figure it out.” That is what’s meant by an empowered team. An autonomous team means you have everything in your team you need in order to make the changes you need to make. So if you need to build something that requires certain skillset, you have that skillset. Now, in truth, most good companies have empowered teams, but only partially autonomous. In other words, it’s very hard to have full autonomy in most companies, because there are so many interdependencies. There are all these platform teams that we depend on. And so, it’s not about full autonomy. It’s about maximizing autonomy.

[00:28:41] Ownership & Alignment

Henry Suryawirawan: So you brought up this keyword autonomy. I think there are two things covered in the book. It’s called the ownership and alignment. So I think not just the empowered team has the autonomous capability, but the people inside also having ownership and also alignment regarding the product that they want to build. So can you tell us more why these two attributes also are important in a product team?

Marty Cagan: Well, you’re getting at another topic that is a very big topic, and honestly, one of the most difficult at most companies. And this is referred to as the team topology topic. Actually, I got that term team topology. You might have noticed in “Inspired”, I didn’t use that term. I just referred to this concept by the way most companies did, which is how do you structure your product teams. So if you’ve got a hundred engineers, you’ve probably got between 10 and 20 product teams. How do you decide what each product team owns? How do you decide what they work on? That’s the team topology topic.

You may know that there’s a couple of DevOps engineers came up with this book called “Team Topology”. I knew one of them, and I reached out when I saw that book and I asked them where they got that name because I love it, but I’d never heard it before. They said they invented it and they tried it out at a conference talk, and people liked it, and I told them, well, I like it too. I’d like to use it in my book and I’ll just reference your book. So that’s what I did. Their book is a good book, “Team Topologies”. If you haven’t read it, you’d probably like it, but it talks a lot about this concept of how do you structure your product teams?

What you’re bringing up, this notion of alignment and ownership. There’re a lot of different ways to legitimately structure your product teams. There’re also a lot of bad ways to do it. You know it’s a bad way if all of your engineers complain that they can’t make any change without getting 10 other teams involved. It’s very demotivating. The opposite of autonomy. So it’s easy to spot a bad team topology. It’s much harder to say what’s a good one. Now, you can optimize team topologies for different things. In the book “Team Topologies”, they recommend optimizing for throughput, which is a good thing, right? Getting software shipped. You know, realize they’re coming from DevOps. So that is naturally what they’re going to care about, throughput.

In a product company, we do care about throughput, but we don’t care as much about throughput as we care about building great products. So it’s not only about throughput, it’s about value. It’s not a minor topic. It’s just more of, you can have these different levers that you can adjust when you are deciding the right topology for your team. When we tell people to optimize for empowerment rather than throughput, we tell them ownership is critical. You need teams to feel like this is their part of the code base. Anything to do with search, the search team owns. It’s theirs. Other teams might be able to change the code and do pull requests, but the engineers on search own it, are responsible for it. So that sense of ownership is very important.

And another thing that’s important is alignment. What that refers to is let’s say you’re dealing with Uber and you’ve got riders and you’ve got drivers. Well, if you have a product team that’s structured right around riders, they can get to know those riders. They can get to test with them. It’s much easier for them to be aligned with the business than if they were on a team that did some things for riders, some things for drivers, some things for Uber operations people. It’s just, it gets hard to know your customers deeply, and that’s what we need. So we say try to optimize for ownership and alignment. That’s sort of what we’re leading to with empowerment.

Henry Suryawirawan: Thanks for the elaborate answers. So I think ownership and alignment, I fully agree. And you mentioned about team topology. I had a chance to talk to one of the authors as well, Manuel Pais. I think it’s like episode 44. Long time back. So I think for people who haven’t checked it out, or haven’t heard about this term, I’ll make sure to put in the show notes. Maybe you can listen as well.

[00:33:00] Product Vision & Strategy

Henry Suryawirawan: So the other aspect of this empowered team, is the other notion where you call it strong product leadership. So I think moving to the product management side, right? You mentioned that product leadership has this concept of product vision and product strategy. Maybe if you can explain what do you mean by strong product leadership? And what are the characteristics of good product vision and strategy?

Marty Cagan: Sure. In the book “Empowered”, we explicitly define product leadership as the leaders of engineering, design, and product management. All three. So that’s what we’re talking about here. Now, obviously, engineering leadership cares about things like tech debt and architecture. Product management leadership cares about things like product vision and product strategy. Design leadership cares about their own set of things. Like, what is the holistic view of our product? What are the design language we’re going to use for this product? So all of the leaders have their parts, for sure.

You’re asking about product vision and product strategy. Product vision is basically what you’re trying to do over the next 3, 5, 10 years. What are you trying to do in terms of helping your customers have a better life, their company be better, but how does it help people. That’s what the product vision is about. It’s meant to be very inspiring. And in fact, if you go to a good product company, the number one recruiting tool is their product vision. They will bring you on so that you can help work on this important product vision.

Product strategy is a lot more tactical. Product strategy is what are we gonna do this quarter? So you asked earlier in our chat, you asked about what’s really the alternative to a product roadmap of a bunch of features? The alternative is a product strategy. Product strategy is what identifies those problems that need to be solved by the product teams. Those product strategies are not just whatever people are screaming for. It’s looking at the data. It’s looking at customer feedback and insights we’re getting. It’s looking at the enabling technology. It’s looking at industry trends. What product strategy is really about is getting the most out of your organization. So if you have a hundred engineers in your product company, a good product strategy can help that a hundred engineer organization do as much as 500 engineer organization. If that other 500 one doesn’t have a product strategy, and many of them don’t. So a product strategy is really gets you all about leverage. It’s about working smarter, not just more features.

[00:35:39] Focus

Henry Suryawirawan: I think you mentioned that if engineers are kind of like having a good product strategy, they’ll produce tremendous output. And I think the key also here is to focus, right? I think many companies just build features, but there are so many features spread across different areas. So I think you brought up a very good discussion in the book about focus. I would say it’s not just in product management, even people’s life, we tend to have this problem of focus. So maybe if you can explain a little bit about focus here.

Marty Cagan: Well, I mean, honestly, focus is the hardest part. Because the focus part is not just your engineering leaders and your product management leaders. It’s your CEO. And that’s usually who I have to talk to about focus. There’s a great quote from Steve Jobs which was “Focus is not saying no to the bad ideas. Focus is saying no to a hundred good ideas.” That’s what focus is, and that’s why it’s so hard.

Imagine you’re the CEO of a growing company, and you’re very worried about competition. You’re very worried about customers not being happy. You’re very worried about running out of money. You’re very worried about all of these things. So for your point of view is like, I want to do all these features because maybe one of them is really the thing we really need. That’s an understandable feeling. But we have to explain to the CEO that that actually hurts their chances of succeeding because not all ideas are equal. Not all focus areas are the same value to your company. So we need to focus on a small number of areas. And then, of course, the real work of product strategy gets going, which is we need to learn about what is the right thing to do in order to make a difference on that focus area.

So, for example, let’s say it’s a fairly young SaaS company and they’re growing okay, but their retention is bad, which is unfortunately very common. It’s like people try it, but they don’t really like it yet. It doesn’t really do what they need it to do. Now you can have a problem, which is fix retention. That’s a problem, but there can be a thousand ways to fix retention, to fix churn. And our product teams need to get to work and try to figure out what are the things that really matter. What will really make the difference?

Henry Suryawirawan: And I think also sometimes, in this example of yours, fix retention, but sometimes some product companies also do the other focus on the opposite area, which is like to also bring new users. So it’s like two focus. Yeah. So it’s like bringing new users and also fixing retention. Is there any comment?

Marty Cagan: It is a classic problem. They get ahead of themselves. Yeah. Normally in a product company, we talk about product market fit. And until you get product market fit, you are wasting most of your marketing money. And so, what companies do is they often start spending a lot of money on marketing before they have product market fit. So now they’re spending all their money to bring more customers, but the customers don’t like the product. That’s a bad business right there.

Henry Suryawirawan: So is there a strategy or tactic that you would advise people, how can they gather better focus so that they can actually focus on the things that matter and focus on building the right product?

Marty Cagan: Well, I mean, it’s not that it’s physically hard. You have to understand why focus is necessary. So a lot of times it’s just literally a conversation with the CEO and explaining what’s going on. Why they’re not getting much done even though everybody’s busy? And so you have to explain to them why focus is so important. I think everybody I know learns it sort of the hard way. They learn what happens if you don’t focus. So most product people are very big believers in focus. It’s so important for all of this. And then, of course, what we want to do is we want to spend our cycles getting a great solution to the problem that is really the most important problem.

[00:39:40] Coaching & Nurturing People

Henry Suryawirawan: Another aspect earlier that you mentioned is about recruitment or hiring. I think you covered this a lot in your “Empowered” book. How to find good people? How to actually nurture people? And also the aspects of leadership. Maybe you can tell us a little bit more about these people aspect. How do you find them? How do you nurture them and things like that?

Marty Cagan: Well, the biggest topic, and this is another one of those very big and obvious differences between great product companies and the rest is, this is the thing, nobody, even if you go to a great university, you don’t come out of it knowing how to be a great engineer. If you’re lucky, you learn some theory. But what you really learn is at the job. And the point is that nobody joins your company, nobody joins your product teams really with the skills they need. So it’s the manager’s job to coach them.

This is such a big difference. So, for example, at Apple, all of their managers, their technology managers have four big responsibilities, and one of them is coaching. At Microsoft, there are three big responsibilities for all their managers and one of them is coaching. At Google, they’ve been very good about this for many years, coaching. I know when I introduce somebody to work at Google, they will get coaching. But in so many companies, they join, there’s no coaching at all. Nothing. It’s like here start coding. We’ll have a code review on Friday or something like that. There’s no coaching. And so, this is a very big miss. I’m glad that more companies are being more vocal about how important it is for managers to provide coaching. And if you’re a first-level manager, a manager of individual contributors, your number one responsibility is coaching. And I’m not exaggerating here. Coaching and staffing is normally about 80% of their work week. So it’s coaching and staffing.

Henry Suryawirawan: So you emphasize really a lot about this coaching. I think it’s not just the manager of the ICs, but manager of the managers or manager of super managers.

Marty Cagan: Yeah. The higher you go, the less time you spend coaching, because these people are supposed to be more experienced by then. But the higher you go, the more you spend time on vision and product strategy.

[00:41:56] Hiring

Henry Suryawirawan: So, how about staffing? How do you find great people? You mentioned about ownership mentality, right? So maybe there’s other aspect.

Marty Cagan: Well, the biggest thing that I wanted to talk about in the book “Empowered” was I think there’s a really a big myth in the Silicon Valley culture. People think that Google hires people that nobody else could hire. I mean, we can’t hire those people. Only Google can hire those people. Meaning they’re like some kind of special alien human race or something, but it really isn’t true. The reason I know this, first of all, I’ve been working with people there for more than 20 years. Don’t get me wrong. They have their fair share of very good people. But what they’ve learned a long time ago was great product teams, they’re not made up of rock stars. They are made up of good people that get the coaching they need to succeed.

In fact, that’s where the subtitle of the book came from, “ordinary people, but extraordinary products”. The best teams I know, that’s what they have. In fact, Google shared a lot of their own research on this. It’s under something called project Aristotle, and it talks about what it takes to make a good product team. If you take the superstars from across the company and put them together, it generally doesn’t go very well. And we’ve all seen that. What you do much better is hire good people, for sure, but hire good people that people want to work with, that are not jerks, and coach them to be great people. And that, I think, is the scalable solution.

Henry Suryawirawan: So you mentioned this in the book that a good staffing strategy is to find people that you can trust. And trust is a function of competence and the character of the person. So it’s not just the rock stars that have a lot of competence, but it’s also the character. How they take ownership? How can they do stuff and learn on the go? I think that’s also part of it.

[00:43:49] How to Structure Teams

Henry Suryawirawan: So as we are going almost to the end of the conversation, you mentioned about team topologies and how to structure team. This is probably one of the hardest problem in any software product company. Maybe you can give us some tips on how should you structure the teams? Some of the principles or some of the common problems that you see from your consulting or from your experience in the industry.

Marty Cagan: I mean, this is a very difficult question. So just to be honest, I get that question at literally every single company I advise. I don’t think there’s ever been an exception. So it is a very real thing. But before I can answer it for that company, I have to ask them about a hundred questions. I have to ask them how many engineers do you have? How many designers do you have? How many product managers do you have? Tell me about your product. Tell me about your kinds of customers. How many different kinds of customers do you have? Do you have personas? I need to know what’s your technology stack? How different are those technologies? How are you on staffing against skill sets? And then I need to get into things like, tell me about your architecture. Because your architecture is the biggest factor on the dependencies.

And so, if you want teams like at Netflix and Amazon, they say, we want our product teams to be highly aligned, but loosely coupled. Highly aligned is not the hard part. The loosely coupled is the hard part. What that means is minimum dependencies between teams. So we need to understand the engineering side. We need to understand the design side. We need to understand the product side. We put all this together and then we say, all right, there’re several ways you could do this. Let’s look at the pros and cons of each. And so, I have never once given the same answer to more than one company. It’s always different because every company is different when you look at this level.

There are some trends which are good. Like, we love that there’s more platform teams now. We also love the architectural trends that enable more. Services oriented architectures enable us to do product teams that are more end-to-end, which is a nice benefit. So there are trends that help, but it’s true that every one of these companies is different. So what I do is I tell the Head of Engineering and the Head of Product that they have to work this out together. I encourage them to read the “Empowered” book on team topology. I encourage them to read the book called “Team Topologies” that you referenced, and then sit down and put together what you think is a reasonable approach. And then a lot of times, we’ll put that on a whiteboard and we’ll discuss the pros and cons of those. But it’s complicated. In truth, it’s complicated.

Henry Suryawirawan: It is indeed complicated. I mean, if you have worked in a startup before, or even in the big companies, sometimes they do restructure as well. Because something just doesn’t feel right, so they structure again, and things like that. And you brought up a good point about architecture, sometimes, or mostly drives a good team structure. I think this is what people refers as Conway’s Law, Mel Conway’s Law. You should probably also check it out if you haven’t heard about this Conway’s Law.

[00:46:55] 4 Tech Lead Wisdom

Henry Suryawirawan: So Marty, it’s been a pleasure. I learned so much about product management. How to build the right product, not just building the product. But unfortunately, we have to end this conversation. But before I let you go, normally I have one last question that I ask to all my guests, which is to share about this thing called three technical leadership wisdom. Something that you want to give advice to listeners here, maybe based on your experience, based on your expertise, and things like that.

Marty Cagan: Well, sure. I know you’re talking about technical leadership in general, but in particular on product teams, I love the tech lead role, the most senior engineer on a product team. And I spend a lot of time with those tech leads. They are the people often that make the difference on whether the company innovates or not. I normally share four things. So I don’t know, you could pick three from those four, but these are the four things I usually tell them.

One is that they need to care as much about what they build as they care about how they build it. We were talking about that before.

The second thing I tell them is get in front of real customers and watch them interact with your products. I mean, don’t let anybody tell you, “No”. You must get in front of real customers. It’s one of the most powerful things a tech lead can do.

And then third, as the tech lead, they are always supposed to be asking themselves, is there something that is possible today that wasn’t possible yesterday? Because as you know, the technologies are changing constantly. Is there something that’s possible today that helps us solve a problem we’ve wanted to solve for a long time, but we really didn’t know how? So this is where innovation comes from. Something that’s just now possible.

And then the fourth thing I always tell them is process is never what’s important. Because a lot of engineers get caught up in worrying about process. They easily start forgetting what’s important. It’s not important. The people on your team is important and the product you’re building is important. Your process is really not.

Henry Suryawirawan: Wow. I love the last one. I’ll make sure to put all these four, by the way. So I love the fourth one. Sometimes yeah, people we tend to try to standardize or come up with a good process, optimize the process, standard operating procedures, and things like that. But I think yeah, at the end, people and the product that you build actually matter more than perfecting the process.

So Marty, if people want to continue this conversation or find out more about your books, your resources, or blogs, training and all that, is there a place where they can find you online?

Marty Cagan: Sure. It’s SVPG.com, Silicon Valley Product Group.com.

Henry Suryawirawan: Thank you so much for spending your time, Marty. It’s been a pleasure. Looking forward to have more people learning about product management and how to build products that matter.

Marty Cagan: Well, thanks very much, Henry. I enjoyed our conversation.

– End –