Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Paul [00:00:28] Hey Sean, that was amazing. That was drinking from a firehose.

Sean [00:00:32] I can’t wait to talk about it.

Paul [00:00:34] So Marty Kagan is one of the founding fathers of the Internet. He’s been around since Netscape, eBay… What are we going to hear when we talk to him in a minute?

Sean [00:00:44] Yeah, I’ve heard of him actually recognized as the primary thought leader in technology product management. And, you know, he delivered.

Paul [00:00:51] Hands down. I learned about product teams versus feature teams, I learned about being autonomous, being gritty as a product manager. I think the hiring process needs some work in the industry, and we touched on all of it. It’s an amazing conversation.

Sean [00:01:07] We talked about what makes a great product leader. We talked about titles, product owners versus product managers. We talked about everything that’s salient to this field. So there’s a lot to learn in this podcast. I hope you guys get as much out of it as we did.

Paul [00:01:20] Here we go.

Paul [00:01:24] Hello, everybody. We are honored to be joined today by Marty Cagan. Before founding Silicon Valley Product Group to pursue his interests in helping others create successful products, he had an elaborate and illustrious career. Marty served as an executive possible for building products with some of the most successful companies in the world, including Hewlett Packard, Netscape, eBay. During his career, Marty has personally performed and managed most of the roles a modern software product organization conducts, including product management, software development, product marketing, UX design, and a host of other activities. Marty, welcome to the pod. We’re really excited to have you today.

Marty [00:02:01] Thanks very much.

Paul [00:02:02] So what’s on your mind lately? I’ve been following your writing for years and your blog has been peppered with team dynamics and product dynamics. And I’m just curious, what’s on your mind lately as the biggest challenges that product teams are facing today?

Marty [00:02:18] Well, I’d probably say that a couple of years ago I published a new edition of Inspired, it was actually a complete rewrite of a book I had published 10 years before, also called Inspired, but version two was… I wrote it completely again because so many of the techniques have gotten better, you know, a lot has changed in 10 years. And I was pretty surprised at how many people, because I’ve always felt that what we do in the product world is pretty specialized, but anyway, a lot of people seemed to read it and like it, which is nice. One of the things though that it did was it sort of dragged me outside of the little bubble I was living in, sort of the Silicon Valley bubble. And what I realized was that outside of, sort of the best tech product companies, in more the real world, and that’s just not a physical geographical thing, honestly there’s plenty of companies right in the middle of San Francisco that are terrible at product. So don’t get me wrong, it’s all over the world. But anyway, I’d say that book kind of pulled me outside of that window and I realized that, while the people seemed to really like the book and they seemed to understand it, the most common problem I would hear was that people would say, “well, we want to work like this, but we’re not allowed to work like this.” Which, of course, coming from my world, that was like, “that’s crazy, what do you mean you’re not allowed,” and, you know, “let me talk to these CEOs and see what is going on.” And anyway, it sort of led me on this journey and I realized that there are some pretty fundamental differences between how the best companies think about product and how the rest think about product.

Paul [00:04:04] If I could overgeneralize it, I think in the way you describe it in either the forward or the preface is, the first edition focused on the startup model and getting to product-market fit and finding that lean product model, and then in the second edition you go to Agile at scale and start talking to, how do you do this thing where the product exists in the platforms or in maintenance mode and you’re iterating and you’re trying to evolve these team dynamics within the product space. Is that fair?

Marty [00:04:33] Well, that’s true. That was a big change in the second edition. I didn’t want to just talk about startups, I wanted to talk about the growth stage a lot. However, that’s orthogonal to this; what I found was that those companies of all sizes, they realized they could pretty straightforwardly learn how to do product well. The issue is being allowed to work that way and that issue is across all sizes. It’s true that most enterprises are terrible. We know that. That’s not a big insight, but it’s across all sizes. And so what I started diving into, and really, I started talking to a lot more of these CEOs about like, “you know you shouldn’t be working like this, you know this is not how Google works, and Apple, and Amazon, you know that. So why don’t you let your teams work the way they’re supposed to?” And that sort of led me on this journey, which actually led to another book. I’m right in the middle of writing another book. The first one, Inspired, was about how product teams actually do product work, but this is about how organizations need to set up in order to let their teams do real product work. It’s called Empowered, and that really is the heart of it. In these good product companies, they are, like Steve Jobs used to say, “we don’t hire these smart people to tell them what to do. We hire them so they can show us what’s possible.” And so that’s what I’m really talking about, is trying to share with those companies that are not set up the way good product companies are, why and how they really need to revisit this whole topic of leadership and product teams and innovation and really consider that there might be some pretty fundamental reasons these leading companies work differently than they do.

Paul [00:06:21] It’s a great observation. It sounds like my life every day.

Sean [00:06:24] Well, that leads us to a topic that you’ve been pretty hot on lately about product team organization and this concept of feature teams, which we are very familiar with, versus product teams. So why don’t you talk about that a little bit and what you found?

Marty [00:06:40] Yeah. Well, what I found, in general, was that it’s muddied. In fact, if you really want an exercise in futility, just go online and try to figure out what a product manager’s supposed to do. You know, there’s like a hundred different definitions out there, most of which are, you know, when I look at it, I’m going like, “this is crazy, where did these people come up with this stuff?” Then, of course, what I realized was that what’s really going on is that no matter what kind of company it is, if they’re doing technology-based stuff, they call them product teams. But really, there’s three kinds of product teams out there and the differences are not minor. They’re just obscured because they’re all called product teams. There is this whole category of people who are really not product teams at all, they’re delivery teams. I don’t know if you guys even come across, but there’s some processes out there like SAFe that are just the opposite of what a good company would do, in every respect. They’re just ridiculous. In those teams, there’s a product owner that is managing a backlog and there’s a bunch of engineers that are there to code. And that’s not a product team in the sense that we talk about. It’s not, you know, Spotify calls them squads. Yes, technically, there’s a few different kinds of people on there, but they’re a completely different purpose. They are there in the software factory model. And honestly, that’s not my world, so I just sort of put them off to the side, even though that’s probably the biggest subset of the three. But, oh well, that’s for them to stress about.

Marty [00:08:11] The other two categories are trickier because they look a lot closer. That’s what I call feature teams and product teams. When I say product teams, truly empowered product teams. Feature teams and product teams, they are very much in the Spotify model of a squad. There’s somebody usually with a title product manager. There’s somebody with the title designer and there’s some number of engineers covering the range of skills that are needed on the team. So they’re cross-functional, but it turns out there’s a really fundamental difference between feature teams and empowered product teams. The feature teams are basically given a roadmap to build. So it might come from the executives, it might come from stakeholders; it comes from somewhere and there’s some prioritized list of features and projects to build. And they are there basically to build, which, if you drill down, really means two things. First, they have to design that feature. And usually, that’s a little interaction design, a little visual design, maybe a little usability testing to make sure it doesn’t confuse people, and then they build it. Now that’s the vast majority of what companies in the tech space are doing. They’re doing a little bit of design and then going to coding. Now, a lot of those companies will call what they do product discovery, but it’s really not product discovery in any sense, because in discovery we’re trying to separate the good ideas from the bad. In that model, they’re just building out those ideas. So design is not discovery. Design is part of discovery, but only if you’re deciding, you know, that maybe half these ideas are worth building and the other half are not. So, in a feature team, they are there basically to deliver these features and projects, a little design, and then lots of coding.

Marty [00:09:57] Now in an unempowered product team, you have a product manager, designer, and engineers, so it looks a lot alike. The difference is, they are given a much harder problem: in an empowered product team, they’re being asked not to build this feature, they’re being asked to solve this problem. So that problem might be, our churn rate is too high, it could be that we can’t sell a product in this part of the world, it could be that we don’t have product-market fit yet. But these are problems. They might be customer problems or business problems, but they’re hard problems. And an empowered product team is set up to actually solve those problems. That means that they have to have the skills on the team to really do that. The big difference is in that product manager because in a feature team, almost everybody calls them product managers, but they’re really not product managers. They’re project managers. They’re herding the cats through design and engineering to get that feature delivered. And don’t get me wrong, that’s non-trivial and it’s important, but it’s not product management.

Marty [00:11:01] In an empowered product team, it is much more like a startup in the sense that, in a startup, the main thing the founders, you know, CEO, founder, the main thing that person is responsible for is actually two things: making sure whatever you build is actually something people want to buy, or want to use, valuable, and making sure that whatever you come up with can sustain a business. That’s what we mean by viable. In an empowered product team, the team has to figure that out. You’re not given a list of features to do where you hope that maybe one of those stakeholders knew it was gonna be valuable, knew it was gonna be viable. We just know that nobody can know that, and really, it’s about how fast you can figure that out. So even though it looks alike, a feature team and a product team, the responsibilities are way different and the level of demand on that product manager job is very different. That’s the root cause, in my opinion, of most of the confusion out there about product.

Sean [00:12:03] Interesting. So what is the problem that that solves?

Marty [00:12:07] Well, the problem an empowered product team solves is you now have teams set up to solve hard problems, whether you’re talking the iPhone, trying to figure out how to enter text on a touchscreen device, nobody’d ever done that before, you’re talking about Netflix trying to figure out a way not to lose money on rentals, or whether you’re talking about Amazon trying to figure out how to do voice control devices… These are hard problems to solve and these companies have set up to allow their teams to solve those problems.

Sean [00:12:37] You get better and more innovation because your team is empowered. And like you said, before with the Steve Jobs quote, you hired them to come up with creative solutions. And they’re smart people. That’s what they think about. That’s brilliant.

Marty [00:12:49] Yeah, some people, you know, when they hear the word innovation, they think it’s got to be an iPhone or it’s not innovation. I mean consistently adding value for our customers and our company, and that takes hard work. That’s what’s hard. That is not what most teams do. So, yes, it’s innovation. It’s solving hard problems for our customers, for our business.

Sean [00:13:11] All right. So if I could paraphrase your definition of innovation for you, try to anyway, it’s the consistent addition of value through the product.

Marty [00:13:20] Yes.

Sean [00:13:21] For the users. I love it.

Marty [00:13:21] For users and for the business. We care both.

Sean [00:13:24] From the mouth of Marty Cagan.

Paul [00:13:27] I want to ask a bit of a nuanced question because what I deal with, you know, as product managers in an agency, we have clients and we’re almost chameleons in the way that we work. We conform to the processes and team dynamics of the people that we’re helping. And I think one of the things that I’ve found is we can assume a product manager mindset even if we are on a delivery team. And I think that there is a challenge to that. If you’re handed a roadmap and said go build it, it’s difficult to create innovation in that laboratory. But I’m drawn to a list that you included in your book, it’s this top 10 of, how do you spread the word? How do you inspire people? And I think you can assume a product manager mindset even if you are a project manager in any other sense of the term. And you go through a couple of things, like inspiring demos and spending time with your team, and I think that some of the things that I was reminded of is the way that I work is oftentimes a product owner, project manager mindset, but you can elevate even if the process constrains you. Is that a paradox? Can you do that regardless of the kind of corporation or team that you’re on?

Marty [00:14:37] Well, I would separate two things because you’re really conflating two important things. One is, is it useful to help motivate the team? Absolutely. In any context that’s useful. I’ve seen that done by engineers stepping up, I’ve seen designers step up, I’ve seen project managers step up. And you’re observing that, isn’t that helpful? Absolutely. I wouldn’t confuse that with the role of a product manager, which absolutely should be doing the stuff that you described, especially if nobody else is. But their day job, if you will, is much more than that. They have to actually go figure out something worth building. So they have a bigger responsibility on an empowered product team.

Marty [00:15:24] You know, I actually have lots of friends who work at agencies, and, you know, you inherit all the difficulties and challenges of your clients. And so I have a tremendous amount of empathy for my friends that work at agencies. And, you know, a lot of them have used the funds from their agency to build product companies because they got tired after a while of, you know, because they know often very quickly that what their client is asking them to do is not really going to help their client. They know that. But sometimes their clients trust them enough that they can sit down over dinner and say, “you know, I really think we could be doing better for you here.” And as you probably know, there are some agencies that have really tried to do that, and I think that’s great. But it does take a level of trust with your client. Most of the clients I know, they’re like, “Hey, you don’t want to do it? I’ve got 50 others that want to do it.” Or they’ll say, like, “I’ll just go hire Accenture; they’ll do anything.”

Paul [00:16:24] Right. Trust is key.

Marty [00:16:26] Yeah. It has to have that trust. So it’s hard, from the agency perspective, to do it. Can you contribute real value in other ways? No question. The fundamental issue is, you’re trying to make them successful with what they’re trying to do. That requires a lot more empowerment. They need to not just hire you, but empower you. You know, that’s unusual with agencies.

Sean [00:16:54] The struggle for us is, especially the position we are trying to be in, is that we have to add so much value that they’re actually becoming a better software development organization as a result of working with us. Like, it’s a true partnership where they’re learning, we’re learning, we’re growing these things together. You know, ultimately it’s their product, not ours.

Marty [00:17:11] Right.

Sean [00:17:12] It’s a difficult thing to achieve, but that’s what we try to do every day.

Paul [00:17:16] So I want to pull on one other aspect of that, because you spend quite a bit of time, in the second edition of Inspired, you talk about what it takes to be a product manager, and it is hip, it is the aspirational career path. It is becoming more and more mainstream as opposed to 10 years ago where it was sort of on the fringes, and as you mentioned, it’s tough to find even a consistent definition still. I feel like I’m speaking for the up-and-coming product managers. I’m their voice on this podcast. So somebody is getting into the field and they’re just starting out. What is the required skill set or expectations that you feel like a new up-and-coming product manager should be preparing for as they’re entering the field?

Marty [00:17:56] Well, one of the things that’s a little different about product management versus design, versus engineering, is there really isn’t an academic program. I could say, like, “oh, go sign up at Stanford for this major,” you know, maybe the d.school is the closest thing, but that’s super hard to get into anyway. There’s just really not much in terms of academics. And the truth is if you look, I mean, I’ve been hiring and coaching product managers for, I mean, nearly 40 years now, and they come from every walk of life, every education, or even non-education. One of the things I’ve learned is it’s much more about, you know, how they think about solving problems and coming at it with a different perspective and it’s just a different set of things we’re looking for. I find it much more straightforward when I’m recruiting engineers or recruiting designers, you know, it’s more of a standard playbook we’re looking for.

Marty [00:18:56] But for product managers, you’re really trying to get inside their heads. Now, that said, there are some great things I look for. I want to make sure that, I talk to people all the time that tell me they want to go into a career in product management. They’re still in college. What should they make sure they take? And I’m like, take a course in a programing language, absolutely. If you haven’t done that, do it now. Also, take it finance or business class. Some general accounting works, financial accounting works, but something so that you can start to understand the language of business. That’s really valuable. I’m like, take a statistics course, you’re going to deal with a lot of data, get comfortable with the data analytics side. So there is a little, you know, some academic foundation, but for the most part, it’s going to be a lot more about how you think and how you behave and those are the things that we’re really looking for when we are interviewing product managers in a good company. I know there isn’t really a politically correct way to say this, but we’re looking for smart people. They have to make a lot of decisions, use a lot of judgment, and so we’re looking for people that are not afraid to learn new things, that are learning new technologies every day, that are looking for what’s just now possible. We’re also looking for people that, you know, realize that it’s a team sport. And I’m not just, again, trying to be politically correct. Really, the way we solve problems is through collaboration. You have to be able to work with a designer, with engineers, with executives to come up with a solution that works. And that requires a certain level of EQ and so we’re definitely interviewing for that. Is this person the kind of person that will approach things with an open mind, won’t be arrogant, will really earn the respect of others around the company and the team? And then there’s another dimension that we usually interview for too, which is just this grit or persistence because product is always so hard, it’s just never easy. There are always all these legitimate reasons not to be able to deliver something or ship something. And so good product people need to be the type that just gets over or around everything.

Paul [00:21:12] So I want to jump in with one in-the-weeds, tactical question for hiring managers who are looking for product managers, on the other side of the table. What are one or two questions that you rely on in interviews to find these somewhat intangible attributes like grit?

Marty [00:21:27] Yeah. And I’ve shared some of my favorite interview questions too. At this point, I’ve given away so many of them, a lot of people already know what I’m going to ask them. But, you know, fundamentally, we are trying to understand how people think about these things. I love to ask people about other situations where they’ve had to solve problems like this, and what were the obstacles? How did they overcome them? As long as you’re willing to be comfortable with some silence and let the person struggle for a while before they come up with something, you can usually figure out, have they really struggled with these kinds of challenges before? And if so, how did they really deal with them and what did they learn from that experience? Of course, if they’re a university hire, they’ve never done this, you’re making a bet on their potential. And so in a way, I find that much harder because there is really no track record usually, you know, they can talk about some school projects. But as you know, that’s not even close. So, if they’ve been working for a few years, though, there should be plenty of good things to talk about that are very enlightening to me on how they think about problems, how they handle stress, how they handle difficult executives. And you just need to get that out on the table.

Sean [00:22:44] All right. I’m going to go and step back a little bit, go back to this concept of innovation. So we know that the best products don’t exist yet. We’re still in the process of learning in every field, and every product space, right. And the job of the organization and the product team is to come up with that to fill that empty space. To come up with that idea, or those ideas, that are gonna make the best possible product. So where do we get ideas? I just want to get your thoughts on that because, you know, a good product manager will have an idea every now and then, but the best product managers, in my opinion, figure out other sources of ideas.

Marty [00:23:19] Yeah.

Sean [00:23:19] What what are your thoughts on that?

Marty [00:23:20] First of all, ideas come from everywhere. If I have to pick one thing to focus on with companies that aren’t very good at product, if I have to pick one battle to fight, the one I usually pick is that I try to tell them, the best single source of innovation is the engineers. In most companies, the engineers are not even invited to the party. You know, they’re never in the room when they come up with roadmaps or anything like that. So I try to get them to rethink the role of engineers. And I’ve got, I don’t even know, I’ve never added them up, but I’ve got dozens of great examples of great products that everybody knows. And I tell them, “yeah, I know, you love that product, right? Well, that came from one of the engineers, and here’s what happened.” And it’s so consistent that in these great companies, the ideas come from engineers. But in the rest of the companies, the ideas are coming from stakeholders, they’re coming from customers dangling a big check, they’re coming from clients, they’re coming from your executives, and no surprise to me. And I try to help them understand the reason that’s the case. And fundamentally, the engineers have a big advantage, which is they’re working with the enabling technology every day. So that puts them in the best position to see what’s just now possible. And the problem with our customers, the problem with our executives, our stakeholders is, fundamentally, they don’t know what’s possible. So they can only imagine what they can imagine. And it’s much more constrained than the reality and that’s why it’s fundamentally different. So that’s sort of the one thing I try to get them to focus on. And also, I have shared this before, but, the fastest way I have ever found to tell in a heartbeat whether or not a company is a feature team or a product team is to talk to any one of the engineers on the team. Because in a product team, they are all in, they know this stuff. They know the business context. They know the customer problem. But in a feature team, they’re there, “just tell me what to build.”

Paul [00:25:25] So I do want to share one anecdote. I did a design sprint where we did have many designers in the room and only one engineer. And it was a data-dense, workflow-rich dashboard with charts and graphs and we were trying to get to a workflow where we need to solve this creative problem to show data in a different way. And the designers were coming up with convoluted, nested, branching filters. And the architect, the engineer in the room, said, “well why don’t we just try putting human-readable text in a field and searching for it and getting to the thing they want?” And the designers all went, “you can do that?” And it was an a-ha moment, but it happens all the time. Those anecdotes are a dime a dozen, and it does surprise me. Jared Spool has a quote that I’ve used before, but I’ll use it again, he said, “it’s a widely believed myth that developers are only valuable when they’re coding.”.

Marty [00:26:18] Yeah.

Paul [00:26:18] Get them into the discovery phase, get them upfront, get them into user discussions.

Marty [00:26:23] Well no question. I tell teams if you’re just using your developers to code, you’re only getting about half their value. So, it’s again, one of those black and white differences between good companies and the rest is the way they think of engineers. In fact, in so many companies I meet, and we’re talking not the good ones here, their engineers, they’re not even employees. They’re outsourced. They’re using Accenture for this stuff. And I’m like, “what do you expect?”.

Sean [00:26:51] Right. In the B2B world, because we build a lot of B2B software, I’ve found it’s super-valuable too to get people that talk to lots and lots of customers on an everyday basis: your customer service people, your salespeople, your marketing people, get them in a room and bounce some of these questions off of them and see what kind of things they can come up with. We’ve found that to be extremely valuable too.

Marty [00:27:11] Yeah, there’s no question that there are great sources, but this is where there’s a difference. There are sources of opportunities, of problems to solve.

Sean [00:27:21] Right, ideas.

Marty [00:27:22] And there are sources of good solutions. Both of them are ideas, right? Ideas of what we should work on and ideas of the best way to solve it. And in most companies, the problem is not, we don’t know what problems are out there. Most companies know what problems are out there. The problem is, in most companies, they have no idea how to really solve those in a good way. They basically have none of that discovery capability. And that’s where engineers and real designers come into play.

Sean [00:27:51] Sure.

Paul [00:27:52] Just to keep the ball rolling, I wanted to get your thoughts, so I do have another selfish question. When working in product teams, but on platform products, so you’ve got an ecosystem of products that are dependent on one another, what risks and what risk management strategies can you undertake where you can’t just build something and release it because it’s got a component that relies on 10 other teams that are using the same thing? When you get to scale, there are challenges that are unique where you can’t just let a team run and solve the problem on their own. There are dependencies and there are ecosystems. How do you develop this product team ethos versus delivery team ethos without creating more collisions and cleanup work after the fact than it is worth? Can you be truly agile and truly product-minded and be at scale in these enterprise platforms?

Marty [00:28:48] Well, this is going to take a few minutes because you actually had several big topics embedded in that. One topic, you started by framing it around platform teams, but then you went into a much more general problem, which was, what if one team, you know, is not, the word I think that a lot of people use for this is an autonomous team. In other words, they are in control of everything they need in order to make whatever change they want to. Now, at any company at scale that I have ever seen in my entire life, they are never fully autonomous. So every single company, and this is especially true the bigger you get, there are lots of dependencies always. So that’s the reality. Now, that’s not really much of a problem either. It can be a pain because of the dependencies, but it’s not much of a problem.

Marty [00:29:38] The third big element in your scenario there that probably causes the most grief is architecture. Really, the way it’s often framed is tech debt. In other words, in a modern architecture, each team can release independently every day. And that’s normal, in fact, in good companies, that’s not like a pipe dream. That’s not idealism. That is normal. Each team can release and that’s a really important principle. Now, that’s an architectural aspect. But if you’ve got some old financial services company that’s 30 years old and they’ve got this massive monolith and they tell you, “we can’t release anything without everybody releasing everything,” then that’s an architectural manifestation of that monolith, which definitely slows everything down. It also makes it so that any one team can end up breaking everybody else. So architecture is a very major component of the whole equation. And, you know, a lot of companies have so much tech debt that they’re basically, I mean, some of them go out of business because of this. This is a very serious issue. Now, it normally takes about one to two years to get your architecture to the modern foundation so that you can work the way you need to. So it’s not an instant thing. But whenever I run into the situation where we’re talking about you can’t release, that is like fundamental. Similarly, in those organizations, they’re not getting any of the benefits of even the most basic agile principles if they’re not able to release, each team, no less than every two weeks. And sometimes in the kind of companies you’re implying, they might say they release every three months, or every month, maybe. They’re not getting any of the benefits of agile. That’s just ritual at this point. There’s no benefits. So they have some work to do in those cases, in order to kind of get to modern, even remotely modern, practices. So being able to release frequently, being able to release independently, being able to regression test, I mean, release with confidence. These kinds of things are the foundation. Without those things, you’ve got pretty high-order problems to deal with there.

Paul [00:31:58] Yeah, that’s a masterful answer of a convoluted question. I appreciate you going through that.

Marty [00:32:02] The other part you did mention is platform teams. I love platform teams. And these are when, you know, if you look at a lot of the best companies, almost half their engineering capacity is on platform, which is really infrastructure leverage. It’s all about, you know, re-use and so that teams are much more efficient and they can focus innovation on the customer level, not reinventing the wheel. So that’s a different thing. It’s also very valuable. In those companies, platform is often staffed with their best people because it’s the hardest and highest leverage and there are special techniques for discovery just for that world. Anyway, there’s a lot to it. That’s not a minor topic.

Sean [00:32:42] All right, I got a simple question for you.
Marty [00:32:45] All right.

Sean [00:32:46] Domain knowledge. How important, or how much of an impediment, do you think it can be for a product owner? And I know every product is different so there’s no clear answer, but how important is domain knowledge in the context of building a great product?

Marty [00:33:00] Well first off, I would separate, because you’ve mentioned product owner a few times, if it’s a product owner and not a product manager, it really doesn’t matter.

Sean [00:33:09] OK.

Marty [00:33:10] So product owner is not really an interesting role to me, that’s just a backlog administrator. The product manager, of course, has to have pretty deep knowledge of the business and that’s where domain knowledge becomes relevant. Now, I still never recommend hiring for domain knowledge because it turns out it’s a lot easier to teach somebody who knows product a new domain than it is to teach somebody who knows the domain all about product. Now, there are some cases, like I was with a company doing a surgical device recently. The product manager is not expected to be a surgeon, right. However, in companies like that, they always have some true domain expert, which is a resource to the team. In this case, it was a surgeon, not just any surgeon, a pretty famous surgeon. And the idea was all the product teams have access to that person. So that’s not an excuse for the product manager to not understand the business and the constraints, compliance, privacy, all the things that is needed in a medical context. But they’re not expected to be a surgeon, just like at Intuit, they’re not expected to be tax experts. They’re expected to know enough about taxation to know that there is local and state and federal taxes and to know who to talk to in the tax team to get your question answered. But I think domain knowledge is way overrated. And also, it’s dangerous because a lot of those people that come from the domain, they think they don’t need to talk to customers. So all things considered, that is way down on my list.

Sean [00:34:48] Got it. I think there’s a lot of baggage around the titles product owner, product manager. People define them differently. I think it creates more confusion.

Marty [00:34:56] Well, it has. I mean, there’s been a real problem in our industry because a lot of people think that to be a product owner, all you have to do is take a certified scrum product owner class and they’re a product owner. Which they are a product owner, but they’re nowhere near a product manager. So I try to be more explicit now. And I want to know because, in a lot of organizations, they literally are just a product owner. That’s it. But if they’re trying to play the role of a product manager, then we need to know if they’re just a product owner or if they’re really a product manager.

Paul [00:35:30] Great stuff. I want to ask a question about baggage in terminology. Our industry is filled with jargon. MVP is a term that comes up all the time and it’s often sought after in your neck of the woods a what VCs go after for where you’ve got a product, you need to find product-market fit, you need to get it to the market. And MVP is sought after as this product. And one of the things you called out is that P is paradoxically not really a product, you have a prototype. At the end of an MVP, you don’t have a product, ironically. So is there a better way of thinking of MVP? Is it still a useful term in our industry? How can we think about this differently, or should we?

Marty [00:36:11] Well, in my opinion, it’s an extremely important concept, but it’s got an unfortunate name and people get very confused about it. Honestly, I haven’t had to deal with this as a problem for years because I just say, look, just call it a prototype and don’t worry about it. Then there’s no confusion because MVPs are prototypes and it also helps people understand there’s many kinds of prototypes, but let’s not confuse prototypes with products. So it’s an important concept, but if you just frame it as prototypes is what we do to figure out the solution we need to build and products are what we ship to customers, the world is a lot cleaner, and to be honest, salespeople, CEOs, customers, everybody’s a lot more comfortable.

Paul [00:37:01] Cut right to the quick. I love that. I’m definitely going to use that going forward.

Sean [00:37:05] All right, so I just recently read Bruce McCarthy’s book. I think the title is Product Roadmaps Relaunched. There’s a quote that he pulled from you in there and I just want to give you an opportunity to comment on it: “at least 90 percent of road maps that you see are squarely in the bad category.” I just want to get your personal opinion on road maps, and what is bad about them and how they’re being used in today’s product leadership market.

Marty [00:37:27] And just for the record, they didn’t talk to me about it and I didn’t review it. I haven’t read the book yet myself. But if they were going to use that quote, then clearly they probably agree that that’s a problem.

Sean [00:37:37] Oh yeah.

Marty [00:37:28] My understanding of the book is to make an argument for outcome-based road maps, which would be good.

Sean [00:37:43] Yep.

Marty [00:37:44] But when I say in the bad category, literally, when you look at them, they’re just a prioritized list of features and projects. And there’s a lot of things that are bad about that. One is that it’s all output, not outcome. And we’ve learned a long, long time ago, decades ago, that it’s easy to ship features, it’s hard to solve problems. So just because we ship a feature that was requested or even demanded doesn’t mean that it actually solved the underlying problem. And the second big thing that’s a problem is when you make a roadmap of features and projects, it’s usually anywhere from a month to a year out in the future. And so you’re locking yourselves into a bunch of commitments, most of which will probably not work. Empirically, it’s usually somewhere between half the items on your roadmap and 90 percent of the items on your roadmap, you will regret at the end of the year because they don’t actually do what you had hoped it would do. So roadmaps cause all kinds of problems. If they were just a list of ideas, it’d be harmless, but it’s never that. And the reason it’s never that is because the company wants to know when things are going to happen. I understand that. We have much better ways of doing that, but roadmaps have been around forever because they go with feature teams and they go with command and control. So I don’t expect those to disappear anytime soon.

Paul [00:39:08] I have learned so much just from talking to you. We’re coming up on the end of our time together. Having learned so much, I just wanted to ask, if I could, for one more piece of advice, something we ask of all our guests. If you’re talking to a product manager or a product leader in the industry, what’s a book that comes to mind? Obviously Inspired and soon to be Empowered, besides those, what’s a book that comes to mind that you’d recommend to somebody who is looking to learn and get better in our field?

Marty [00:39:35] Well, I think there’s a lot of good resources. My favorites, probably Ben Horowitz’s two books: The Hard Thing About Hard Things and the most recent one is about culture. It’s about, What You Do Is What [Who] You Are, something like that. I can ever remember the right title, but it’s a great book. And of course, his books are only for the kind of product people we’re talking about here, empowered product [people]. It would be nonsense for a feature team because he really makes the argument these are very much future leaders of the company. But those books are outstanding and he’s brilliant on this stuff. I usually start people there, but there are lots of good books out there for, you know, helping with the design side, helping on the engineering side, on the data side. You know, there’s a lot of good resources today. I think the harder problem is, for most people, they don’t have a way to know, what are the things that make sense and are good for them and what are the things that are not. That’s what’s hard.

Paul [00:40:37] Amazing. Sage advice. Marty, thank you so much for spending some time with us today. We really appreciate the time you took and this conversation has been a blast.

Marty [00:40:45] No worries. Hope it was useful.

Paul [00:40:47] Definitely was.

Marty [00:40:48] All right.

Sean [00:40:49] Thanks for joining us.

Marty [00:40:51] Thank you. Take care.

Paul [00:40:55] Well that’s it for today. In line with their goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or reading wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch and inspire the world just like you’re doing. Thanks, everyone. We’ll see you next episode.