Transcription
[Music]
Foreign ER and partner of Silicon Valley Product Group, before founding SVPG to pursue his interest in helping others create successful products through his writing, speaking, advising, and coaching. He served as an executive responsible for defining and building products for some of the most successful companies in the world, including HP Labs, Netscape Communications, and eBay.
As part of his work with SVPG, Marty is an invited speaker at major conferences and top companies across the globe. He is also the author of two books: "Inspired: How to Create Tech Products Customers Love" and "Empowered: Ordinary People, Extraordinary Products."
We are so excited to hear you in this session, which is called "Leading Complexity with Context and Not Control." Over to you, Marty.
---
All right, thank you very much! Thank you, and uh, you know, thanks for inviting me to this series. I love the idea of this series in particular. I've been talking to Marcus about this topic for multiple years.
I have a talk that is not a normal talk. I have lots of sort of typical talks I give, but this one is a special talk really just for this community, this group. By the way, I have been paying attention to those of you who have shared what role you're in. This is super helpful to me because my theory is that most of you are coaches or trying to be that sort of change leader at your company and help your company get better, or for many of you, help many companies get better—your client companies get better.
So that's a group that I feel very deeply about and care a lot about. I will warn you that a lot of what I'm going to talk about is probably going to be ranging from uncomfortable to disagreeable. You're going to have to decide, but I'd encourage you to consider this: I think we have—one of the things I have found in the sort of coaching community is virtually every single person I met is very well-intentioned. They have a sincere desire to really help other people get better, and that's why I love people like that.
However, I think the community as a whole has been misguided, and I am going to try to use this time with you to convince you that in truth, much of what you have been taught is not helping you or, more importantly, your clients.
So I absolutely am going to save plenty of time for Q&A at the end. If you feel real strongly about anything, feel free to just interrupt; I don't mind that. But I want to give you—I want to maybe get you to rethink some of the things you are thinking today about helping.
For those that don't know, I mean, you heard a little bit about my bio, but what I'm really all about is my focus on the best product companies in the world, as defined by those kinds of companies that are forced to consistently innovate in order to stay in business. So it's all about consistent innovation—that's my world, that's what I mean by the best product companies.
Because I was just by dumb luck, really, I worked at Netscape, which was incredibly lucky. For those that don't know, that was the first internet company. I worked at eBay, which was the first marketplace company. I mean, the truth is a lot of the people that went on to go to great product companies came from one of those two places. So I knew a lot of these people, and they would call me—early Google, early Amazon, early Facebook, early Twitter—all these companies would start, and I got to know them.
My world is really about sharing how they work and trying to close the gap between how they work and how most companies in the world work. But I have to admit, I'm losing that battle. I think collectively we are all losing that battle. More companies are working terribly—I mean just terrible—than ever before.
So I think we need to step up and look at how we may be inadvertently contributing to that. So that's where I'm coming from. One of the things I started with is I wanted to just make sure, you know, because we are all dealing with complexity, we know that. So I went to the—you know, my sort of like, you know, the friends I have at these companies. It's a pretty little big list, and I asked them, like, you know, so what—when you talk about dealing with complexity, what are the things that you care about and interest?
No surprise, they're the same things everybody cares about. Just these are the things all of us deal with. So one of the things I had this theory that the challenges are no different—the challenges of a bad company versus the challenges of a good company—they're still the same challenges. There's no silver bullet that makes them go away. However, the way they deal with those challenges is where it gets interesting.
So let's talk about this. Now, the first thing I want to do is kind of get something out on the table that is going to be a theme through this entire talk. But I think this is the reality that we have to really talk about today. When somebody says, you know, they're agile, I don't even know what to believe. That is so tortured and damaged as far as a brand.
But let's talk about this. Let's talk about two teams, and I can list many examples of each of these. So Team Red—let's talk about Team Red. They are—they've got an agile coach, maybe one of you. They've got a Scrum Master. They, of course, have a CSPO or a PSPO trained product owner. They follow Scrum rituals religiously. They do Sprint planning, they do daily stand-ups, they do demos, they do retrospectives—all the things we'd like them to do. They're probably following Scrum; maybe they're following Kanban, but that's what's going on.
However, they're not empowered by any meaningful definition of the term. They're there basically to implement a roadmap, usually coming from a bunch of stakeholders. Also, the team releases monthly, or worse, a lot of them are releasing quarterly. I even talked to a company recently that's still somehow releasing yearly.
What's remarkable is these companies consider themselves very agile. In fact, go further—they consider themselves textbook agile.
Now let's talk about Team Blue. Team Blue thinks agile is a bunch of—and I hear that from companies all the time. I hear it from teams at Amazon, I hear it from teams at Netflix, I hear it from teams at Stripe. It's like, "No, agile is a bunch of BS. Look at all this nonsense out there." They say, "No, we don't have any agile roles. We don't have any agile coaches. We don't follow any Scrum or Kanban rituals."
However, they're truly empowered by the sense that what we mean—they are given problems to solve. The team is able to go figure out the right solution, and they're doing continuous delivery, continuous deployment. By the way, not for the last weeks—usually for the last many years.
Now you tell me, which team is more agile? This is—you know, that's not a hard question. Team Blue is the only one doing any meaningful form of agile.
One of the talks I'm going to reference through my talk—the person who actually introduced me to Crisp years ago was Henrik Nieberg, who gave the introductory talk. I will tell you, I'm a huge Henrik fan. I'll listen to him explain anything; it doesn't matter what it is. He is—I just love listening to him. He is a gifted storyteller and a gifted—I think he's a gifted coach.
It was so funny to me listening to him because I'm going to reference the Spotify model as we go, but it was really funny. He sort of says, "Yeah, they're agile, so of course they're empowered. Of course they're doing frequent release vehicles."
I'm going, "Henrik, I wish! Look at all these companies out there." In fact, I don't know what the real answer here. All I can do on this is say anecdotal, but you would all have your own experiences. How many of the teams you know are actually releasing? You don't even have to be doing continuous delivery or deployment. They could be doing release every week or even every two weeks—that still counts as agile, I think, in my book, in the real book.
And how many of them are actually empowered versus just feature teams or even worse, delivery teams? Almost none of them. So you have to ask yourself, what the hell is the point of agile if that's what people are doing?
Of course, people are doing a lot worse than Team Red even. I'm going to talk about that. So it is not—you know, we need to step back.
Now, the theme of this talk is going to be looking at another way of phrasing it: What is agile really? Is it a process like Scrum, or is it a set of principles like you find in the manifesto? What I would argue with Team Blue is they are actually living the agile principles. When you talk to them about the manifesto, they go, "Of course, these are obvious. We've been doing this for—we believe this forever." But these processes, they're a joke.
Now, I think it's deep there. We're going to talk about why companies get pulled in the direction of formal process, but I'm going to be honest with you: good product companies—they're Team Blue; they're not Team Red.
Okay, now I have to also confess to you that for nearly 20 years, I've been recommending teams move to agile if they're not. So don't get me wrong. I clearly—and why do I recommend they move to agile? Because of this: that's because I've been—I think of it in the terms of they're going to be empowered, they're going to do frequent continuous release vehicles, and that's—agile is often the forcing function for them to get there.
But if they're going to move to agile and not get there, I'm—you know, I'm not going to talk about it. That's just not helpful. So coming right at you, this is not useful. We need to revisit and rethink what we're talking about here.
So let's step back because, like I said, it gets worse. It gets a lot worse. Fundamentally, there are two ways of coping with this complexity that we all face once we get beyond just like about a dozen engineers. The main way that I see most companies dealing with it—and partly this is the fault of the coaching community—is they deal—they attack it with process.
Now, the most egregious form of that out there—and you know, another thing Henrik showed was that slide that almost made me cry, but it showed, you know, how do companies deal with scale and agile? Of course, he was showing off that, oh look, the Spotify model is number three or number four. But that's not what I saw. What I saw was number one, by a long shot, was this piece of crap, SAFe.
Now we need to talk about—and my goal through this session is that every one of you understand why this is so toxic to the companies you're trying to help.
So first of all, I want to go—I have to sort of fess up almost. Well, four and a half years ago—I looked this up last night—four and a half years ago, I wrote an article because people kept asking me about SAFe. I said, "Hey, the problem is I don't know a single good product company that uses SAFe, so how am I going to write about it?" But I kept getting asked about it, so I reached out and I talked to people that were running SAFe. They're not in what I'd call the best—they are all absolutely not in the best.
Anyway, I published an article that said things like there is literally nothing agile about SAFe, which is super easy to see. I don't know why—I mean that's just marketing, right? They added the word agile in for marketing. But hopefully, you'll see this.
I also say I don't know a single strong product company that uses SAFe, which is—you know, what's really remarkable? At the end of the article, I said, "Hey, I only know the people I know. I can't pretend to know about all the companies in the world because nobody knows all the companies in the world."
I said, "But I can tell you I do work with most of the best product companies. Not a single one of them uses it." I also said at the end of my article, "If a good company did adopt SAFe, I'm pretty certain their best people would leave."
Now, these are really—I mean that's pretty harsh, wouldn't you say? That's pretty harsh. But I want you to understand why I was able to say this with such confidence. When I said it four and a half years ago, I didn't know really—I mean maybe I was just missing all these great companies that were using it. The truth is it's continued to grow like crazy.
But what we need to talk about in this talk are the two really important questions. The first one is, what is it about that piece of crap that is so attractive to so many companies? I know what it is; it's not a mystery. But we need to talk about that—what is so attractive?
And number two, why is it that none of the consistently innovative product companies use it? What the heck is going on? I want you to have a clear understanding of the answers to those critical questions today. This is a big deal, and I suspect many of you know the truth: there is a lot of money to be made as a coach helping a company to implement and deploy SAFe. That's what it's for; it's a machine.
There's a lot of money to be made, and I don't get me wrong; I'm not judging. You have to feed your families. But if you genuinely want to help the companies that you're trying to help, I want you to understand why you're not helping them at all. So this is important.
So that's what I want to talk about here. Now I want to start here by sharing with you because I find this really remarkable. So it's not just that the best product companies don't use a process like SAFe; most of them don't like formal processes at all. You could put Less in the same bucket. I actually don't know anybody who's—unless I don't even know if it's relevant, but it's not good, I'll tell you that.
And I understand why the good companies don't use it. So one of the leaders—think about this approach, and I find it remarkable because the truth is they are all uniformly afraid of this happening to their company. I can say I don't know of anything else that these leaders all agree that they're scared about, right?
So Eli, who of course has lots—we could talk all day about crazy Elon right now, but he's right: the problem is that big companies' process becomes a substitute for thinking. I think he's spot on there—allergic to process. For those that don't know, Steve Blank, he's well, the father of Lean Startup. He is four times a successful entrepreneur, teaches entrepreneurship at Berkeley and Stanford. But he's right: as companies get bigger, they start to value process over product. Over time, as organizations grow, the process people start dominating management, and the product people end up reporting to them.
What he doesn't say is—and then the product people decide to have to go somewhere else in order to practice their craft. How about Bezos at Amazon? He talks a lot about the difference between a day one and a day two company. A day one company, no matter how old you are, acts like a startup. And no matter how old you are, a day two company acts like a big bureaucratic process machine.
The point is, if you're not careful, process can become the thing. It happens very easily in large companies, but process is not the thing. I don't know if any of you took me up on my suggestion to watch the lost interview with Steve Jobs, but here's a little clip. And by the way, I consider that an absolute master class in product. If you haven't, it costs four Euros to watch, so it's the best thing, best four Euros you'll ever spend.
But let's talk about what he thinks about process. People get confused; companies get confused when they start getting bigger. They want to replicate their initial success, and a lot of them think, "Well, somehow there's some magic in the process of how that success was built." So they start to try to institutionalize the process across the company, and before very long, people get very confused that the process is the content.
That's ultimately the downfall of IBM. IBM has the best process people in the world; they just forgot about the content. And that's what happened a little bit at Apple too. We had a lot of people who were great at management process; they just didn't have a clue as to the content.
In my career, I found that the best people you know are the ones that really understand the content, and they're a pain in the butt. You know, when you put up with it because they're so great at the content, and that's what makes great products. It's not process; it's content.
So, you know, I honestly can't point to anything else that all those leaders consistently are scared of, but it's true. You have to realize when Steve Jobs said that, IBM was kind of like we think of Amazon today. They had been great, and they lost it. They lost it, and that happens to so many companies.
By the way, he recorded that before he came back and turned Apple into the most valuable company in the world, so it was very unusual. I would encourage you to watch that video.
So let's talk about the alternative. Now, Henrik described one company that uses the alternative—Spotify. I think I said this before; in my view, Henrik is an incredibly gifted coach. I'm—he's the one who actually introduced me to Crisp years ago.
But that said, the first part of his quote is spot on: the most important thing is not your process. The second part of his quote is not really helpful or really even true. Well, what I'm going to talk about—and I'm pretty sure Henrik would agree because so much of what he said in his talk was actually getting to what's important.
But I feel a little guilty because, in my understanding, Henrik is a bit of a Swedish national treasure. So this is with love. I hope Henrik—maybe Henrik's even listening, and he can join us in the Q&A.
But I am going to talk about a few things here that are—you know, I watched his video, and because I love hearing more of the Spotify origin story, I did get to work a little bit with Spotify. Nothing like him, but I actually—you know, Henrik didn't really tell you what you needed to know about Spotify, and I need to tell you that.
So first of all, he didn't answer what is it about the Spotify model that enabled their record of amazing consistent innovation. I couldn't hear that; I couldn't find that. And even maybe more important, because this applies to so many of you, I didn't hear a word about why did so many companies that try to adapt the Spotify model fail to make any meaningful improvement.
I see that all the time, by the way. I meet companies that say, "Yeah, we're on the Spotify model," but it hasn't really done anything. And I'm like, "Well, show me your Spotify model." And what do they show me? Does anybody actually seriously think this is the Spotify model? This is noise; this is irrelevant.
Try—you know, the fact that they like to call a cross-functional empowered product team a squad—it's irrelevant. Who cares? Now, Henrik did say in his talk that they named it different things so people would ask the question what this really means.
I could tell you definitively that has failed because so many people use the term squad, but they don't change it to mean what Spotify means. So what's the point? It's just another way. The point is, who gives a about what the terms are for this? We don't care.
That is not the Spotify model. The Spotify model is much more important, and this is—and I just stole these little fragments off of Henrik's wonderful illustrations, but this is what the Spotify model really is, and it's not a process at all.
First of all, it's not a process. Where's the process? They don't even care if you're running Scrum or Kanban within the squad; they don't care. Where's the process? It's not a process; it's a culture. It's the way he likes to describe it, or it's a set of—the way I would describe it, the way Netflix would describe it, the way Amazon would describe it—it's a set of first principles.
It's a set of things we believe about how products should be built. For example, the biggest one is Spotify very—and this is why I say Henrik knows all this stuff; he just doesn't—you know, I want him to call this out. I want to call it out for you.
Why did Spotify succeed? It's not because they named things goofy names; it's because they had these principles. And I see these same exact principles at good product companies across the world.
And you know, I'm not—I know I'm beating up on my Swedish God Henrik here, but he sort of said, "What I want you to do is copy, paste, adapt." Do you remember that? You should copy, paste, adapt. That is terrible advice, and that doesn't work. That's the biggest reason so many companies that quote adopted the Spotify model and didn't get any value.
Maybe think of it this way: let's say I made Swedish meatballs for you, and you loved my Swedish meatballs. You said, "You know, can I have the recipe?" And I'm like, "Sure, here's the recipe." And let's say you decide to adapt it, and maybe you adopt it by removing the meatballs. Do you think you're going to like my Swedish meatballs if you remove the meatballs? No, it's going to not be good Swedish meatballs.
And that's what happens. People listen to him; they adapted it, and they lost what was important. Now, unless I was waiting for Henrik to say, "And these are the principles that were really important and made the difference," and if you want to adopt the Spotify model, it's not about the nomenclature; it's about these principles.
So this is what you, as a coach, need to understand if you want to help a company. It's about these principles.
Number one, probably the overarching one is it's a way of working that's optimizing for innovation over predictability. Now, by the way, SAFe is the exact opposite. SAFe is a process that's designed to optimize for predictability. Many of you know that's what waterfall is good for.
SAFe, despite the marketing, is pure waterfall—pure waterfall. It's just got all the buzzwords thrown on that ridiculous image, but it's—it's all, you know, anybody knows knows it's just buzzwords.
But now, of course, it's fine to optimize for predictability, but not if you're a tech product company that depends on innovation. So that's why I say with confidence no good product company would use SAFe because it is optimized for a different problem.
I also love—I mean, I just love these things that have been there for a long time, and this is why I—as soon as I met Spotify and talked to them about how they worked, I'm like, "These are all the same principles that it just took me a little bit to get through their silly nomenclature differences."
But that was easy. Trust beats control. Focus on motivation. The whole idea of squads, which is just, you know, it's like a mini startup—it's cross-functional. All this is what we mean by an empowered cross-functional product team.
Well, how about small and frequent releases, decoupled releases? How about this idea that agile actually means more than Scrum? The reason they succeeded is because they didn't get trapped; they didn't get fooled by all these process people. They knew to ignore them.
The principles are what mattered. Impact more than velocity—another one that I've been talking about a lot lately because it's such an important first principle. I don't think a product team has any chance of success with innovation if that product team doesn't have direct access to users and direct access to the stakeholders of the business.
Look at what they've got there—just minimize the distance between the maker and the user. They understood that too. The point is, oh, how about an experiment-friendly culture? We call that product discovery.
All the principles there are the same principles I see in the best product teams. That's why I love Spotify a long time ago; that's why I still like them now. A lot of companies will ask, you know, "Well, can we adopt the Spotify model?" My answer for years has been you can do a lot worse than adopt the Spotify model.
It's a good model, and it can work. The problem with it is it's not packaged in a way that people see what's important. I'm going to say, since I'm saying all these blasphemous things about Henrik, I don't like those big diagrams—the culture diagrams. You know, they're famous big diagrams.
I think everybody loves them; don't get me wrong, I understand that. But I don't like it because there's too much on there. People don't take away what they need to take away. What I think would be much more impactful is if you share the model with people, break it down, talk about each principle.
Now, the truth is there are some principles that you could be like, "Are they really critical or not?" That's fine, but there are some principles that really are truly first principles.
When I first met Spotify, the most important thing I saw—and this is what I look for in any—the single most important thing is their engineers were empowered. And by the way, that is not true in SAFe; that is not true in most of those processes, unfortunately, as we all know.
You can use the method of Scrum and be totally unempowered. If you're just—we say if you're just using engineers to code, you're only getting about half their value. So that's a first principle. Spotify sets the dial on an empowered engineer to 10. By the way, so does Netflix. You heard Joe Justice—Tesla sets it maybe to 20; you know, they set it all the way past the dial.
But this is the most important thing, and if that's not happening, I don't really care about the rest. I know it's not going to work. So there are certain principles here that are first principles and are absolutely essential.
But if you want to know why Spotify has succeeded still and despite so much competition, it's because of this. It's not because they call groups of teams a tribe; it's not because they call a cross-functional team a squad; it's not because they have guilds.
It's not—they could have addressed those things a dozen different ways; it wouldn't have mattered. What matters is that they understand these critical principles. And you have to be able to look at what Spotify does and then look at SAFe, and you can hopefully see how different they really are and why one leads to success and one doesn't.
I'm just looking—yeah, I cannot pretend to be able to interpret what Dave Snowden is trying to say, so I will just take your word for that.
All right, so let's talk about how top product companies deal with complexity. Let's look at this, and I would absolutely include Spotify. They have long ago earned their place in that list of top companies.
So first, there's really three things: first principles, which I started talking about, and then thinking, and then talking. It's funny because when I talk to my friends at these companies about, "Well, so what do you think is the key?" You know, they all use different words. For the most part, they're talking about the principles, and they're talking about what I'm terming thinking and talking.
But this really is the alternative to scaling with process. So let's talk about some—not all—but some of these first principles. Well, I mentioned this one just before. This is what I look for in every company I first meet, and that was true with Spotify, and it's true: nothing is more important than an empowered engineer.
That's Bill Campbell. He literally explained that to Steve Jobs before in early Apple. He literally explained that to Jeff Bezos at early Amazon. He literally explained that to Larry and Sergey at early Google. And it's not an accident that all of those companies built their way of working around this foundational first principle.
I was taught this at HP Lab. At the time I worked there, it was known as the most consistently innovative product company in the world, but that's what they taught us—an empowered engineer.
So an empowered engineer is not a mercenary; it's not somebody that's just given a backlog and said, "Go implement this." It's somebody who cares just as much about what they build as how they build it. This is a critical first principle.
What does it mean for a team like Spotify to work like a startup or think like a startup? This is what we mean by an empowered team. Leaders should articulate what needs to be done and why, and then let the team decide the best way to do it.
One of the things I loved about Henrik's talk—and one of the things I hadn't heard before—was he shared how the leaders of Spotify got up in front of the squads and said, "Look, we do some things really well about helping you manage your music, but one of the things we don't do well is help you discover new music."
For those of you who saw that, hopefully, you remember him talking about that. He even had a photo of the leaders explaining this. That's what good product leaders do—they provide the context. They share, "This is the problem; this is why we need to solve it. Figure it out."
And of course, there was lots of product discovery work that went on, and they came up with—I mean, the origin story for Discover Weekly is an awesome origin story. It's an awesome product discovery story. They did a great job with that.
I will tell you, as a Spotify user, I rarely do playlists anymore because the generated ones from Discover Weekly are generally better than my own. That's how good they are.
So that's another first principle, though: we need teams of missionaries, not teams of mercenaries. You saw the Spotify principle of motivate—that's what this is. That's what John Doerr is trying to say. You need motivated teams. In fact, a motivated team of engineers can do almost anything. It's amazing; it's what keeps me in this business.
How about Leslie? For those who don't know, Leslie Kilgore was one of the early members of Netflix. She was ahead of their marketing, actually, and she coined the phrase, "You push decisions down to the product team." Sound familiar? This is very much what Spotify does; this is what all the good companies do.
And by the way, the polar opposite of what SAFe does. SAFe is a command-and-control model. Top-down, the decisions are made above and passed down to the program level, then to their—they call them teams, but they're not teams.
Anyway, lead with context, not control. Instead of command and control—that's what control is for. It's context, which is short for strategic context. That's like, "Tell us the problem; tell us where we're trying to go; tell us what other teams are going to do so that we can do our part."
You probably know Jess Humble. He wrote the book "Accelerate," one of my favorite books for the engineering side of the equation. I love this quote: "If it hurts, do it more frequently." That's another one of the principles in Spotify.
This is why frequent, small, reliable, decoupled releases is the foundation of any good product company. They need to be—now, that's not just a purist thing, and you don't have to be continuous delivery. I prefer if you are; there's a lot of advantages for our customers and for us.
But at a minimum, you have to do release trains no less than once every two weeks, at a minimum. If you're not doing that, why do I say that? Because if you're not doing that, you're not taking care of your customers.
We can talk about why; I can point you at articles if you want to read about why, but you're not taking care of your customers, and a good product company is all about taking care of their customers and innovating on their behalf.
Reed Hastings, the co-founder of Netflix, he's talking about product teams in a team topology—highly aligned, loosely coupled. It's another one of those first principles. We want to structure our team so that they're highly aligned, loosely coupled. Again, you'll find that in the Spotify model too.
Mark Andreessen, the co-founder of Netscape—he was my boss there and the co-founder also of Andreessen Horowitz now—but, you know, the way he phrases the need for an experiment and experimentation culture is, "The most important thing is to know that you can't know."
Good teams not only know what they can't know, but they admit what they don't know, and they go figure it out. If we knew, we would just build it. That's why it's so easy in a process that's focused on predictability. We know how to deliver on time, on budget. I learned that literally 40 years ago; it's not hard.
But it means shrink to fit; it means cutting it. You give up all hope of actually solving customers' problems. It's literally output over outcome. But of course, what matters in the product world, when your livelihood depends on consistent innovation, what matters is results.
And that depends on knowing what you can't know, and then we go figure it out. That's literally why we call it product discovery. Diane Green, the co-founder of VMware, says, "The riskiest thing you can do is not take risks."
It's all about being smart with risks. You know, when we're coming up with a good product, we're looking for a solution that's valuable, usable, feasible, and viable. All right, those are examples of first principles.
Now, if you look at Henrik's images when he showed you the engineering culture at Spotify, there were like 20 principles in there buried in there along with lots of pictures and lots of stuff. But if you look closely at it, you'll see these first principles—that is what matters.
Now, I'm not saying that every company that wants to use the Spotify model should just exactly use theirs, but I am saying you better get the meatballs right. You better get the important things. If you get those important things, and then, you know, every company is a little different.
Netflix feels very strongly that process rules are insulting to their people, so they literally don't like things like an expense report policy. They think that, "No, if anybody we hire is smart enough to be reasonable on an expense report, is that important?" I don't know.
You know, there are other examples of that. You can see examples of that in the Spotify—you know, Amazon's got things they feel religious about. They feel religious about a technique I'm going to talk about in a minute, which is called the six-page written narrative.
Do you have to do that in order to be a successful company? I don't think so. Do I recommend it? Absolutely. So there are—it's not a first principle, but it is a really useful technique.
So there's differences in companies; that's the part you can adapt to your culture. But if you don't get the meat right, you fail.
All right, so let's talk about thinking. What does it mean to think? And I mean this; this is really important. What are we thinking about? We're thinking about three big things: product strategy—it's a huge element; product discovery; and big product and policy decisions. These are the main things we're thinking about, and that's the leaders.
And this is the source of so much complexity we have to solve for these things. Now, there are some good ways of doing that. I haven't mentioned Stripe yet. They're probably one of the best product companies right now hitting on all cylinders.
But yeah, think deeply to move quickly. Now that's a first principle they believe in. I didn't see it in the Spotify one, but I think they would like it; they may even do it; I don't know. But that's sort of the point. If you're trying to think better, this is why we do that.
I love this quote: you probably don't know Leslie Lamport, but he invented one of the very first word processors, and I benefited from that. But I love this quote: "If you think without writing, you only think you're thinking."
Because I really do believe that. That's why Amazon feels so strongly about the written narrative—the so-called six-pager. And you know, it's something I really do believe writing forces the author to really think much more deeply, to articulate your logic, your priorities, take accountability for your recommendations.
There's no wiggle room, no hiding place. This is the thing; they don't allow PowerPoint presentations because they think it's far too easy for somebody who's a charismatic speaker to get up there and wave their hands, and people tend to go along rather than really listen to what they're saying and whether they know what they're talking about.
So it's part of their culture. Okay, Apple's got weird things in their culture; everybody's got different things in their culture.
All right, and then the last one is talking. And what are we really talking about here? Well, we're doing a lot of coaching. This is one of those big differences between good companies and the rest—is coaching. We're also talking about first principles so that you can pass these on to your teams, and we're also sharing that strategic context—the vision, the product strategy, the team topology.
One of the things I love seeing is how so many more companies are understanding the role of coaching today. I love this Andy Grove quote. For those—he was a long-time CEO at Intel. You know, what gets in the way of good work? There's really only two things. The first is that your people don't know how to do good work because they weren't taught, which is what coaching is meant to do.
And the second is they do know how, but they don't care. They're not motivated. That's why you saw the motivation first principle for Spotify. Bill Campbell's quote: "Coaching is no longer a specialty; you cannot be a good manager without being a good coach."
Now, I want to distinguish because a lot of you are coaches, and as you know, in the coaching community, there's kind of two kinds of coaches. I mean, our dream world is every coach does both of these things, but in the real world, it's often too.
There are coaches that know the content, and there are coaches that just know the art of coaching. Do you see what I mean by that? So in the product world, where we're talking about—the reason your manager needs to be a good coach is because your manager's primary job is to coach you on the skills.
If you're a manager of product managers, your job is to coach them in being a great product manager. If you're coaching tech leads, to teach them to be a great tech lead, and same with designers.
I think it's impossible to do that if you have not done that job yourself. And my evidence for that—and this is going to be rough for some of you to hear—my evidence is the vast majority of people teaching product owners in CSPO and PSPO classes have never done the job at a good product company.
So what are we doing? We're creating people that know the rituals of the process but are absolutely clueless when it comes to the substance of the job. This is one of—if you've read anything I've written, you know this is a hot trigger button for me.
But we have got to fix that. The people that need to train product managers are people who have done product at good companies. If you've done product at Spotify for five years, okay, let them teach product people.
You notice I'm avoiding the term product owner? I think that it's a bigger problem in Europe than it is in the rest of the world. But I'll admit I didn't see this problem coming originally, and I should have. I thought, "Who cares what it's called?"
Well, it turns out we should care a lot because product today—we have all these people that know the rituals in Scrum, but they don't know the job of product manager, and the whole product model falls apart if you don't have a competent product manager.
And I will tell you, I have never met somebody who's only been trained as a product owner that was anywhere near competent as a product manager. So we need to—if you're trying to help a company, stop trying to teach them to be a product owner. If you've not done this job, get somebody that has done the job.
Just like would you teach an engineer how to code if you've never been an engineer? Seriously. But for whatever reason, we think we could teach somebody to be a product owner.
I honestly think that the industry has not done the product community any favors by doing that. So I'm interested in a title product owner, and even worse, the anti-pattern is a product manager who is not the product owner, by the way. That's the model in SAFe, if you haven't noticed.
So there's a hundred different ways that is a toxic, terrible way of working. How about Microsoft? The new leader, Satya, who's so much better than his predecessor and is really turning that place into a product company again—the leadership framework now at Microsoft has got three pillars: modeling good behavior, coaching, and caring about your people.
How about at Apple? Long-time Tim Cook—the Apple Leadership Model has four pillars. One of those pillars is teaching and coaching. One of your four responsibilities as a leader.
How about Sundar at Google? The top trait of a successful manager at Google is that that person is considered a good coach by their employees. By the way, the second-rated trait is that they are considered an empowering manager and not a micromanager.
And then back to Spotify to bring it home here. I love this quote: "Talk is cheap, so we should do a lot more of it." I love that. That is a big part of the culture. That's what we do. We need to share and coach and share the context.
All right, I have thrown a lot at you. I just have one more thing because most of the coaches I know, they genuinely want to help their company learn to work like the best. That's what I hope you do, and I hope this talk motivates many of you to rethink how you're actually helping—if you're even helping.
And if so, if not, how you can change. When we talk—when I meet a company that genuinely—it's usually a CEO that reaches out to me and says, "All right, we know the way we're working is not working for us. Amazon's now coming after us; somebody else is coming after us. We have to learn how to be a serious product company. We have to start innovating. How can you help the company do that?"
There are three things. Number one, you need to get them to change how they build. So I don't care if they've been doing agile for 10 years. If they're not doing frequent, small, independent, or decoupled releases at least every two weeks, they're not agile.
And you need to give them some tough love. You need to tell them, "You're not agile at all." It's not about the roles; it's not about the rituals; it's about do you have consistent, frequent, reliable release vehicles—again, no less than once every two weeks. If not, you gotta fix that.
Second, changing how you solve problems. This is what it means to move from a delivery team or a feature team to an empowered product team—changing how you solve problems. Now the teams have to step up. They're not just there to code; they're not just mercenaries. They are there to solve problems, which means product discovery.
Which means you need three critical core competencies: real product management—notice, not product ownership; real product design; and real tech leads—serious engineering. Those three competencies come together; they're supported by others like data analysts, user researchers, but those are the three core competencies.
And their job is to run these experiments to get us to a solution worth building. And finally, the third—and this is what's meant really by moving from an IT model or project model, whatever you want to call it, to a product-led company—which is changing how you decide which problems to solve, which opportunities are the best ones to pursue, which threats are the most serious threats.
A lot of you are not even concerned with that because in the old model, in the IT model, it's not even a question. The stakeholders decide those things. But in a good product company, like all the examples I was giving, no, the product leaders are responsible for that, and that's hard.
You have to pick the things that really can move the needle. Like when the leaders at Spotify said, "We need you to help people discover new music," that was them as a leader deciding the most important problem to solve. If they would have gone and asked a salesperson, they wouldn't have heard that. They go and ask a stakeholder; they wouldn't have heard that.
But this is what the leaders do. There are skills involved in all three of these, obviously: continuous delivery is the skill for the first; product discovery for the second; and this is really first and foremost about product strategy.
All right, I know I have thrown so much at you. If you do want to learn more, there are some books. You know, "Inspired" talks about product discovery, and "Empowered" talks about product leadership. I love this by my partner, Martina, who is talking about product marketing.
We have one more book underway; it's going to be a little while because it's a hard book to write called "Transformed," which is really about transformation, and it really talks about those three big things I just listed: changing how you build, changing how you solve problems, and changing how you decide which problems to solve.
And it got several—it already has several first-person detailed case studies of successful transformations. With most coaches we talk to, that's what they're asking us for more than anything. They know the examples that fail; they're all over the place.
A company needs to transform; they hire somebody like McKinsey or Accenture; they bring in something like SAFe; they get nowhere other than spending millions of dollars. And so they know what doesn't work. What they don't know is what does work, and the purpose of that book is to share that.
Okay, so I will—I would love—and I've actually—I'm right on time, which is just more dumb luck than anything else. That's great, Marty. But I—Marcus, let's do some questions.
But for anybody that does not get their question answered, jot down my email there so that you can feel free to send me a note. All right? And I can say Marty is amazing at answering emails, and you're very fast at responding too, and you've been great so far with feedback.
So thanks! All right, so let's open for questions. Please use the chat to write a question.
And before, you wrote an email to us in the Leading Complexity crew a couple of days ago, and you said that this would be a wild ride or something equivalent to that. And I can just say it was a fantastic presentation.
So let's open for questions.
---
Let's see what we have.
So the first one for Maria: I would like you to elaborate on Team Red. What was the problem with having a roadmap? Isn't the six-pager plan?
I need another hour, Maria. Those are big topics.
So first of all, the six-pager is not a plan, just to be clear. The six-pager is a rationale for a decision. First, the truth is you can have lots of forms of six-pager. The most famous one is called a PRFAQ, which is still not a plan; it's a vision.
But the most common example is actually, "This is a decision we need to make around our product; this is our recommendation." So it's still not a plan.
Now, the other part of what you're asking, though, is what's the problem with roadmaps? I'm just trying to figure out a short way to answer that. If you're interested, the book "Inspired" starts with that, actually, and you can Google it—an article called "Product Fail" that kind of summarizes that.
But fundamentally, there doesn't have to be a problem with roadmaps. In other words, if you're a good product company and you are doing product discovery, and afterwards you put what you're building on a roadmap, that's just a simple, useful communication tool.
But in 99 out of 100 cases or so, that's not how the roadmaps are used. The roadmap is done instead of product discovery, and that is a whole different topic. It's one that all the good product companies understand.
You heard me say the first principle: know what you can't know. A roadmap, in the old way, is created by people who are so arrogant they don't know what they can't know. They think their features are going to work; they think they know how much it's going to cost.
And just by the way, since so many of you are agile coaches, they think ridiculous techniques like story point estimation is how you're going to figure out what's going to be involved in building something. That's just—that's so amateur, and it's time to step it up. If you're going to help serious product companies, you need to do way better than that.
---
Should we grab another one from Manuel? One of the major problems I'm struggling with in my pursuit of trying to implement a cultural continuous discovery, etc., is product designers and PMs who claim that we cannot release before we have reached a certain minimum feature set because you never have a second chance to make a first impression and will ruin customers' opinion if we release too early.
I think you would like that one.
Yeah, I mean, that is a good question. That's not unusual. That debate has existed forever. Mostly what it tells me, though, is this is an organization that needs some education on the techniques and discovery.
So what—another way of framing that question, Manuel, is that there are some risks. What you're saying is that we don't know. Remember I said there's four risks in product discovery all the time: value, usability, feasibility, viability. What they're saying is we don't know; we have to give it our best shot.
And by the way, in a lot of companies, it's true—you only get one shot, not because, you know, the first chance to make a one chance to make a first impression or whatever. It's not because of that; it's because management doesn't put it on the roadmap for another iteration.
So you literally just get one shot. That's all describing a company that doesn't understand how to do product discovery because product discovery is all around addressing these risks.
So what you're really saying in that question is we're not sure if what we have is going to be perceived as valuable enough. That's what you're saying. If you were sure it was going to be valuable, no problem—go to market. If you're not sure, what do we do?
It is true that sometimes companies way overdo it, and they over-engineer in order to do a simple test. In other cases, they will—they worked for four months on—it's known as the four-month MVP—and they push live a piece of crap, and nobody wants it, and then nobody is interested in doing anything.
So they can each be true. So what we do in product discovery is we will test on a limited set of users, a little bit limited set of customers, and we will make sure we have evidence about the necessary value before we even have our engineers build it.
So the main thing—I know I sound like I'm trying to sell books, Manuel, but that's why I wrote "Inspired" because I kept meeting teams that thought what this team you're referring to is thinking, and they don't understand, "No, we have really good techniques for doing this."
---
Manuel, do you have a comment? Can you raise your hand?
Yeah, I do have a comment because actually, at least that's my interpretation of what I'm observing in my company, is that there actually—it's the other way around. They're overconfident that they know best.
So I'm in a context where we're selling software to musicians, and a lot of our product designers are musicians themselves, so they have this attitude of, "I know what's best for my product, so I know what to build."
Well, by the way, that's a really common problem—that they think they are the customer. You heard—you saw on that Spotify principle of close the distance between your real users and your team. It's the same thing.
Even if you have somebody who knows the domain really well, that is not a substitute for putting it in front of real users and customers. And that is so easy to do.
So now, if what's really going on is there's some arrogance there, right? The product manager thinks they know, and they might be right, but they probably are not.
Even if part of what they think is right, a lot of it won't be. So you need to force the issue of putting it in front of real users quickly. Good companies often use the heuristic of put that idea in front of real users in no more than two weeks—not two months, not four months, no longer than two weeks—because you need to learn what you're right about and what you're wrong about.
The other thing I'll say, Manuel, is because this is a really important point, is it's easy to know too much about a domain.
We did—you notice I know another company in Sweden since we're talking about so much about Spotify? Just down the street from Spotify is a company called Klarna that you may know. Klarna is one of the leaders in a space called buy now, pay later. It has basically disrupted the credit space.
It wasn't just Klarna; it was also Afterpay; it was also Affirm. These different companies invented a new way of doing credit. It's pretty remarkable that none of the credit companies came up with that innovation.
Why? Because they thought they knew the rules of credit. Now, this may be the problem too. If you pull somebody from the music industry, they know how it's always worked, but they might not know how it should work or could work.
The biggest thing I would say, number one, make sure you are testing your ideas with real musicians or whoever it is. But also, the biggest single thing, even more than that, make sure the engineers are there because of this: you know, you just gave me a little clue that this product manager is pretty arrogant.
One of the signs is they don't think they need to talk to customers. A bigger issue is they don't think the engineers need to talk to customers. And consistently, this best source of innovation are our engineers.
---
Great! So Cara, you have a question. Do you want to jump on stage and pose the question?
Let's see. Maybe I can go ahead.
Oh, you're muted.
It's not working. All right, I can read it.
In an organization where engineers are separated from the customer by multiple layers of product and management, what are the ways to help people in those layers understand that they're getting in the way?
So what we just talked about is very much what we just talked about. And I think it was yesterday—or maybe no, it was Monday. Monday, I published my latest article, which is called "The Foundation of Product."
And one of the things you'll find as one of those first principles in good product companies—and you can absolutely see this in Spotify—is that there are three things that are simply non-negotiable for that squad or cross-functional product team.
One is direct access to the actual users—that's what we were just talking about—direct access. And I was emphasizing by the engineers too. So product manager, designer, and engineers.
Number two is the product manager needs direct access to the stakeholders. So the people who are responsible for sales, marketing, finance, privacy, security—any of these legal product manager needs that relationship because coming up with a great product is both something your users and customers love but also works for the business.
And then the third is that the product manager and the product designer—this one is within the team—the product manager and designer need daily access to their engineers, and you can't have anybody in between any of these three.
And just to not to beat a dead horse, but SAFe is not set up this way; it's set up quite the opposite. So that means you need to make sure that your engineers have direct access. You need to make sure your product manager and designer have direct access.
And often, there are people that want to—you know, they're usually well-meaning people. You have a customer success team, and they say, "It's our job to do that," or you have account managers, and they say, "It's our job," or there's nobody at your company that's in the way.
But when you talk to your—in a B2B context, you talk to the company you're trying to sell to, and they say, "Oh, you have to interact with our IT person here because they're the ones that manage the vendor relationship, and they'll talk to the end users." None of those are acceptable.
And in my article, I said if product is always about picking battles, this is a battle worth fighting. You need to make sure you have this access; otherwise, you will very likely fail.
And I can't say that about that many things. I really think this is a make-or-break thing. So Cara, this is essential. Now, most of the time, a little education of the CEO, and you're done.
And I will say there's very few companies that don't really understand this. Now, the problem—the biggest single problem is process people. They think that there's a different process, like SAFe, that you should be following, and this is not part of that process.
That's why—connect jobs.
Yeah, go ahead.
We've got a question from Helena. Do you want to jump on stage and add some color to that question?
Otherwise, I pose it.
So could you please elaborate and help—oh no, so that was wrong. It was Ingrid. It was Ingrid, sorry. I mixed up the names.
So Ingrid, what would you tell the bank that wants to make all the services that support their actual products products?
So, Ingrid, do you want to add some color to that question?
Sorry, I couldn't find my unmute.
Yeah, so this bank that I'm working with has their heart in the right place, but obviously, I mean, they're doing all the wrong things. So I'm sure to work for a while here, but I'm trying to help them understand that the services that are component parts of their actual products are not products.
And they're trying to make them products. So I've tried everything I can think of to help them understand why they're not, and I just thought maybe you would have maybe a pithy take.
Well, first, can you clarify for me? Most of the time at a bank, we talk about two kinds of things. There are products like a savings account or a checking account, and then there are products like online banking that lets you modify.
When you say service, do you mean the checking account, or do you mean something different?
No, I mean the actual services that support the product. In this case, it's loans—commercial lending, a loan.
So a loan is a product, right? But the services that support that—so for instance, e-signature, you know, DocuSign.
Yeah, I can't think of what the other things are now—all of the tools that they use to pull together the data for each of the borrowers.
But you're saying you don't see that as a product?
Well, so maybe I'm wrong, but if the loan is the product, why would we productize all of the components of that product?
Well, I mean, you're kind of—I think getting confused because of the language. So once you were looking for a pithy way, I have quite a few. I've talked to quite a few banks, actually, and you know, banks finally, thanks to Stripe, they're all scared and now taking product much more seriously.
So that's the good news because they're long overdue. But one of the things I often tell them is just look: if we were Amazon, if Amazon was going after your customers, how would they think of this?
It would all be—it's all the product—all of it is the product. A loan is part of that product, just like when Amazon sells books, the book is part of that product. They call the book the merchandise, just like a bank might call the loan the actual loan offering—that loan product.
But everything around that loan—and you just gave great examples: electronic signatures, balances, payments—all of the things around that loan—that's what product does. That's what product is.
And our job is to create, you know, the best experience around that loan product. Now, that's the easy short answer, and that's kind of stage one. Stage two is to say, "Look, how can we use the data we're collecting from this hole to actually make better loan products?"
And that's happening in the insurance industry; it's happening in the loan industry; it's happening in lots of places. And that is really what Amazon would do.
That's what they are doing. Like, look at what they're doing with an online pharmacy—sort of reinventing the pharmacy. They're not just thinking of it as, "Oh, well, there's a pharmacy that issues prescriptions, and we do things like payment." They do a lot more than that.
Okay, that's very helpful. I appreciate that.
You bet!
---
Okay, let's take the last question from Malta. Are you ready to unmute?
Yes, thank you very much. Thank you, Marty. Great to be here, and great to have you.
My question would be as follows: when you look at ITIL implementation, I'm really sorry that my camera is not working, but when you're looking at ITIL implementations and service providers, I often see layer upon layer of portfolio managers stacked upon each other in front of the service owner.
And they defend this move by saying, "Oh no, we need to shield our product owners from the craziness of our customers."
And it's really difficult to break through there and break this 30-year-old habit of layer stacking.
Well, look, they need what's called an intervention. They are so far broken that way of thinking, and you said it by, "We need to shield our product owners from the craziness of our customers."
There is nothing more wrong than that statement right there. And so what's going on is their leaders—now, they probably have some CIO that has no clue. They're probably running one of those formal processes, and that's the model.
So they need an intervention. Now, that might only happen if they decide that they have to change. That's one of the challenges for coaches is if a company doesn't think they need to change, it's very difficult to get them to change.
But that is a—you're describing a very broken company, and they need—somebody needs to sit down. Now, one of the challenges coaches often face is the agile coaches often face is that they're not—the people they really need to talk to are the CEO, but the CEO is not going to talk to the agile coach.
So that's where it falls down. The CEO needs somebody to work to talk to. That's why they go to so often the places like McKinsey and Accenture is because they feel like they can talk to that person.
Unfortunately, those companies don't really know what to do. They want to help, and they want to charge them, but they don't really know what to do.
But yeah, I have to say that it's Accenture—that's what I said. Accenture has no idea about this stuff.
Okay, thanks a lot!
Thank you!
Sure!
Okay, thank you so much, Marty, for this interesting session.
All right, just like you said.
[Music]