Transcription
If a company, no matter where they are in the world, says, "No, we know that we have to do better than we do today," then the question becomes, "All right, there are lots of different ways of building products—thousands of ways of building products. What's the way that the best companies most consistently use?"
Hi, Pav, and here in this interview, Akas Gupta and I interview Marty Kagan, a legendary product leader, founder of Silicon Valley Product Group, and author of "Inspired" and "Empowered." In his new book, "Transformed," Mart explains how to transition to the product operating model—the model in which the best product organizations work. We hope you will enjoy the interview as much as we did. Let's get into it right now.
All right, this is super exciting! Everybody here with Pavell and Marty Kagan. We were just discussing off-air that when I started product management in 2008, I purchased the first edition of "Inspired," and I actually have now two copies of "Inspired" because this is the second edition. So, Marty has played a very formative role in my product career, and I'm curious—Pavell, I'm sure you have a very similar story.
That's the first edition.
Yeah, I have a very similar story because after reading "Inspired," I got interested in product management seriously, and I started reading more and writing content. So, this was transformative for me.
Yeah, I think every product manager probably has a similar tale. So, thank you for what you've done for the product career.
Oh, well, yeah. I mean, I remember when I started. I mean, I started product a long time ago—literally in the 1980s. So, it's a long time ago, but there weren't really any books. I mean, good or bad, there weren't really any books. There were some books from the old, what we call product marketing, but there wasn't on product management.
I remember the person who was coaching me saying, "You know, there's no books on this. The tech industry is not that big. There aren't that many of us that do this. The main way you learn it is from other people that have done it, learned it before."
And so, I realized, of course, after I left the bubble of Silicon Valley and kind of went to more companies around the industry and around the world that there were so few resources for people who wanted to learn product. Of course, today is very different. Today, there are so many resources, but today we kind of have a different problem because there are many different views on how to do product. So, it's hard to get heard above the noise.
Yeah, absolutely. There are so many different viewpoints. Actually, that was probably our first question: Given how many different perspectives people are hearing, why do they need to check out your latest book? Like, why this new book? Why do you think it's needed as another perspective out there in terms of how to build product?
Well, just to be clear, this new book, it's called "Transformed," to move into the product operating model. This book is different than the other books. The other books—well, as you know, "Inspired" is all about product managers and product teams and how they create products. It's really a book on product discovery.
In fact, when that book came out, a couple of editions ago, the most common request we would get at the time was, "You know, the managers don't understand. The leaders don't understand. So, can you share the same kinds of principles and practices for the leaders?" That was the motivation for "Empowered."
But even once "Empowered" was out, the single most common question we would get—and this is a question from all over the world, even some teams in San Francisco—they would say, "Okay, what you've described in 'Inspired' and 'Empowered' is how we know we need to work." They would say that, but then they would say, "But our company is so far away from this. It is like night and day different."
This is the big shocker to me: You can literally be in downtown San Francisco, and two companies are across the street from each other. One is doing products like, you know, Amazon, and the other one is doing products like a bank, and they're literally right across the street. I think that's crazy.
Of course, the further you get around the world, you see this distribution, this difference between how the best companies work and the rest. So, "Transformed" was written to try to answer the question, "How in the world do we move from working like a bank to working like a good product company?"
It's different. It's not about, "Here's how you do good product." It's about, "How do you change your organization to be able to do good product?" which, of course, is the transformation question.
But the big thing underlying your question, though, is why should a company change? Even, you know, do they want to change? One of the things I don't try to fight is some companies don't want to change. They, especially, you know, I'm teasing banks, but banks make so much money. Most of them don't want to change. The same is true with telcos—they make so much money.
Now, both banks and telcos are often in protected industries, so they can, you know, who am I to say, "You really should change?" I do believe they should change because they can better take care of their customers. But if their CEO doesn't want to change, mostly because they're making so much money, then okay, do what they want to do.
But for companies that do believe they need to get good at product—and to me, that's most of the world. By the way, even banks now, thanks to our friends at Stripe, Stripe is finally scaring banks. So, that's why I love Stripe so much. They are not only doing a good job for their customers, but I think they're doing a good job for the world's customers.
So anyway, if a company, no matter where they are in the world, says, "No, we know that we have to do better than we do today," then the question becomes, "All right, there are lots of different ways of building products—thousands of ways of building products. What's the way that the best companies most consistently use?"
That's really why I started doing what I do—to share what I see in the best companies. You know, I point this out with every book. It's in the new book as well that nothing in the book was invented by us. Nothing. All we do is we share what we see working well in the best companies, and we'll try to explain to companies why we think that's a good thing to do and how you would try it out.
Now, it is true that after doing this for, I've now done it for 20 years, sharing these practices, so after 20 years, you see a lot of patterns, and you start to see what's really common. Because if you talk to any company—like if you talk to Apple, they'll say Apple is special, and this is why they do their magic way. If you talk to Amazon, they say the same thing. Spotify, same thing.
It's not true with any of them. If you look at really how all of those good companies work, there's much more in common than different. In fact, mostly what they do different is more a function of the personalities of their founders.
So, if you peel away that—yeah, I mean, at Amazon, they call it working backwards. For us, we call it, you know, starting with the—it's the same concept, and it's a critical concept. You find that in different companies with different names.
But I feel like what we can do—and I'm really speaking for myself and just Silicon Valley Product Group—we're only five people. We're just a small little group. We do get to work with a lot of these good companies, so we can share what we think is important.
In fact, we shared an article recently called "The Product Model at Spotify" because, as you know, most people thought they knew the Spotify model, and it was a bunch of nonsense. They were just, you know, no idea what they were hearing—a bunch of agile coaches' interpretations of what Spotify was doing.
But of course, an experienced product person looks at Spotify and says, "None of that is relevant. That's just their Swedish words for what we good companies know they need to do." In fact, Spotify, I would argue, is an excellent example of a strong product company, and that's the single biggest reason they still exist.
Even though they're competing against the best companies in the world at product, they still are holding their own. They're doing wonderfully. I mean, there's no—they have no right to even still be running as a company when they're competing against Apple and Amazon and Google, but they do.
The same is true, you know, I'm actually in the middle of writing an article right now about the product model at Amazon. Amazon is probably the most consistently innovative company in the world and has probably had the biggest impact on this idea of a product model.
But that's what I was getting at: You start to see patterns, and we realized we needed a name for those patterns. Because for many years, if you look at my writing, I would just say, "Well, there's how the best work and how the rest work," which is not very precise, right? Just say, "Work like the best."
So, for this new book, we said, "If you're going to help a company transform, you need to talk about where you're going to transform to. What does that really mean?" You can't just say, "Like the best." You have to define that.
That's where we adopted the term "product operating model" from some of the companies that we work with. We thought that was good because it's a model—it's not a process. It's just a conceptual model, and what that really means is there's a set of principles. If the company does those principles well, they seem to do well consistently in product.
So, that's really what the book is about. It really shares those principles, and then it shares examples of companies that transformed, how they transformed, and why they transformed, and what they were able to do after they transformed.
Would it be possible, Mart, to just briefly describe those principles, those patterns that you discovered in the best companies? It's a short interview, so of course we cannot go deep into everything that we can find in the book, but maybe some key dimensions, key elements?
Yeah, absolutely. Well, stop me if I get too detailed. You could feel free to stop me at any time. But we kind of define this starting at the highest level. At the very highest level, it's really all about moving from output to outcomes.
So, if you had to say in one phrase what it's about, it's about changing to delivering outcomes, which, as everybody knows who has even ever tried that, is very hard. Outcomes are hard; output is easy.
So, at the highest level, it's about outcomes. But what does that really mean? Because that's just a phrase that doesn't really mean much. So, if you double-click on that, there are three dimensions that we see in every good product company.
It talks about when you transform three dimensions. The first dimension is changing how you decide what problems you need to solve. In other words, making your decisions on strategy—what is the most important work to do? The way the best companies do that is very different than how most companies do with their big annual roadmaps and planning meetings and stuff like that.
So, the first topic is changing how you decide which problems are important to solve. That's really product strategy. The second dimension is changing how you solve those problems. In other words, the old, you know, one way, which is what's used still in most of the world, is the stakeholders define a bunch of features and projects that they prioritize onto roadmaps, and the team just knocks them out one after another.
That's a feature team. In good companies, they don't work that way. Those teams are given good problems to solve, and then they're empowered to come up with a solution that delivers the outcome that you need. So, the second big dimension is product discovery—really changing how you solve problems.
The third big dimension—and I would argue all three of these are interrelated—but the third big dimension is changing how you build, test, and deploy your products. If you want to prove outcomes, you need to make sure you have the data, which means you have to have everything instrumented. You have to have everything monitored.
It means, especially if you want to take care of your customers and not hurt your customers, which sounds obvious, but this is the difference between being agile and doing agile right. So, if you're being agile, you are actually releasing continuously.
Now, as you both know, you don't have to be following any agile method to do that. All you have to do is truly be agile. You have to have, you know, small, frequent, uncoupled releases for each team. So, that often means changing how you build.
Twenty years ago, that's why companies moved to agile. Today, of course, you probably know a lot of the agile movement has been sort of taken over by what I would call fake agile or agile theater. So, if the first thing they tell me is they release every quarter, I'm like, "Don't bother me. You're not agile in any sense at all."
So, if you want to take care of your customers, you're going to have to change. I've been struggling with this a lot because I started my journey with Scrum, and later I discovered that Scrum doesn't mention how you select what to build, so there is no discovery.
Yeah, it's—people try to think, you know, they think of it as a much different thing. They don't really know how to think of it, but it's really just a delivery process, and it's fine. There's nothing wrong with if they do real Scrum, you know, releasing, say, at least once every two weeks. I'm usually okay. That's okay. That's not anything to brag about. That's not very impressive today.
The best practice is continuous deployment, so it's not there, obviously, but it's a whole lot better than releasing once a quarter or even once a month. So, okay, you can be okay that way.
All right, so back to Pav's question. These are the three dimensions: changing how you decide which problems to solve, changing how you solve those problems, and changing how you deploy your solutions. That's, again, at a high level.
In order to do those things consistently, we argue there are four new competencies that you need in your organization, and there are five new product concepts you need in your organization. These are tricky because you probably already use these words, but they don't mean the same thing.
So, for example, this is where, if I get too detailed—and I haven't even reached the level of the principles yet, Pav—there are 20 principles that we outline in the book. But I will get to your direct answer in a minute.
But in terms of the competencies, the first one is real product management. You know, most companies don't have that. They have product owner-ers, or they have feature team project manager types. They don't have real product managers.
But if you're going to have empowered product teams that are responsible for achieving outcomes, I can promise you your very few designers can cover that outcome responsibility. Very few engineers can cover that. They cover other responsibilities that are critical, but that leaves a big hole if you don't have it filled on the team for somebody that can take responsibility for the value and the viability of the solution.
So, you need real product managers. You also need real designers—product designers, not just graphic designers—real product designers. And, of course, you need real engineering tech leads. These are engineers that care just as much about what you build as how you build.
And then hardest of all for most companies is that they need real product leaders, and most of them don't have that. They have managers that manage, you know, people with these titles, but they don't have people that have ever done this job in a product model company.
So, they have a big hole in product leadership. Product leadership is really two things: they're the ones responsible for coaching and developing the people, and they're the ones responsible for providing the strategic context, which is how teams make good decisions.
So, the product vision, the product strategy, the team topology, the objectives for each team—in other words, what is the work the team needs to do? Which problems do they need to solve? That comes from the strategic context, so the product leaders have a very big role to play.
So, those are the four new product competencies. And I will tell you, this is where most transformation efforts fall down, is because the company thinks they have these people, but they don't.
Oh, can those companies transform at all? Absolutely! Yeah, I mean, that's what—absolutely they can. But that does mean they have to introduce these competencies, and yes, that's hard. I mean, that is hard.
But one of the things I knew we had to do in this book was to provide many examples of companies that have successfully transformed. It was also clear that none of those examples should be Silicon Valley companies because the Silicon Valley companies have the advantage of being born in this model. They started in this model.
It's much harder to be a company, say, based in London or based anywhere that has never worked this way before to change. So, all the examples in the book—there are 11, if I remember right—11 case studies. They all were from companies all over the world, including places like Brazil, Saudi Arabia, and of course, England and several other places.
Okay, so those are the four competencies. I warned you to stop me if this gets too much. There are five critical concepts that make up the product model, starting with some of the ones we've talked about already.
You need this concept of product strategy. It is a thing that spans the product teams. It's another common misconception. They think product teams are supposed to have their own product strategies and product visions, but they just have never worked in a product company.
I think the people that say that—okay, so product strategy is critical. The concept of a product team across, you know, what Spotify calls a squad, but a cross-functional, truly cross-functional empowered product team that has the skills in order to come up with effective solutions that are valuable, usable, feasible, viable—that's why teams are really the center of all this.
And then, of course, what do the teams do? They do product discovery and product delivery, so they need those concepts as well. The final concept really underlies all of these, which we refer to as product culture, which are things that span all of them.
They're things like, "What is the role of experimentation? What is the role of innovation? What is the role of predictability?" These are critical cultural aspects.
Okay, so those are the five product concepts. And then underlying all this is a set of, by our enumeration, 20 product principles. And that's what Pav was asking for. But in order to get to those principles, I kind of needed to work my way down that stack.
But the principles are things like—Pav was asking for some examples of principles. Well, one is, for example, that you're going to tackle all the risks up front. If you don't tackle all the risks up front, you're going to spend all this time and money building in the stuff that doesn't work.
So, you have to make sure you tackle those risks. Another one is that you have to embrace the concept of experiments. If you don't run experiments, you're never going to be able to do the things you need to do. You'll be a very risk-averse company.
Those are examples. Another one is what I was referring to before with deployment. If you don't have that principle of small, frequent, reliable, uncoupled releases, you won't be able to get these things live, measure the results, iterate like you need to. You also won't be able to prove outcomes like you need to.
So, those are just a handful, but there are quite a few principles. And it's the principles I think that are most important because, as everybody knows, there's a lot of different cultures out there. There's a lot of different kinds of products. If you're building an iPhone, it's a different thing than if you're building, say, Amazon Prime.
It's a very different kind of product. One's a loyalty product; one's a device. But those principles you'll find in each of those, at all of those, I should say. And that's why I think the principles are the most important.
I've always been much more interested in the principles than any process or any framework or any tool that might sometimes help you get there. Sorry for that very long answer to that question.
I want to double-click right before we got to the principles. I think you emphasized the five key requirements, and all of those were related to the team. So, I actually want to double-click on some of the frictions I've encountered in teams that I've led or teams I've been a part of, and I'm curious how you try to tackle those.
So, I think the most common frictions I see are with PMs and engineering managers or tech leads and PMs and designers. So, with designers, I think that one of the things that was crazy was, you know, when Brian Chesky said he eliminated—of course, we all know he didn't eliminate the product management function—designers were so happy.
I find this universally is that designers carry a little bit of resentment almost towards their product manager kind of taking some decisions. So, I'm curious about that component. And then with the engineering manager, it's a little bit different. It's where they're often tasked with the how to build something. Sometimes they're often tasked with the when—like, "Give me this estimate of when we can also deliver it."
And then they're wondering, "How do I have more of a say in the why or what?" So, I'm curious for both of those tensions how teams can work to overcome them.
Well, the most important thing to realize is that, by the way, I see those tensions all the time, but not in real product teams. I see them in feature teams. In fact, they are clear symptoms of feature teams.
Now, why it's worth really double-clicking on that—why is that? Because in a feature team, the product manager is not doing what I've described before. What does that mean to even do that? They're already handed a roadmap of output they have to deliver.
So, in a feature team, you have this person with a title—product manager, product owner, whatever they're called—yet they're not doing the job we talked about. What they're really doing—and I believe they're dramatically overpaid for this—but what they're really doing is project management.
That's why you see in these companies that people bend over backwards in order to try to defend the job. They're saying, "Well, our job is to explain the why," or "Our job is to herd the cats," or "Our job is to communicate."
And like the designers are listening to this and go, "Seriously? That's your job? I could do that job with a little bit more of what I already do." Or the engineers are looking at it and saying, "I could do that job with a little more than what I already do. You're not adding value."
They're not. That's the truth. They're not really adding value. They're certainly not adding enough value to justify their existence. If the company is in trouble—and as you know, a lot of companies today are in trouble, and they are worried about costs—that is a tough job to defend.
I keep trying to warn people: If that's your job, if you're on a feature team, you are vulnerable. A lot of roles are vulnerable, but that one has a huge target on its back.
But you have to realize that that's just a symptom of lack of role clarity. Because really, what is it that they're doing? I always tell anybody that tells me, "Oh, the job is the why," I'm like, "That's 10 minutes a week. 10 minutes a week! What are you doing the rest of the time? How hard is it to rearticulate the why? It comes from the product strategy anyway."
So, what are you? You're just really reiterating that to the team, and that's your job? Or, you know, herding the cats? Okay, well, the truth is we've got a lot of project managers that are already in the engineering organization. They're probably doing most of that anyway.
So, you're seeing a symptom of being in a different kind of team from what I'm talking about. I see those symptoms all the time. It's a very strong clue about how they're really working.
But if you talk to a product team—a real product team at a good product company—the designers are not saying, "Oh, well, the job is a noise job." The designers are like, "I'm glad we have this person because I wouldn't want to be doing that job. That is a hard job."
Because fundamentally, the product manager, they're responsible for the value and the viability, and they take ownership of the outcome. The designer is responsible, of course, for the usability—that's obvious—but they also, more generally, take responsibility for the customer experience, which is a huge responsibility.
And the engineers, of course, are responsible for the technical feasibility, but more generally, they take responsibility for the delivery of the product. So, we've got a very busy team. The designers have no time to play product manager, and the product manager has no time to play designer.
So, you don't see that muddy role that you see in feature teams. But I tell companies, you know, if you're going to do the feature team model, you really don't need the product manager. You need good designers, and you need good engineers.
And I would rather trade that product manager head for another designer. If you are that product manager that's kind of in that position—or even product leader—I would say, even when I was a VP of product management and I was in some of these types of positions, can you realistically drive the transformation? Or is it really like trying to incept your leaders to buy into this type of thinking?
More like, how do we approach it as middle-of-the-organization product folks who might be in that situation?
I think that's one of my favorite questions and topics now. But the answer is going to be different on whether you're an individual contributor or a leader because you described, you know, both scenarios there.
As a leader, you actually have a lot of ability to influence change here. As an individual contributor, the main thing I'd say is you have a lot more ability than you probably realize. One of the things I've been talking about a lot lately is agency—a sense of agency. Not enough people realize how much they can impact how their companies work.
Because, you know, nothing's worse—and I feel so sorry for those people that feel like a victim. They feel like, you know, they can't do anything because their company sucks and their leaders suck, and they just can't do anything. But really, there's a lot they can do.
I like them to take more ownership of what they can do. At a minimum, I promise it will help their career. At a maximum, it might actually change the course of their company.
So, there are a lot of factors outside of their control. But let's answer that first for the individual contributor. So, one of the most common questions I get is a product manager will say, "Okay, now I totally understand my situation. I'm a feature team product manager, and that's why I'm so unhappy."
So, their question usually is, "Do I have to change companies if I want to have a real job, you know, be a real product manager?" I tell them, honestly, sometimes, but not usually. Usually, you can significantly improve your role at your company, but it does take you taking some initiative to raise your skills.
So, for example, the classic, especially in Europe, is to go from a product owner—which, as you probably know, has had almost no training in product—but they do know one or more delivery processes like Scrum or Kanban. So, they're raising their skills from a role on a process to a real job.
Now, that means they do some work like you both have done, like I did, which is we go learn what a product manager really is and what does that mean. We have to go talk to a lot of customers. I remember the person who was coaching me wouldn't, as a new product manager, let me make a single decision until I visited in person 30 customers—15 in the US, 15 in Europe.
And it was the best thing I ever did. And that was not the end of my customer visits; that was the start of my customer visits. But you can't do the job of product manager if you don't deeply engage with your users and customers.
Another big thing that I didn't—I just—I was an engineer that moved into products, so I had some skills but not many. For example, I knew nothing about the go-to-market. I knew nothing about the marketing, the sales, the service—how our products actually made it into the hands of customers. I knew nothing about the financial analytics, the cost structure, or the monetization.
All that I had to learn. I was able to learn that—all of it—in less than three months. Most people can, but it does take a willingness. I remember the person who was coaching me, the first question he asked me was, "Are you willing to put in the effort to do what I tell you you need to do?"
Because if I had said no, he was going to say, "Well, I'm not interested," because he wasn't getting any extra money to coach me. It was just part of his—he was doing it as a good citizen, as a leader in the company.
And I said, "Absolutely." I genuinely wanted to learn this. I'm like, "You tell me what I need to learn; I will do everything I can to learn it." It doesn't take that long. That's the ironic part. It really doesn't if you're sort of pointed in the right direction.
Now, I was super lucky to have somebody who was amazing at product coach me on this, but today there's a lot more. Now, this is separate from the issue of the noise we were talking about before because, unfortunately, the vast majority of resources I see out there—and you know I'm not including you two in this; that's why we're doing this call—but the vast majority of the resources are just trying to help people become a better feature team product manager, which is not useful.
So, what I want to help them do is become a real product manager—defining "real" as how the best companies actually do this. And that means they have to do some work. They have to learn the customers. They have to learn the data. They have to learn the business dimensions. They have to learn the industry.
But you can all do that. What I tell individuals is once you've done that, at a minimum, your leaders, your manager will recognize that all of a sudden you know a lot more than you did before. And by the way, what the things you know are incredibly helpful.
I've seen people get promoted just from that. And then, of course, now they're in a product leader position where they can now influence more than just this. But to your original question, what can an individual do? They can raise their skills.
The next thing they can do is try to win the hearts and minds of their own team. So, that means going to your designer, going to your engineers, and helping them see the advantage of working this way.
Now, most designers and engineers, in my experience, are not the problem. They were trained to work this way. They're frustrated; they haven't been able to. But one way or another, you need to get on the same page with your team.
So, as an individual, you can do yourself, and you can do your team, and then you can start showing your company what you're capable of. Now, you have to do that in a responsible way, so you don't just ignore the roadmap.
It's just that you start doing a lot better job delivering what's on that roadmap. So, once you—that's what I recommend for the individual product leader. Of course, a product leader has a much bigger span of impact there.
Their first responsibility, if you're a product leader, is to raise the skills of your product managers. In fact, I tell product leaders that they will be judged by their weakest product managers, so they need to take that personally, and that needs to be their job—their responsibility.
Now, the biggest issue most of them have is they never worked this way, so they know they need to get good at this, but they don't know how. That is literally why I wrote the book "Empowered"—to share the biggest section in "Empowered" is on coaching, and it tries to share this.
So, I usually encourage those people: Just take one chapter a week, do one-on-ones with your people, raise their skills, and you're raising your own skills at the same time.
The other thing that can help is an experienced product leadership coach. You may know that over the last couple of years, my partners and I have been reaching out to meet a lot more product coaches out there because we get asked to introduce and refer product coaches almost every day.
We had a few that we've known for a long time—Teresa Torres is wonderful, Jeff Patton is wonderful. We've been recommending them for many, many years, but we overwhelmed them a long time ago. So, we needed a bigger network.
Today, we have a network of about 50 product coaches around the world that we think are good. We don't have any money relationship with any of them. We don't want any money relationship. We just want to know which ones are good.
When I say good, I'm talking about the people that I know have been there, done that at a good product company, and can genuinely help another company get there. Today, there are good coaches in most parts of the world. I'm hoping to see that really grow and be more like that.
Because if you're a product leader that's got this responsibility but you've never done it before, then a product leadership coach is probably your best bet for quickly coming up to speed.
Does that make sense?
I love the point about taking the initiative as an individual because, at the end of the day, I think this is what leadership is about—that you don't necessarily need to influence others with having formal authority. If you can do that just by acquiring new skills and winning the minds and hearts of people around, that's even better.
Yes, perfect. I like the concept you kind of talked about, which is basically like your inside world and your outside world. As the VP of product, I think you can be a little bit of an umbrella.
There are still infinite company-wide planning processes, OKR processes, but you don't necessarily need to subject your company to those waterfall processes. You can actually fill out all those forms for them, and you can tell them, "Hey, go be empowered. You go do continuous discovery."
So, I think just identifying kind of your sphere of influence—the areas where you are able to make decisions and then the areas that you're able to cover them—is a really effective way as you move up the ladder.
You know, I don't mean to make this sound easier than it is because the product leaders, especially within the product organization, in my experience, it's not that hard. I mean, if you do your job, most of the people want to work the way we're talking about.
There's some, but most don't. Most are very enthusiastic about this change. The bigger issue is the rest of the company. The rest of the company has never worked this way before. They don't really understand. They're worried about losing control.
They're worried about losing, you know, what happens if I'm still accountable to the numbers, but I don't have this same influence I had before. So, the real nuance comes to these product leaders to win over the hearts and minds of the rest of the company, especially the key stakeholders and the key executives.
That takes building trust and sort of being very smart about picking your battles. You know, you can go in and say, "We're not going to do any of this stuff anymore, and if you don't like it, tough luck." That doesn't go over well in most companies, especially if the CEO is also nervous, which most of them are.
So, what we want to do is work a lot more, you know, gently with those leaders to understand, like, "Look, are you also frustrated that you keep funding all these features, and they're not generating the results you want?"
"So am I! How about we do some experiments together to see if we can't do this better for you—literally for you?" Not many of them are going to—most of them are going to be pretty excited about that possibility because this is a very different framing.
In fact, that's why we chose the term "product operating model." As you know, a lot of people like product-led company and product-driven company, but when you talk about this to these stakeholders, they do not like those terms, and it's not hard to understand why.
Yeah, I think that labeling it and being a truly influential product leader—that's kind of the real rarity among those five requirements you mentioned that a lot of these companies are struggling with. If that product leader hasn't lived it, then they can't influence it. It's a very tough process for some teams.
Well, in fact, I would argue that the real key to successful transformation—there's a lot of things that have to go right, a lot of things that are hard—but the real key are those product leaders, especially the head of product and the head of engineering.
If those two leaders do what they need to do, the company has a real solid chance of succeeding on this. But if they don't, it's almost impossible.
Yeah, could we maybe go into a specific example or a case study where you worked with maybe like a head of product and head of engineering? How did they approach it? How long did it take them? Did they—I've heard you talk about in previous interviews like finding maybe like a set of teams even where they pilot it in. Is that like the approach you recommend? Or how do they go about that one-to-two strategy of transforming their company?
Yeah, and pilot teams are one of our core techniques that everybody—you know, it's a smart idea. Instead of rolling it out to a whole company, you know, it's just like an A/B test but on the organization instead of on your product.
Right? You're taking a small group, letting them run this, and even if everything goes perfect—and it never does—but even if everything went perfect, the rest of the company is able to observe. You know how people are. Some people hate change; some people need time for change.
This pilot team really helps companies get through that. But to your question, one of my favorite examples in the book is a company based in London called Trainline. Trainline—if you ride the trains, in fact, a little-known fact: Monday through Friday, Trainline's app is higher rated than Uber. That's how popular it is.
Trainline, a few years ago, was nothing. It sold some tickets, although they didn't even have a mobile app. It was all—you'd have to go to a laptop or something and buy a ticket. But it was nothing in the industry.
One of the big private equity firms decided that that's crazy; that should be an amazing tech-powered company. So, they bought the company, and the first thing they did—this is normal when it's a private equity firm—they brought in a CEO that knew what she was doing.
They brought in a woman named Claire Gil Martin. She had come from eBay, and they said, "Look, you turn this around. Set it up like you would set up a product company." The first thing she did was she brought in a head of product and the head of engineering.
Now, I realize in that case they had almost nothing. It was all outsourced; it was all obsolete tech stack. It was a very small number of developers, and like I said, most of them weren't even employees. They were remote. It was, you know, not what we're talking about.
So, she brought in the two leaders, and the three of them got to work. Now, it normally takes somewhere between one and three years to transform, depending on the size of the organization. This was like a mid-sized company. It was a real enterprise; it had been around several years, but it was, you know, it was not designed around the principles we're talking about.
So, these leaders had to introduce those principles. They started by looking at the staff they had and seeing which ones wanted to learn how to work this way. There were a few engineers that were on staff and wanted to—that was fine.
But they had to do a lot of hiring, and then same with product. There were more that Jonathan—that head of product—was a guy named Jonathan Moore, who I've known for many years. In fact, he's now a partner at SVPG, Jonathan.
But Jonathan had led the transformation at The Guardian. Many of you know The Guardian. I first met him as a brand new product manager at the BBC, where he was responsible for one of the most famous properties today—BBC News.
So, Jonathan and his head of engineering, they got to work putting these things in place. You heard me say that the two big responsibilities of these product leaders are developing their people—hiring, coaching—and then developing the strategic context in this case: the product vision, the product strategy, the team topology, the architecture.
And they got to work, and they—after about three years, they became the UK's biggest IPO to date as of that date. That's why you transform. And by the way, they went from nothing to literally one of the country—now they're all over Northern Europe too. It's not just the UK, but to one of the favorite apps.
You talk to people in London, ask them for their top three favorite apps, it usually includes Trainline.
I have a related question, Mart. You mentioned that the CEO brought the head of product. So, is it possible to coach a product leader that doesn't have product experience as an individual contributor?
Yeah, no, that's a fair question because one answer is, like Claire did, just go recruit somebody strong and let them do it. Again, that's one answer. The other answer is if your company has leaders that they think are good—in fact, another story we told in the book is a company called CarMax.
CarMax is the biggest used car sales company in the US. They're based on the other side of the US on the East Coast—not a technology center. They're a car sales company. They weren't born a tech company in any way.
But they had strong people that they believed could be coached, and that's exactly what they did. In fact, I was one of those people helping, but they had other people help as well. These are people that had the right mindset and the right sort of motivation; they just didn't have the experience.
That's why I was saying that in many cases, a product leadership coach is very much what you need. By the way, there are also CTO coaches that do the same thing for engineering leaders. They are, you know, somebody who may have been an IT manager but now wants to become a technology head of engineering.
So, those are different skills, and so they learn that. That's the main—those are the two main ways. I know you either bring in people that have the experience or you have a leadership coach that helps them learn the experience on the job.
How have people messed up hiring a coach in your example? Like, what's the anti-pattern? What should they avoid?
Well, by far—and I am worried about this. I'm always worried about this—the by far the biggest problem is that they hire a coach because the person says they're a coach, but they don't actually have the experience. They've never actually done product at a serious company.
The biggest example of this I know—the single biggest example—and this is very frustrating—is the vast majority of people teaching CSPO and PSPO classes—in other words, teaching product owners—have never done product. They are just agile coaches that have been trained in a method like Scrum or worse, and they think they can train these people.
What they're really teaching them is like, "Okay, you have to use Jira to prioritize a backlog." That's not product; that's administration. That's why they're called, you know, these are backlog administrators.
So, what we need are people who actually know product to teach product, to coach product. I did something unusual in the new book "Transformed." I was so worried about this. I am so worried about this because if—what does it mean to be an agile coach today? Almost nothing.
If that same thing happens to product coach, we lose. So, I was so worried about that, I decided to profile seven real product coaches in the book. I do this because I want people who want to transform to be able to get a really good idea of what good looks like.
Every one of them has serious experience doing product at a good product company, and they care about coaching. One of the problems we have in Europe—there is this whole—there is a big movement around coaching, but for that movement, coaching is a different thing.
It's good, but it's not the kind of coaching that these people need. If they talk about, you know, sort of career coaching, life coaching—that's nice, but that's not what this is about. I have never met a coach like that that could actually help you do a good product strategy.
Sorry, they can say all the nice things to you, and they can make you feel good, but that doesn't help you do a product strategy. So, there are some softer skills that those people could probably help you with indirectly, but I would much rather have a proven leader that has already worked with these kinds of stakeholders and can help you tangibly to do this.
So, this isn't an especially sensitive topic in Europe because there they have a very different definition of coaching. I don't know what to do about that. You know, in the US, we have a very strong institution about coaching—the famous book "Trillion Dollar Coach" about Bill Campbell.
What really differentiates a coach—and I think this is the part that surprised me about Europe—Europe loves football, as everybody knows. A football coach is not a touchy-feely person. A football coach is there to help you be an amazing football team, help you develop your skills.
If you go to a golf coach, you're expecting them to have deep knowledge about the mechanics of golf and could help you with that. They're not just about, you know, helping you have a good attitude or something.
So, anyway, we need people that know how to do things like coach other product managers that know how to do things like a real product vision and a real product strategy. That is probably the key to successful transformations at scale.
I would love to ask one more question. Go for it; I'm fine.
About the product operating model. So, Mart, you mentioned that there are 20 principles. Is that correct? Right in the book?
So, how should we interpret those principles? As best practices? As something that works or works in most cases? Can we break some of those principles depending on the situation, or are all required to have a good product organization?
No, it's a good question. It's a hard question. You know, when you look at this, the craft of product over the last 10 years, 20 years, 40 years—I don't know how far back you want to look—in some ways, things have not changed much at all.
In other ways, they've changed dramatically. I would argue that things that have not changed much at all are the principles, and I would argue that things that have changed dramatically are the tools and methods of applying those principles—dramatically.
Product is so much—the tools to do product today are so much better than when I first learned. But interestingly, the principles have barely changed. My belief is that the principles, if they're really true product-first principles, then they're probably very durable.
It's worth pointing out a principle doesn't say how you do it; it just says that you need to do this. You need to find a way. For example, one of those principles I already mentioned was an experimentation culture.
Well, as you know, the tools and techniques for doing experiments have gone from very primitive to very advanced. But we still do experiments. They were harder before, but we still did them. But the point is not how to do those experiments.
I have different advice with every company. When I'm working with a device company, it's very different on how to do an experiment than when I'm working with a pure software company. But they still need to do experiments.
In fact, the counterintuitive thing is a device company has to do more of them because the downside of messing up with a device is much worse than if we mess up in software. So, that's where the differences I think really are.
Now, will new principles emerge? I don't know; probably. But I don't think it will over the next couple of years. I think those principles emerge very slowly. If they're really principles that are lasting, when I look at the principles in the book, it's hard to—I mean, I would say they always have existed.
More principles speak more to the nature of technology-powered products and not about the particular frameworks or processes or methods. Those change constantly and, to me, are much less important.
Yeah, thank you. I can't wait to read the book and understand it in detail.
I agree.
Yes, I can't either. I want to be conscious of your time, though, so maybe we'll switch to just the simple fun questions. I think you did these with Lenny, so we've chosen different ones this time, of course.
But what's your favorite book that you've read recently?
Well, do you mean work-related or not work-related? That reflects a lot about you, what you choose. We're curious to see.
Well, I read a lot of work-related books, but I love reading. But I would say my favorite work-related book recently is "Build" by Tony Fadell. I actually have it here because I really enjoyed that book. Here it is.
So, "Build" is talking—oh yeah, I got it too! I hope you liked it too. But it's talking—it's describing the product model. The difference is he worked in hardware companies, and I mostly worked in software companies.
But he was in the right place at the right time. He got to work on the original iPod. He got to work on the iPhone. He got to work—he started the company Nest. I love device products; I really do. I started my career at a hardware company, so I love those kinds of products.
But it was really fun reading his firsthand account of this. He came from a designer-engineer to a CEO, so he's got great perspective. I thought that was a very good book.
It was interesting because the subtitle of the book is "An Unorthodox Guide to Making Things Worth Making." But when you read it, the reason it's unorthodox is because it's not about any of the modern processes or anything like that. It's all about the principles.
Awesome! Do you want to do the next one?
Yeah, Mart, what's your favorite product culture?
Favorite product culture? Yeah, oh, that's a hard one. I mean, I'm kind of a student of product culture, and I see—I've got pretty good at spotting the good and the bad at each culture.
I'd have to say if I could—the closest to my dream culture is probably Netflix. Netflix sets the empowerment dial even higher than really any other company, and they set it even higher than I normally even recommend. They sort of set the dial to 12 on a scale of 1 to 10, you know, so high.
But I also am so impressed with what they've done over the years. But there are honestly things I love about Apple's culture, about Google's culture, about Stripe's culture. Stripe is maybe—that's the best answer.
I mean, they kind of created their culture out of the best of several other companies. I don't know. I think there's a lot of—you know, there's some very good cultures out there, and there's some, you know, culture is very personal.
So, for example, there are some people I tell, "You will hate working at Amazon." I tell them, "Either you'll quit in the first year, or they'll fire you in the first year because of their culture." Other people, I say, "You were born to work at Amazon. You will absolutely love it there."
And most of the time, I'm right just because I understand Amazon's culture, and I understand, you know, if I know the person. But it's so personal, right? Because certain people, if I send to Amazon, I know they're going to hate it.
Amazon acts more like a startup than 90% of the startups I know, and a lot of people do not want that. Other people, that's exactly what they want. So, it's a tough question because it's so personal.
Totally. Good. What is the best product you've used recently?
Oh, jeez! I mean, I work with—I get to try a lot of products, but of course, I try them for a lot of startups, and a lot of them have a lot of work to do. What would be a great example of a great product?
I mean, I love motorcycles. I ride motorcycles. I own a couple, and the state-of-the-art in motorcycle technology today has never been better. Just the full product of what they deliver is pretty outrageously good.
I will tell you—I don't know why you just got me thinking about automotive. I don't want to buy a Tesla because of Elon Musk, so I bought a Rivian, which is a very, very good product. They have done a very impressive job.
There's a lot of overlap with a Tesla. The difference is the head of Rivian is really a designer—a product designer—and you can tell that in the product. It is a beautifully designed product that works holistically remarkably well.
Amazing! We're way over time, but last question, I guess. What is your least favorite—this is the spicy topic, so we left it for last—your least favorite product concept that has popped up?
Oh my gosh! You know, this is a sensitive one because there's so many that really make me frustrated. I think, though, the thing that bothers me more than anything else is this, you know, the prevalent definition of product management.
Because I think not only is it not helpful, but I think it's the root reason so many people in that job are not happy. So, that really does bother me. I think what pushed—you know, I wrote this article recently that was very controversial called "Product Management Theater."
What we've seen these issues forever—it's not like they were new—but what pushed me over the edge was there was this article that made the rounds online by one of the major product certification programs that sort of certify product managers.
They described their job of the product manager. They had this big graphic, and they said, "This is the job of the product manager." I'm looking at it and saying, "I can't believe they think this. I can't believe they say this. I can't believe people believe them. It's terrible!"
Because all it did was describe a project manager—pure project management. I'm like, "All right, this is—and this is the major group certifying product managers." Okay, this is a problem. So, that probably drives me nuts more than anything.
100%. It's kind of an epidemic right now of unhappy product managers as a result of misunderstanding their job, I guess.
That would be—where can people find you? When can we expect the new book?
Well, yes. Well, I hope this was interesting to people. You can find more of my stuff at SVPG, Silicon Valley Product Group dot com. The new book is scheduled to come out on March 12th.
However, I was told that in certain countries in Europe, Amazon is already shipping them several weeks ahead of schedule. So, I don't know when it's really—hopefully no later than March 12th.
And it'll be out in Kindle, Audible, and hard copy, and the translations are underway already.
Amazing! Amazing! Well, thank you so much for being here.
Yeah, that was an honor and a pleasure.
Well, thanks for inviting me, and yeah, I appreciate the dialogue, and I hope to encourage you both to keep doing what you're doing.