"Product Strategy: The Missing Link" by Inspired Author Marty Cagan of SVPG at Lean Product Meetup

Hi, I'm Dan Olson, and we had another great speaker at the Lean Product Meetup tonight: Marty Kagan. He's right back there, a product expert and author of "Inspired." This is the second edition of his book. You may have read the first edition or maybe this one.

Tonight, he gave a new talk on product strategy, and we were very excited to hear about that. He shared a lot of great insights and advice, and we also had a lot of great Q&A with the audience. So, I hope you enjoy it! If you do, please like the video, subscribe to our channel, and also sign up for notifications so you get notified when we publish other videos. Thanks, and enjoy!

It's good to see everybody, and I am curious how many of you might have been here last year. It's like an annual tradition for Dan and me to come here each year around this time. I gave a talk last year, and I wanted to see how many of you might have been here for that. Just a quick show of hands. Some of you!

The reason I ask is that I talked about what I wanted to work on for the next several years. Just quickly in summary, my book "Inspired" is really about how good product teams solve hard problems in ways customers love but that also work for the business. Admittedly, that's my favorite thing to do. I love working with teams to do that. That's what most people get into product to do.

However, I shared last year that I've met many teams, and I realized that I was in a bubble here in Silicon Valley. I met many teams not only outside of Silicon Valley, but also right in San Francisco, that are not allowed to work that way. They're literally not allowed to work the way a good team works. This, of course, is just insane to me, and I wanted to understand why.

I sort of went on a crusade. I started a multi-year effort. I gave a talk last year about empowered product teams versus command-and-control teams, also known as feature teams. I talked a lot about how feature teams are given a roadmap and they just crank out features, versus a real product team, which is there to solve problems.

I also said that I was planning for the next several years to write about what's necessary to actually change into one of these companies, to move from the most kind of company to the best kind of company. For those who haven't been following my blog, I have been writing many articles. My initial focus was on the biggest area I felt was missing, which was coaching. The managers were not doing their jobs to develop their people, and for an empowered product team, you really need that.

It's a hard job. In fact, I have been increasingly honest and frank with people about the difference between being a product manager on a feature team and a product manager on a true empowered product team. On a feature team, which is what most people sadly are, it's really a project manager with a pretty title. If you think about it, what's really going on is there's a little bit of design and maybe, if you're lucky, a little usability testing, and then code, QA, ship. That's what goes on.

So, the quote "product manager" is really there to herd the cats, getting everything from design into engineering and out. Of course, that is not what good companies do, and that is not how they solve problems. I had talked before about why and how good companies work, but I didn't really shine a light on the difference.

I have been doing that. My series on coaching has been going for months, and I finished most of the topics I wanted to write about. I've got a few more. I should mention that Dan and I do share a publisher, and I agreed to another book. So, all of these articles will one day want to be chapters in a book, depending on how well they do out with the community.

I share each one, get feedback, and decide if I can improve it or if I should just scrap the idea. The nice part about that is when I do actually get to the point of a book, I have a lot of data that says this is actually answering real questions. I like the process, but it's some work.

Now, though, I told Dan I have a few other talks, and I wanted to use this group, which honestly I consider my home group. This is where I've spent 40 years, so I love this area. Of course, a lot of you I've met before and know many of the companies. I said I wanted to try out a new topic.

I'm going to admit I actually picked the hardest topic to talk about because product strategy is what I usually reserve for when I advise a company. That's pretty much what advisors do: strategy. There's a little bit on technique and process and stuff, but mostly it's about strategy. That's a lot easier to do one-on-one with a company than it is to talk in general terms.

Alright, but I had to tackle that with the purpose of the book. I am trying out a big topic on you, and I'll also warn you that this really is a big topic. I'm not exaggerating; we could talk all day on this. So, I'm going to plant a lot of seeds with you. I'm not trying to just tease you or anything; I just want to get you to rethink some of the things that are going on in probably your company and in many companies.

For those who haven't heard me talk, I'm kind of all about the difference between the best companies and the rest. I will admit, especially in this book, there are four companies that have very heavily influenced me. I went back to these companies to really look at what's different. Those are Amazon, Google, Netflix, and Apple.

Now, of course, there are other really good companies: Airbnb, Slack, Etsy. We can keep going with other really good companies, but those four, I'm just sort of confessing, had a disproportionate impact on me. Partly because they have consistently innovated, they really have, and they've earned their place for me.

The other reason is that those four companies, if you've been inside them, have very different cultures. This is something that kind of makes this whole discussion tough because I used to say good companies had a strong product culture, and bad companies had an IT culture. You've probably heard that. The truth is it's more nuanced than that.

For example, all you have to do is go visit Amazon and go visit Google, and they are two completely different planets. They have very different cultures, yet you'll see they have a very common philosophy when it comes to the topic of empowered product teams. In fact, they share that with Google and with Netflix.

I've been spending time untangling what I think is really essential about those four companies from what's just honestly a reflection of their founders. So, what I think is really important is what's just sort of incidental. Admittedly, that's driven a lot by my own judgment of this, but that's what I'm sharing with you.

It's like those companies do strategy much differently and much better than most companies. As an example, they also do coaching much better. So, these are the things I'm talking about.

Dan did a good job giving you my background, so I don't need to repeat that. What I do is let's start by talking about what I even mean by product strategy.

So, empowered product teams are all about giving teams hard problems to solve and also giving them the space to solve them. The Netflix phrase for that is to give them freedom and give them space to do their thing. That's really what we're talking about.

Now, the real question, though, is how does a company decide which problems they should actually work on? That's what we mean by strategy: product strategy. Let's also admit there's market strategy, business strategy, sales strategy—every kind of strategy. We are talking product strategy, which is really another way of phrasing it: how do you make the product vision a reality?

But this topic of product strategy is really critical because it's the bridge between your vision and what product teams actually work on. That's what's key.

Now, this is one of the most remarkable things to me, but when we talk about most companies rather than the best companies, many of you have probably seen this. It'll just be a fun one. I can watch this a hundred times. This is the Underpants Gnomes. If you don't know the Underpants Gnomes, you're in for a treat. This is the shorter version. If you watch this at work, turn down the volume.

But anyway, let's show it, and then I'll tell you why I relate to it so well. I cut off some of the more egregious issues they talked about in there, but honestly, I know it's funny, but it's so true. This is so true. I cannot tell you how many companies I meet that have some big objective. You know, they're pretty much all the same: double revenue and reduce our churn rate.

So, they have all these big objectives, but then all of a sudden, you've got a roadmap of a hundred features. It's like, what? You know, what is missing from this picture? Strategy is missing from this picture.

Now, it's more insidious than that. I really do believe I understand the reasons that's missing. Now, fundamentally, at one level, the reason it's missing is because it's hard, and companies hate hard things. I mean, I've learned that over the years for sure. They hate hard things.

If you go online and Google "product strategy" or make the mistake of saying "product strategy framework," you will get all kinds of garbage that comes back that tries to give you like a fill-in-the-blank thing, and of course, they're useless.

Now, one of the reasons you'll see why these things are useless is that a lot of people, most companies honestly, don't do anything. I'm serious. They don't do anything. They go right to roadmaps. But some companies say, "We should have a strategy." I mean, they talk about that in business school. We should have a strategy.

So, what do they do? They hire McKinsey or they hire Bain or somebody like that, which they don't realize, but they're actually giving them a business strategy, not a product strategy. So, it's not even really useful to us. But still, they feel like they have a nice PowerPoint presentation now that they can show.

Oh my gosh, it's really depressing. But if you look at what a real good strategy is, there is some talented leader. Honestly, this is a theme I come back to all the time in good companies: they have good leaders. It's really the key difference.

But they have a talented leader that identifies the few critical issues, and they actually figure out how to get leverage out of what they work on. Then they focus the attention and action on things that actually matter. That is so different than what most companies do.

Now, what I wanted to drill into is, wow, why don't companies really do this? The fundamental reason is because it's hard. But more specifically, there are four things that have to be done well to have a good product strategy, and each of those four things, as you'll see, are difficult things for companies to do. If it was easy, we wouldn't have this issue.

So, what I wanted to do is sort of work through these four things, both pointing out what I find in most companies and then trying to show you what I see in good companies. Of course, where we really need more time would be in what good companies do, and that is why I'm working on a book.

So, alright, let's talk about the four big things. First of all, they have to be able to focus. That word, most companies are allergic to that word. They really don't understand what focus is. Most of them think it's prioritization. It's not prioritization, but we'll talk about what it really is.

They have to focus on the critical problems. It's one of the true things about businesses: not all problems are equal.

Alright, second, they have to generate insights on how to attack those problems. That's a hard one for most companies. It's the heart of good companies, but it's very hard for most companies.

Third, they actually have to coordinate the actions for each product team. This is literally where a strategy turns into work, turns into actions.

And then finally, they have to actively manage. I'm still looking for the right verb there, but I do not mean micromanage here, of course. I do not mean that, but I also don't mean passive management.

So many people think that agile teams and even they think empowered teams mean back off managers, and it is so not true. It's exactly the opposite. So, we need to talk about this a lot now.

I say this a lot now: we don't need less management; we need better management. So, these are the four things, and I want to drill into each of them.

Let's start with focus. You guys know most companies. This is not really a secret. How many companies struggle with focus and being able to really choose? I want to be clear about what I mean by focus.

I was actually at a company just recently, and I've seen this in many companies. I wouldn't be surprised if you've seen it at yours. All along some wall somewhere, or at least on some spreadsheet floating around, is a list of the top priority initiatives or whatever you want to call them—the big things, not the little things. I'm not even talking about the little roadmap; I'm talking about the big things.

This one company had over 60 of them, literally. Those were like, "We must do 60 things." And you know what's funny? I had this conversation with their leaders. I mean, like, "Can we talk about focus?" And they're like, "Oh yeah, that's the prune-down list, right? We wanted to do much more. We know what it means to sacrifice."

No, but honestly, I'm going to be real with you. At this level, if you've got more than a few, it's too many. So, we have to talk about how people do that.

I feel a little guilty about what I'm about to share with you here because I don't know these people personally, but I have been—how many of you have seen a few years ago an otherwise excellent resource for product people, the First Round Review? Some of you may know that one of my favorite VCs, First Round Capital in Philadelphia, they have a really good blog.

But anyway, they published this article talking about the Pandora product prioritization process. Some of you may have seen it. For years, I have been forwarding a link to this to people to say this is exactly what you don't do. Seriously, it is exactly—it is the poster child for bad strategy.

Well, honestly, it's not even fair to call it a bad strategy; it's no strategy. For those that don't know, and it is true, there's this kind of extreme, but it's really very similar in principle to what so many companies do.

So, what they do is they basically imagine sort of the absence of product management or product strategy or product leadership. All they do is they have a certain amount of engineering capacity, which in fairness to them, in their case, was not very much. That's sort of the root of the issue.

But anyway, we all have not as much as we want. So, they had some engineering capacity, and of course, they wanted to try to satisfy as many stakeholders as they could. So, the way they do it is they give fake money to each stakeholder proportionate to what the CEO says: "You get twenty dollars; you get thirty dollars," and they could buy whatever features they want. That's their process.

And of course, they were bragging about it because it's like the stakeholders get to get what they want. This is exactly what I mean by the difference between a product team that is there to serve the customers in ways that work for the business versus a feature team that is there to serve the business. That's exactly what's going on.

I didn't know them; I still don't know them. But when I read the article, I was thinking, "Okay, well, this is what happens when you have zero product." I was certain that, first of all, I knew they were going to get a ton of features because that is a recipe for a ton of features.

But I also knew there was almost no chance there was going to be innovation—almost no chance. In a tech-powered company, to me, that's just—it’s only a matter of time. So, I didn't know when it would happen, but it's interesting. Right after this article was published, if you had watched, they went public at, I think, sixteen dollars a share. Just like this gradual—it wasn't overnight; it was over years—gradual at eight dollars a share, they got sold to Walter basically for salvage price to Sirius XM, which is their dead.

So, that's exactly what you would predict would happen if this is, you know, at the absence of product strategy, at the absence of product management. So many companies, then, where these roadmaps are actually coming from is a negotiation with the different lines of business. So, it's not really much different; they're just sort of being very overt about it.

Now, I want to be a little fair. I don't know them, but I want to be fair. Every time I've seen a system like that, it's not the product people saying, "We should do this." They're forced to. Usually, it's the CEO or the other leaders who are forcing them.

When I also learned in that article that they went public—remember, Pandora went public with 40 engineers. Think about that: 40 engineers. Now, of course, as investors, First Round is like, "This is such an awesome company! Only 40 engineers! Look what they've done!" I'm thinking they had no business going public with 40 engineers.

In hindsight, it was clear they were because they were obviously competing with Spotify, with Apple, with the serious players, and 40—you know, you're not. So, in fairness to them, with only 40 engineers, I don't know what they could have done.

The truth is, if I was the head of product, I would have known that the stakeholders, no matter how much funny money we give them, are not going to be happy. So, this was maybe a way to make as many of them, you know, at least include them in demise together.

Yeah, but that is a good example of a company with no strategy. Now, what they really were doing—and I don't know if they realize this or not—but they were confusing what they were confusing was focus and prioritization. Because what they were really doing was a prioritization process, not a focused process.

So, I want to talk about focus a little bit because we need to talk about what that really means and why it's so essential. It's just one of those words that's thrown around in every single company, but it's largely meaningless. It really means two things.

The first is that only a few things on that 55 or 60 item list will actually have the chance of moving the needle realistically. Everybody learns this, I think, in their own way when they learn it. I remember still the time I learned it, and it was because it made such an impression on me.

I learned this lesson about real impact and focus because, well, like Dan said, I started as an engineer, actually very close to here in Palo Alto at HP Labs. You know, I was right out of university, and I had known, you know, which basically means I knew the theory of programming but not really much of the practice of it.

So, one of the nice things at HP Labs was they had what we would today call pair programming. It's where we were paired with somebody, and I was paired with a great guy, actually, who was fortunately for me, answered all my questions and was very tolerant.

So, I was honestly not programming; I was watching him. He was very good, and it was amazing education for me—amazing education. One of the things we were working on was system software development tools and development environments, and one of our objectives was performance.

In that kind of software, it's still like if you adapt performance, it's still one of those things. But anyway, every time we started working on something, you know, when I saw code that was obviously not that efficient, I would say, "What about let's work on that? We could definitely improve that."

He would say, "Well, we could, but we're not going to." The next day, the next area, "We could, but we're not going to." He just kept saying that. Honestly, I was like, "Alright, alright."

Anyway, about a month later or so, he says, "Now we're going to work on performance finally." The first thing he does is he brings up the performance analysis tool, which is on basically every operating system, and we run it through some paces.

Sure enough, there's an online report that comes out, and there were three things where all the time was going. He really wanted me to see this, and he said, "Here's why I kept saying no before. We could have fixed every one of those issues that I pointed out."

He said, "The truth was, even if we did every one of them, the user would not have perceived any difference. It would have made no perceptible difference. However, if we focus on these three areas, we're going to make all the difference."

He said, "That's what goes on across organizations all the time. Everybody's told to work on tech debt, which means nobody really does the hard stuff with tech debt that really has to happen. Or everybody's supposed to work on growth, and nobody really moves the needle on growth. Same with retention—all these things. They don't—everybody does just a little bit; nobody really puts the effort in to make it happen."

It really made an impact on me. That was obviously a software engineering application of this theory, but I think it's really true. There are only a few things that really make an impact.

The reason that Pandora process was so flawed is because it ignored that, and it was trying to be politically correct and please as many stakeholders as they could—not impact.

Now, there's another dimension to this that's also going on here that makes focus so essential because you could say, "Well, just prioritize the things and work on, you know, the top priority." But the truth is, especially in organizations, if you try to work on too many things at once, everything slows down.

Now, of course, if your team is running Kanban or something, this is one of the fundamental concepts: this idea of WIP limits—work in process. The bottom line is if you try to work on a few things at once, you know, you will bottleneck, and things slow down.

You actually get more throughput if you limit the things, and I absolutely see that play out every day with teams. But the truth is, it's even more true and much more dramatic at an organizational level because now you're talking about senior leadership's attention and decision-making and removing obstacles.

If you get an organization trying to do even ten of these big things at once, they are just—it's just like the freeways here. You know, too much on there, nobody goes anywhere. It's the same principle.

So, focus is so critical because you really have to make sure you've only got a few things at a time going through your own organization, and they need to be the things that really can move the needle.

Now, I haven't told you how you pick those things that can move the needle, but the honest answer for that is that's where the smart leader comes in, where they really are studying the data, studying the business, the model of the company, and understanding those dynamics.

Alright, but the big takeaway here is prioritization is not focus. You really need your organization to pay attention to this, and this is a primary responsibility of product leadership. You know, working with the CTO, usually not the problem here; this is more on the head of product.

But to really understand that we are not talking about prioritization; we're talking about the top few things—the things that really can move the needle. In fact, I find most organizations spend way too much time worried about prioritization.

Honestly, this is another talk, but it's not only a waste of time; it's predicated on things that they don't know. They are guessing about how much money would be made; they're guessing about how hard it would be. They have no clue, though, so it's all guesses anyway.

So, I try to get organizations to stop focusing on this prioritization concept and instead learn to focus. Part of that is getting very good and fast at trying out ideas. We'll talk about that.

Alright, the second point I brought up was insights. Insights are actually where, you know, as an advisor, that's where I spend a lot of time with the teams. Now, we'll talk about those, but in most companies, actually, this is sort of what I see.

I'm staying with my gnome friends there, but they are literally not interested in the insights. They are not interested in the insights because they are too busy basically trying to satisfy the stakeholders. They're not looking at the insights. They're not even—when they're right in front of their face.

If you go in most companies, again, most companies are feature teams, and they do a little, let's say, usability testing on some design, and sometimes they actually learn something pretty interesting. You go try to tell a director or a VP of product about this insight that you just got about your customers.

"Okay, what are we going to do with that?" It's not really something they're interested in. They already have a roadmap for the quarter—not interested. It's like, where do insights fit in their model? They don't.

But this is what's essential. We need to talk about it. Strong companies, insights are everything. So, we get insights.

Then I want to be clear: the truth is insights can come from anywhere—anywhere. I was actually—I'm a big advocate of Ben Thompson's blog, Stratechery, which is really a business strategy, a little product strategy with mostly business strategy blog. But I love his thinking.

One of the companies I was with thanks to, they got a really good insight from another company in their industry, but a really good insight that led to some really good product work that really looks like it's moving the needle.

So, insights can come from anywhere. I'm not trailing off, but there are some major sources of insight. Qualitative insights—I mean, I put them first because, in truth, this is my favorite source.

Qualitative insights usually come from chat conversations with our customers and our users. They can be prospective customers; they can, by the way, be former customers; they can even be competitors' customers. It is amazing what you can learn, and I don't think there's a substitute for the face-to-face interactions we do with users and customers.

You just have to realize when you're doing that, you're not trying to prove anything; you're just trying to learn. But it is amazing what you can learn and just off-the-wall great insights. You know, they're very unpredictable when you do qualitative, but I encourage product teams to gather qualitative insights every single week.

Normally, we do that by trying out our prototypes with customers to see how they respond, but that's really a teeing up of a very high-quality conversation about why they wouldn't use this and what it would take to get them to use it.

So, I adore qualitative insights, and if I had to sort of credit any one source for the best progress in product from my experience, it's that. But there is no question there is a close second today, and probably in five years, I'll reorder these two because the quantitative insights are phenomenal.

We are talking about insights based on data. This might be data that we aggregate over time in our data warehouse, trying to better understand our customers. Very often, it's an A/B test that surprises us and inspires us to go figure out what is going on, which is often back to the qualitative testing.

But these quantitative insights are phenomenal, and so many companies today—the thing about the quantitative side is you really need some pretty significant volume of data. But then it just gets better and better and better.

So, it's not something that's especially useful to most startups and most certainly most B2B, but pretty soon you start to get serious traffic, you start to get some real history here, and you start to get some real insights on the data.

I should also emphasize a lot of the biggest insights are really blends. It's looking at both because quantitative might tell us what's actually happening, but it generally can't tell us why. So, the qualitative can help explain what's going on, and then you have that big aha moment, and then you direct the product organization to really fix that problem.

Now we've made a real difference. So, that's another great source of insights. In our industry, this is what I think is great about our industry: the technology foundation is always changing, which means, you know, from a product perspective, the way we think about that is there are things we can do today that we could not do yesterday.

So, that's what we are looking for—right? Things that are just now possible. And you know, this is by definition a moving target. We are always evaluating new technologies.

Now, of course, product people and our technology counterparts have to use their judgment. You know, some things are fads; some things are real trends. You have to decide; you have to separate the marketing hype from the reality.

So, it was actually—I've been charmed in my career, so lucky, but when I went and studied computer science, I actually studied artificial intelligence, which, if you knew the year I graduated, that would be like, "Do they even know what that was?" It was so—it's like, but back then, that was like the next big thing.

Of course, it was not even close to the next big thing, but the funny thing is there were like three more times where it became the next big thing, and it just sort of fizzled out. It wasn't until the last couple of years that it's like, "You know what? This is not a fad; this is a real thing."

Because now there are real solutions that are based on this. It's not just theory. The theory, honestly, hasn't changed all that much, but now it's practical, and you can use it for real.

Of course, there's a big reason for that, which is the volume of data that it's predicated on. But anyway, I love—that's what I—if I had to pick one thing that makes me love this industry so much, it's the enabling technology and that it is always getting better.

I go to China every year, and don't worry, I was not just in China. I did have a trip I had to cancel, but I was there well before anything was going on. But they're amazing what they've been doing.

China is just—I used to feel like Silicon Valley was pretty much ahead of the world. Not so much, especially in China. It's just what they've done. You know, they have three times the market we do in the U.S.—three times. And they also have some of the best teams in the world now.

Of course, they're a good example of the nonlinear value provided by data. When you get more and more data, you start being able to do things that you could never do before. It just becomes much more practical instead of a week for a test, a day for a test, that kind of thing.

So, anyway, technology's fabulous. And the last is there are insights in our industry, our market, our competitors. That would be an example from things like Stratechery, but there are always interesting things to learn in your industry and from other industries.

I love how the enterprise market is learning from the consumer market today and adopting a lot of the practices. But at strong companies, they live for this. This is that dynamic in strong companies. It's not just a once-in-a-while thing that a designer comes to a product manager and says, "Hey, this week we learned something interesting."

This is like what they live for. In fact, a big responsibility of the managers and leaders is to collect this and disseminate these learnings. They are literally there to connect the dots.

They are there to connect the dots. So, it's not—you know, a lot of people wonder, "Well, what do I do with this learning?" You know, just putting it out on Slack, it's not going to go anywhere useful.

First of all, it needs to be really curated. People have to think about how it fits in with a bigger picture, and then it has to be intentionally disseminated. Like, if you're a leader and you know this other team over here really should hear about this learning, you're going to go and share that learning or connect them with that team.

And if it's a general enough learning, you're going to have like the weekly or the monthly one-on-one. You're going to say, "Hey, we had some big learnings this week that you need to know about." Those learnings could be any of these things, right? It could be any kind of learning, but they are—they're sort of like a learning distribution machine, these leaders.

I find it so different than the not-good companies. It's like the not-good companies are not even in this game; they're not even trying.

Alright, so yeah, the core of strategy work is really always the same: discovering the critical factors. These are the insights here, and designing a way of coordinating and focusing the action to deal with those problems—those factors.

So, that leads us to the next big topic, which I would argue is where it really—this is where the rubber meets the road, if you will—action. We need to turn our insights into action.

Now, I have to admit, because in truth, I'm now all about the empowered product teams, I'm not spending any time helping anybody to become a better feature team. Believe it or not, I have been asked, and I'm like, "Not interested."

First of all, there's like a thousand other people that that's all they seem to want to do, so go to them. I want to focus on empowered product teams. But I will also admit that there are two ways of turning insights into action: the command-and-control way, which generally turns into a roadmap, and the empowered team way.

Now, this is going to yield—this is going to be a little bit of a complicated discussion here. Let me start by pointing out that it is not hard to generate activity. We have no trouble doing that. In fact, that kind of is what makes it a big problem.

I have to say, agile only made this worse. It really did. And for the record, I always advocate the team should be delivering with some agile process like Scrum or Kanban, but this made it worse because it made it even easier to crank out features faster than ever.

It did! It did! So, that was not the point, of course, but that is a consequence. And the hard part is getting the right things done—the things that matter, you know, the things that have an impact and can really move the needle.

I don't know if you've seen this little video, Dan. Monty Python, I love this one. Have you seen this one?

But oh, thank you! That's right, we're going to break everybody's eardrums again. This is literally what I see in my mind when I see companies doing the normal roadmap process.

Oh, I swear that's what's going on with your roadmaps. To me, it's exactly what's going on. They are just going in every different direction, and you don't—each one of those runners, if you're going to call it that, are like serving some stakeholder on some part of the business.

They're all doing something, but if you look holistically, they're making no real impact. That is what's going on.

So, what we need to do is we need to focus the minds. We need to focus the minds of the team, right? Their energy into action, and this is really what makes a difference.

This is where it's so clear the difference. What I really want to talk about, but I'll be honest, I'm a little hesitant to talk about it, is OKRs. So, I'm going to just jump in anyway. We'll see what happens.

So, let me start by professing this: I do not recommend OKRs anymore. I used to recommend them all the time. I was a very vocal advocate. I do not recommend OKRs unless they're already in the empowered product team model, which most companies are not.

The fundamental issue—well, most people know, and it's been plenty of years—just give it a try. Most people know that OKRs in most companies are a big waste of time. Just a big waste. Most of them have pushed it off to the side, and it's just OKR theater.

You know, it's easy to tell because they're given objectives and they're given roadmaps. It's like, so what do you think they're going to do? They're going to do the roadmaps.

And so the objectives—their OKRs are really not. Now, what's going on here is OKRs came from the empowered product team company model. That's the company that it came from. This was in tech; this was Google.

This day, around the model, if you take a company with feature teams and try to just overlay OKRs, you get the mess you see in companies. It makes no sense. I try to explain that. You know, people think—and it's not hard to see why—they all flock to OKRs. They're like, "Oh cool, they use it at Amazon. They're all making tons of money. It must be because they use OKRs."

That's really what they're thinking. So, they're thinking, "Hey, OKRs are actually pretty simple. Come on, they're pretty simple, right? Here's an objective; here's some results. Go for it."

But what's going on is that it's a true cultural mismatch. They are not successful—these good companies—because they use OKRs. They use OKRs because they go with the empowered team model that they've embraced.

So, the real issue is moving to the empowered team model. Now, if you've done that, that's what it's for, and I do advocate it for that situation. But I've really learned my lesson.

You know, because I can talk about all these things you can do, and then they gravitate to OKRs because they're so easy conceptually—super easy conceptually, much harder than the kinds of changes I'm talking about, like managers doing their jobs, coaching, investing in staffing.

I mean, we could talk about all the things that good leaders are really supposed to be doing. It's a lot easier just to do OKRs.

Alright, so let's talk about this. For OKRs to be helpful and meaningful, there are three things that are really essential. The first is you've got to have empowered product teams, not feature teams.

If you're not ready yet to make that transformation, you know, save yourself a bunch of time. But that is a big change. Hopefully, people know what I mean by that. If you haven't, if you don't, I would plead with you actually to read an article. If you just Google "SVPG empowered team feature team," something like that, it'll take you to this article.

It is happily—it was pretty popular. I've actually been writing about this stuff for years, but for whatever reason, I think I hit a chord with that one, and people are like, "Okay, now I understand."

Unfortunately, yes, we're a feature team. They understood that now. So, you really need to look at that. It's a difficult transformation. I mean, all the companies that are trying to do a digital transformation, they don't realize this, but what they really need to do, and what they are if they want to succeed, is convert from feature teams to empowered product teams.

But that is not a minor change. But for you, the good news is it actually requires these people called product managers. But of course, I'm not talking about the project manager product manager. I mean a real product manager.

In fact, I used to help you. You know, I have not been shy about using the term "a good product manager is the CEO of the product." But I would get a lot of frustration and confusion with that, and it took me a while to figure out what was going on.

Then I realized it: they're talking about feature team product managers. A feature team product manager could not be further away from the concept of a CEO of a product. That's so silly. It's like literally pointing to the project manager and saying, "You're the CEO." No, it's not even close.

The CEO of the product concept comes from the empowered team model. That's where it comes from. Because like a CEO, if you think about a startup CEO, the designer is responsible for a usable solution, and the engineers are responsible for a feasible solution.

But that founder is responsible for making sure it's valuable—people will buy it—and viable. It works for a business; you can market it, you can sell it, you can make money from it, you can fund it. That's exactly what a real product manager is responsible for.

So, you know, that's a big difference right now because if you think about it, on a feature team, nobody is explicitly responsible for value or viability. It's dispersed among the stakeholders.

It's basically if some executive asks for something on the roadmap, they're taking responsibility for that. They don't necessarily realize that, but they are. If they say, "Add this feature," they somehow believe that feature is valuable and that it's okay to do.

In an empowered product team, they don't do that. They give them problems to solve, and the product manager is responsible to make sure that solution is valuable and viable. So, this is the real product manager job.

Well, I should say this: in the industry I grew up with, and I'm comfortable saying this, the same is true as Ben Horowitz, and we grew up in the same companies. This is what we mean by product manager. We do not mean project manager; we do not mean feature teams.

Most of us would never have gone into this industry if that's what we thought our job was going to be. So, the good news is I think as companies move to this, they realize, you know, they have designers and they have engineers, but they really need to invest in true product managers.

Okay, the second thing they need is another thing that messes up OKRs in companies is that each manager does their own set of OKRs. So, like the director of engineering does a set, the director of design, the director of product, and what do you think happens? They pass them down to their employees, right?

And then on a product team, the product person probably thinks, "We're working on some company thing," but no, the designer says, "No, I'm supposed to work on this because this is what my boss told me to work on," and the engineers are like, "No, we have to work on this."

So, of course, the whole OKR thing collapses under its own weight right there. So, I tell them, "Look, the other thing you need to do is if you're going to embrace empowered product teams, in OKRs to be meaningful, stop doing that. It's just product teams that get objectives—just the product teams."

So, and the other thing I say is until you get good at this, stop doing individual OKRs. Those are just confusing the issue, and they're not important. Focus on the team.

It's all about the product team. Just be clear that doesn't mean the product team is not the organization of product managers, right? This is a squad—a cross-functional, durable, hopefully close, co-located. That's another topic I need to spend more time on.

Yeah, you know, the co-location. I've been very vocal about the benefits of co-location, but anybody who's followed anything knows it is not very politically correct to say that anymore.

I genuinely believe it. It's motivated by selfish Silicon Valley, mostly venture capitalists that want to—they know they can't afford people here, so they want to stay here.

Anyway, I think it's BS, and I totally subscribe, and I'm going to share more of Amazon's philosophy on this, Netflix's philosophy on this, because they've taken a very hard stand for co-location.

So, you want to do that remote stuff? Fine, but we're actually here to innovate. And I'm not kidding; it is a big difference. I'm not saying it's impossible to work remote, but boy, your odds go way down.

Everything I talk about is not a guarantee of success, but it's about increasing your likelihood of true innovation and success, and that is not helping you.

And I scored a lot of points in the room with that, I know. Alright, so I don't care; it's true. It's just true.

So, somebody—I think needs to say it. Alright, and the last one is active leaders, not passive leaders. So many people think, you know, that little Monty Python video—that's what I see people do with OKRs.

They literally say, "They go to the teams and say, 'Pick your objectives. Tell us your objectives. Go out, do your thing. We'll look at what's going on at the end of the quarter.'" And every team is going off in its own direction. I'm like, "What are you doing?"

That is not what OKRs are about. The objectives actually need to come from the leaders now, not the key results. Those come from the teams, but the objectives come from the leaders.

That's how the strategy is turned into action. If the strategy is, "Look, we need these three teams. We need your teams to focus on this onboarding problem. We have got to fix that; it is not scalable."

You guys need to focus on the onboarding problem, and between the three teams, there's enough brainpower there. We think that's going to—we're going to make a difference. That's where objectives come from.

Now, those teams, they use what empowered autonomy really means: they're able to figure out the best way to solve those problems. So, we're not giving them a roadmap of features; we're giving them problems to solve.

But they are not random problems. They are not problems left to teams to choose. Now, don't get me wrong. One of the things we love is when the leaders share the strategy. They literally say the strategy, like, "We know onboarding is a problem. We know 80% of it is manual."

Whatever these are, the insights we would like the teams to think about how they could help on this. We love it when teams go, "Hey, we would love to work on that problem because we think we have some really good ideas to pursue that."

We love it, but even if everybody came back and said they want to work on the same problem, we'd have to go to several of them and say, "I'm sorry, we have other problems we have to solve too."

So, it's a responsibility of the leaders. Again, I refer to this as active leaders. I don't want it to be confused with command-and-control leaders. These are not there to micromanage.

In fact, I'll talk about this next. I think it's really more like servant leadership that we're talking about. So, these are the three things that have to be in place for a product company to really get value out of OKRs.

If you don't have these three things, save yourself a bunch of time at the end of the quarter.

Alright, so the fourth part—if you remember, first was focus, then insights, then actions, and the fourth one is management.

Now, the truth is no strategy survives first contact with the actual reality. So, there will be a lot of learning, and the question is, what do you do now?

In most companies, that's kind of the world, right? Roadmaps. Because this is how teams and organizations manage their work. This is nothing new; it could be one of a million roadmaps out there.

So, there's nothing special about that other than it's terrible. Look at it; it's all output. It's all output. Oh, the first one I grabbed, but they're all the same. They're output—a bunch of dates.

This is not empowered product teams, just to be clear. This is what feature teams do.

Alright, so let's talk about strong product companies. The leaders have this servant leadership mindset. They are really there—what that really means is, okay, they've given the teams servant leader does not mean passive or anything.

That means they've given the team the objectives, but they know that things will come up. A team comes back and says, "Hey, we didn't realize we had a dependency on a platform team, and we really need some help to get their help."

This management is not just there to watch; they need to engage. Go talk to the platform team. They might find out that, oh, there's a piece of technology we didn't realize we need. We need help with that; we need to get that technology in place.

We need to expedite this; we need to make something happen. We have a stakeholder that needs some real attention, let's just say, and then they need some help to kind of get with the program.

So, you need to help there. In these good companies, the manager has a very hands-on active role. The difference is they're not micromanaging; they're removing obstacles for the team. They're letting the teams come up with the right solution. They're just there to help facilitate.

Alright, yes, this is that same point. Please, it's not about less management; it's about better management.

Alright, okay, so that went fast for me. I didn't have a lot of time. So, in terms of product strategy, summarize this: it's critical to focus on the key critical business problems—just realistically two or three—the things that will really have a chance to move the needle.

You know, this isn't really that hard. Most of the time, I get—I mean, it's hard politically. It's not hard to know what the right things are. Honestly, it's usually what's being talked about at the board of directors level.

They know what the real levers are for the business. It might be unhappy customers; it might be growth. That might be, you know, a very common one in SaaS is retention. Retention is—if that number is not good, everything falls apart. They know.

So, it's not that hard to know the things that really matter. The problem is, in most companies, you've got a lot of different stakeholders and executives, and they all have needs. Or at least, yeah, they do have real needs. I mean, their perception of solutions and stuff, but they all have needs.

So, it becomes more a process of trying to do a little bit for everybody—back to the performance analysis problem.

Alright, second, generating insights on how to attack those problems. Now, this is where that culture comes in, where you really need a culture that is constantly learning from your customers, constantly learning from the data, constantly looking at new enabling technologies, constantly following the industry so that you can prepare to identify the insights and then leverage them.

There is one other point I should make about that. In every case I know that the leaders really are good, and they are seeing these insights. It doesn't happen on its own. They are always preparing.

So, they study the business; they study the dashboard; they understand the economics of the company; they understand the dynamics of the company, like in a marketplace. They understand what we call marketplace health.

They're looking at all dimensions of the marketplace. You know, at Amazon, it's not unusual for a typical leader to be tracking several hundred KPIs every day. They are—they're not talking about just—they have a deep big-picture view of the business, which means when something really is spotted, they can see how that might be a great opportunity.

They can see those—they're doing their—I say this a lot: they're doing their homework so that they're prepared to not miss that opportunity that comes in front of us. The opportunities are always there.

Alright, you need to coordinate actions for each team. I didn't say this explicitly. Some people—this is another one of those weirdos. I don't know where the route is, but some people get really upset if two different product teams are working on the same objective.

They think that's somehow like, I don't know, inefficient or whatever. It's like, "Oh no, that is really common." In fact, it's often really, really valuable.

Now, there's different kinds of ways of working together. Sometimes, like you're the platform team; I'm the common experience team, and we're working—you're going to do some new service for me. That's kind of obvious cooperation.

But another kind might be it's a really hard problem, so we've each been asked to use our own technologies to solve that problem. The truth is, and management is not hiding this, none of us may succeed. They're hoping at least one of us makes the moves the needle.

That's really called a risk management, risk mitigation technique. Another one—and this is actually one of my favorites—is if it's a really hard problem, it may totally be justified to take two or even three product teams and ask them to work together to solve it.

That's sometimes called a swarm, if you've ever heard, where they actually get together, they put the brains together, and they're, you know, hopefully, the combination of our experience and our skills. It's like, "Yeah, we can see now."

We all sometimes swarm on discovery, sometimes on delivery, sometimes on both. But that is, yeah, that actually can be a lot of fun.

You have to realize a lot of the problems we're asked to work on are really hard problems. They are not trivial problems. You're not being asked to add an edit button.

I say that—I literally—there was another article that came out on OKRs the other day, and his first example of a supposedly good OKR objective was an edit button. Literally, that was the first one. I'm like, "What is going on?"

There is so much nonsense out there. Totally, somebody totally missed the point of this stuff.

Alright, and then finally, it takes active, engaged, capable managers to manage this work and facilitate the interactions that need to happen. Especially, this is more and more true the larger the organization.

Management needs to connect the dots. The head of design, hopefully that's obvious, they need to connect the dots. It needs to be one experience. The head of engineering needs to connect the dots. You need an architecture that makes sense holistically.

A tech debt strategy, by the way, is a classic example of what we've been talking about. You can't tackle tech debt effectively with every team doing a little bit. It doesn't work. That's the little refactor frequently that they will never do—the magnitude changes that are needed to really address the issues.

Alright, so those are the four big things. Let me try to put all this into perspective just so that you hopefully have a frame of reference here.

The product vision is really describing the destination. I didn't talk much about vision; I've talked about that a lot. I love product vision. It's very inspiring; it helps us recruit great people, but that's sort of a given.

It's sort of the input to strategy—that's where we're trying to go. Product strategy helps us decide which problems we need to solve to make that happen. That's absolutely, I would argue, that's the most important part.

Product discovery is actually where we figure out the tactics. Just to be clear, roadmaps are tactics, but that's what I said. It just skips strategy. They're going straight from double revenue to a bunch of tactics. There is no strategy.

Strategy leads to a bunch of problems to solve. Each of those are solved by the team in discovery. Discovery is just trying to find a solution that works. At the end of the day, they will probably build out some features, but they're building the ones that they actually have verified solve the problem.

For those that don't know, that means the solution is valuable, it's usable, it's feasible, and it's viable.

Alright, and finally, delivery builds that solution. That's the one most people understand, but those are the four—that's sort of how the four main concepts in product really relate.

Okay, I referenced a couple, but I've tried to—you know, I've been a student actually of product strategy my whole career. I admit I like discovery best because to me, that's just fun—literally solving our problems, prototyping, testing—that's just fun.

However, I would say that the strategy skills are more valuable, at least for me career-wise, have been even more valuable because if the strategy's not good, it's kind of the rest don't matter. It doesn't matter.

So, even though I love discovery so much, I would argue that the investments in strategy really help. So anyway, I've been a student in reading books forever. There, I found two that I think are good and useful.

Most of them fit into that category of the paint-by-numbers thing: you know, do this and you'll come up with something. I love "Good Strategy, Bad Strategy" and "The Art of Action."

To be honest, this guy writes military history books, but it turned—you know, the truth is military strategy has a lot of similarities with product strategy, and he seemed to figure that out, and he decided to write a book on that.

It's one of the best ones out there. If you haven't heard of it, he doesn't actually even reference OKRs, but he's really talking about OKRs.

Yeah, I don't even know, though, that he knows they exist, to be honest. I checked the date; it's not like he wrote it when OKRs were big, and I was sort of surprised about that.

But the length he's describing the way OKRs are supposed to be used, and I literally did a—got the Kindle version, searched nothing.

Okay, so for those that don't know, the second edition of the book is a hundred percent rewrite from the first edition. So, even if you did read the first one, I hope you do read the second one.

And if you like that topic, discovery, I definitely hope you read it. Like I said, I am in the middle of writing a new book, which is called "Empowered: Ordinary People, Extraordinary Products."

That's one point I didn't really get across, but I probably should share with you. I told you the four companies that really impacted me and motivated me on this and impacted my thinking.

One of the things that I think most people—when I—the biggest argument I get against empowering teams from CEOs is they think they can't hire the caliber of people that Google hires.

I try to set them straight that Google's people are much more like their people than they think. I tell them one way I know that for a fact is for so many people that I have introduced into these companies, and they tell me after six months that they have done more in those six months than they had done in their previous several years.

These are the same brains, same bodies, same people. The difference is they finally landed in an environment that would let them do work.

So, I am absolutely, you know, convinced that what's special about the four companies I talked about is how they let their teams do their jobs—not that it's some sort of DNA filtering or something going on.

Alright, okay, so do we have time for questions, Dan? We want to capture it so it gets on the video, so you have to have a mic, Dan.

Some questions? Raise your hand; we have mic runners. Then we'll get a mic to you, and just wait your turn.

Awesome! You mentioned the military command intent.

It's command intent. I use that, yeah. Not everybody—well, you don't have to repeat the question with the microphone.

So, command intent, I use the term strategic context for that, and it's a really important point. It's not in this particular talk, but it is an important point on the empowered team concept.

You know, why—if, look, imagine your eyes, you know, they call them squads in the military. Imagine you're a SEAL squad. If you were—if it was command and control and you were trying to do something like capture something, and you literally had to follow some recipe, you're dead.

Literally, the way they are true examples of empowered teams, they are given an objective, and they're given skills. And by the way, these squads are by design cross-functional. They have different skill sets in their medical, long-distance shooting, demolitions—all these different skills.

And they have to be able to make decisions themselves and figure out the best way to do it. Now, that works if you do two things: you give them a mission—the objective. By the way, in the OKR, you give them an objective.

And two, you've got to give them the big picture. They need to know how their work relates to all the other squads that are out there and what the overall objective is. That's called command intent.

I use the term strategic context. The product strategy is part of the strategic context, as is the product vision, as are the business objectives, and also the other big one is the product principles.

So, yeah, it's a really important concept that applies in our world too.

I considered using some of the military terminology, but it's got some baggage.

Yeah, sure! Thank you so much for this presentation. I had a question about a product team. I think something I really struggle with is we own a really large product, and it's really hard to help people focus when you're getting inundated by so many questions about really large historical old products.

I was wondering what tactics or advice you have for how do you filter out some of that noise from the team, but also we have to adequately own the product.

I mean, only today—so, I don't know, just ideas on how we could better manage that.

What you're saying, though, is you've got a product—a big product—and you're getting a lot of questions about that product, and you're the product manager?

I'm a manager.

Oh, okay. Well, of course, everybody else in the room is probably thinking that's normal, right? We all get tons of questions and tons of feedback. We have customer service; we have sales; we have customers. We've got questions coming from finance. We've got a lot of that.

And of course, if it's bugs and, you know, you're starting to the point where the teams are telling you that just the cost—it's often referred to as "keep the lights on"—is basically consuming their teams, you might be saying that.

That definitely happens in companies, and they're like, "We can't make any forward progress; we are just treading water barely." And it's not very motivating if that's what's going on.

Then, you know, the company has to make some hard choices. I would argue the focus probably hasn't been happening, and now it's non-negotiable. It has to happen, and boy, it's high stakes to do that.

So, I don't want to be, you know, there's a lot of potential things that could be causing these symptoms. So, without sort of going into a whole back-and-forth of how many engineers do you have and how many designers and where are all the inputs coming from and stuff like that.

But as a principle, though, I don't want to say with just one other thing, which is you do want the product managers that work for you to be getting the feedback directly. We do not like filters.

So, one reaction to that might be to shut things down, you know, so that they don't have so much noise coming in. But it's really essential that the product manager hear all feedback.

Yeah, sure, Victor. Can you talk about the breadth strategy for at least HD? It's like if you must three people, what he wanted the first time VP, and how do you see strategy there when the sources are low, and you still try to get the first version?

Okay, well, the first thing I would say is that strategy is not like a luxury for when you have big organizations. Strategy is about making much better use of the limited resources you have.

Most startups, you know, there is this—I don't know. The truth is I meet a lot of startups. Some of them, it's like, how did they get any funding? They don't. Like, I don't know.

So, I don't want to say—so some startups are great, and some of them are not, you know, that. But I would argue a strategy is all about smart use of resources. In fact, we can take this back to that Pandora example.

I mean, I already said I think it was insane for them to try to go public in that space with only 40 engineers. If I was on the board, I would have raised hell about that. That's just crazy, and I think they ultimately paid the price for that for sure.

But if there were just 40 engineers, then they literally had the worst possible process because you could argue that with only 40, if you don't have a super smart strategy and you don't pick really well, you're toast.

So, strategy is a weight; it's a force multiplier, right? It's not a luxury.

So, suggest I can pull off—you mean strategy as a process, not as an outcome? Butter humans are something documented, which you really present your name?

Oh, maybe we should talk privately. Yeah, because there's a lot there we need to unpack.

Yeah, but strategy is not a process, to be clear. It's not a process; it's insights that turn into action. And you can document it if you want; who cares?

But what really matters is you've got to make sure your team understands it. But let me just say, if in the scenario you described, a startup working early stages trying to get to product-market fit, you better be good at the stuff we're talking about.

Yeah, hi! So, how do you keep everyone happy and still be focused at the same time?

No, I love that question. How do you keep everybody happy? Well, that's super easy to answer: you don't.

No, I don't think it's possible. I mean, you can keep them happy at least until, you know, the stock drops through the floor. But no, yeah, this is not—I think this idea of keeping everyone happy is fundamental.

Look, that's why the CEO doesn't want to focus. And, you know, it's not just like they're trying to please people; it's fear of missing out. They're like, "Oh, all these things could be important, so let's do them all."

I mean, it sounds safer, but no, it's really not. And it's, yeah, we product people have to make these trade-offs every single day. It's really important.

Now, I do believe in not being a jerk about it because some product people are. They're like, "Because I said so," you know, it's that kind of thing.

No, I believe in full transparency, being very open with the stakeholders, really showing them the strategy, showing them the insights, showing them the reasoning.

In fact, I'm a huge fan of the written narrative to really spell it out for stakeholders to see why you decided to do something. It's like, "Here, take a look. You know, the CEOs read it. Make sure you understand I'm not trying to be arbitrary here."

So, the goal of keeping everybody happy is not, I think, a realistic goal. How about keeping everybody employed?

So, there was—yeah, go ahead.

What would you recommend somebody buy shoes? What do you think I should be mindful of?

Can you say—I just—there was just some—say that middle part again. I'm sorry.

I'll say that I'm considering making a transition from sales to product management.

Okay, so what do you recommend for somebody like me?

These shoes—considering that both—and what should I be?

Oh, right! Moving from sales to product. I definitely know some people that have moved from sales to product because, you know, in sales, you've got that frontline experience with customers.

The truth is every single person that moves from product to product has some gaps and some strengths. There's a tool that I published as part of this coaching series, and I would strongly encourage you to self-assess.

Just self-assess. I mean, with your background, there's some things I'm pretty sure you're going to do pretty well in, but there's going to be a lot of areas that, at least from just your sales experience, you haven't said anything about education or other jobs you would not have been exposed to.

So, you will probably have a pretty substantial set of things to develop, and you can get to work on those things. In my experience, most people, they really want to get into product, but they have to do the work.

There can be a lot of work. It is definitely not an easy job unless you go to a feature team, and it's pretty easy.

Hey buddy, I'm a product manager at Springboard, and I think we're in the middle of this transition from being a feature team to hopefully an empowered product team.

But building on the question of how do you keep stakeholders happy, how do you say no to them when they come to you, and when they've been trained to come to you with feature requests every quarter for planning?

Especially when you're asked to defend and compare and contrast their requests against like everything you have planned.

I understand all too well. I mean, you're describing feature teams exactly, just to be clear. So, you're not alone for sure.

But the question you're really asking is how do you transform your organization to a modern tech-powered product organization? And that is not a three-minute question. That is a major topic.

But I guess I could say I'm writing a book about it. Fear of people telling up, you know, this is wrong or this can be proved, and fear of the people off to make me change things.

Yeah, yeah. Well, I mean, this is—you're not just talking about like the, like you said, different swing feature teams and empowered teams. You're talking about a cultural change in a company.

I mean, the kind of company you're describing, you know, it's not the kind of place most people want to work. The fear is not a good thing, you know?

And I will say there's a great—the people have heard me talk before now. I'm just a huge fan of Bill Campbell, Coach Bill Campbell. He died a couple of years ago, but he's considered the best coach ever.

He actually was CEO here at M to it for a few years. I just remembered that, but just an awesome guy.

Anyway, he's—I have all these great quotes from him, and one of my favorites was, "There is nothing more powerful than an empowered engineer."

And I really believe that's true because if you—I do get to work with a lot of cool product teams, and inevitably, the real innovations come from the engineers.

And I always encourage good engineers to work at a place that can use their skills. So, I mean, if you—hopefully, you can convince your management that they should use your skills, but if not, you should definitely—there are lots of companies in this valley that love to use engineers and let them do—like Steve Jobs used to say, "We don't hire all these people to tell them what to do; we hire them to show us what's possible."

So, yeah, sorry! [Laughter]

[Music]

And then, you know, at the company level or the level you have, increase revenue. I think that is—well, first of all, good part of what you said is their goals, right? You didn't sort of rattle off a bunch of features on a roadmap. You talked about goals.

That's good. You talked about some high-level company goals; you talked about some team-specific goals. The only part that was missing was product strategy.

And so I would argue your good example—now, there might be one, but you didn't share that in there because that's the missing part. That was the underpants gnome.

No, you have the big goals; you have the profit at the end, but it's that middle part. So, that's what I would encourage you to work on is that clear articulation of a strategy, which will then, of course, cause you to revise your team goals.

And again, they don't all have to be the single—it's normal in a larger organization to be pursuing each team pursuing different problems, sometimes the same problems, but lots of different problems.

But they all need to be aligned. One of the virtues of OKRs is it's a lot easier to align our organization and make sure we're going in the same direction.

But that doesn't mean like we're only working on what's—one you said onboarding were, you know, check out.

Well, that's—that's kind of the presentation I am, but I understand where you're coming from. In fact, one of the parts of the book I'm writing on right now is a very detailed case study because I want people to not just think it's theory but also see how it all plays out.

So, it's got the actual team topology; it's got their actual strategy, their actual objectives. And so hopefully, to be able to answer that question.

But I'm also writing a bunch of articles about to publish more that I think will give you more to work with, but it's a big topic.

There was—yes, over here.

Hi, and so that—thank you so much for good. So, what about somebody here?

You so partly it's a similar answer to the person who's coming from sales. Obviously, finance and sales are not the same, but you will have very different—you know, you'll have similar a profile of things that you need to work on.

There is one other thing that I'd like to mention that applies to the salesperson as well. Don't worry so much about what company you go work for because even if you go to Amazon, which is—I mean, they are really good at what we're talking about.

They also have a demanding culture, which isn't for everybody, so you kind of have to know that. But they're really good about—while we're talking about that, said I know teams there that are feature teams.

So, even in great companies, some teams are, you know, usually because they haven't earned the trust yet of the leaders. But the point is what matters more than the company you go work for is the person you're going to work for.

Literally, the person—especially if it's your first job in product, you want to find somebody—there's really two things I tell people to look for. Look at their—look on LinkedIn, see where they've worked before. If they've worked at a good product company where they know how to do this well, that's number one.

Number two, during the interview, you want to say, "Look, I'm coming here to learn from you, and I am willing to work very hard. I want to know if you're willing to coach me to become great."

Some people—well, most people will be flattered; they'll love to hear that. Some people will say, "I have no time; I need people ready to hit the ground running."

But what really matters is for you to find someone who's willing to invest in you, and it's—to be honest, it's usually a year or two of work of developing in this situation if you're brand new to product before you really at that level you really want to be and can go on.

So, it is much more important, and the company is the manager. You've probably all heard that line too; it's so true. But people join a company, but they leave their manager. That's really true.

So, don't get me wrong. If you go work for Netflix, awesome. But if you can't get somebody who used to work at Netflix, like a product director at Netflix, and now is willing to—they're at another company, a smaller startup, and they're looking for somebody like you, that's great.

Yeah, always. And always like, is it okay to—like, no, there's probably the little story behind your question there too, I'm thinking. But to be clear, you know, we all know those product manager types that feel like they just have to know everything or they have to sort of appear like they know everything.

I've never seen this work. I think it backfires. So, you know, making decisions is one of the most important things we do. However, they should—you know, if the decision has to be proportional to the consequence, there's a lot of minor things which frankly don't even need to be decisions.

You probably could defer to your designer, defer to your engineer. It's

Hard not to be empathetic when you really know someone. It's really easy, unfortunately.

Especially for consumer products, this is a bigger problem in the consumer space than in B2B. Interestingly, in consumer, you know, any of millions of users—like the millions of users—it's abstract. It's like, whatever, I'm never gonna make them all happy.

But when you really have names and faces and you know them, it makes all of product more satisfying and meaningful. One of the challenges is, you know, we're not all working on something like Google Maps, which is something everybody can relate to. It's awesome, or Google Photos. A lot of this stuff is like, "I'm doing payroll."

Hey, I picked that on purpose! Come on, I know where I am, but we're doing payroll. It's not like Twitter, right? It's not like I'm telling grandma about it that way.

But I have found that when you take your product manager, when you take your engineers to the payroll departments of these customers and literally sit down with them—or even better, invite them to dinner with you that night when you visit—it's a whole different thing.

Honestly, I have seen this so many times. They actually tell you, for example, what happens under stress on payroll runs, what happens when there's a problem, or when you've got somebody yelling at you for getting this done by a certain time, or when there aren't funds in the bank to cover this and you've got to talk to finance.

They realize that, oh my gosh, these people have super hard jobs. And you know what? I think we could make it better for them. So I found that works.

I want to go further, especially with developers. Developers are, I mean, obviously I'm biased on this, but they really want to help people. They really do. I think that one of the biggest crimes in our industry is when we shelter developers. A lot of developers feel like the only way they can help people is by helping their colleagues by writing their tools.

So they love doing tools, and some people think that's all developers want to do—innovate by doing tools. No, it's just that they know their developers that they work with. If you introduce them to these payroll clerks and managers, they are gonna care about them too. I guarantee it.

Yeah, I even sit and thank you again because I started my part of my entire thanks to your book as well. But then, I did start with that as a question about focus.

There's a flip side to focus, right? Because focus also means that you're putting your eggs in one basket, or a small number. Yes, one of them. No, that's okay for Google, right? Because they have a lot of engineers; they can do a lot of things.

But for a smaller company, you know, hundreds of other people—maybe five other people—you can have maybe two or three packs. That's all clear. You're making my argument. You are Google. It doesn't matter; they have more money than God from AdWords. They do, so they can and they do spend it.

Nobody could even count how many things they're working on, but most of them they do, and that's fine because they have AdWords.

I'd add some, but you're making—I'm just trying to point out you're making my point. In a smaller company, you can't mess around like that. In a smaller company, you don't have nearly a thousandth of the resources they do.

So, you know what? You better make good use of the people you have. That's the point of strategy. You have to make sure you are doing good use.

What I was trying to say is if you just say, "Well, we're not sure; we're gonna make 20 bets and we have 30 engineers, so we'll just do a little of this," this is the fear of missing out. You know, we're just gonna—

All I'm saying is that's a guaranteed way you're gonna fail. You argue that maybe Pandora made like one bet, and that bet was the music. Zero, right? That was dead, and they said, "This is what we're going for. We have 40 engineers; who cares? I have people working on this music thing, and that's my partner. I'm gonna go off with this."

Right? That could be an argument. I would argue they didn't. I mean, they really didn't make any conscious bets. They abdicated that responsibility by just giving it to the stakeholders. That's what I meant by absence of product.

I would have argued, you know, and I wasn't there, but yeah, and it's all hindsight. But I would have argued to them—I hope I would have known to say this—that they are a tech-powered music company.

At the time, it was all about their deals with the studios, and they were dominated by expensive costs. That's why they said they couldn't have more than 40 developers, because all their money went to pay for rights.

I would have argued, "Look, you are in a tech-powered business. You have to have a machine for continuous innovation, and if you don't, it's only a matter of time." They did have a head start, and they lost it.

Yeah, but I would argue that even with only 40 engineers, even with the best strategy in the world, that's not clear. But it would have been a much better shot than just random—let's see what everybody— a little bit for everybody.

Mariana, actually, I'm a product manager on Google Maps. Oh, we actually do so many user interviews as frequently as possible because it's just so enlightening.

But my question is more about—I love your framework, and the point in that framework that I'm most interested in unpacking is the management part.

You know, the tuning for certain leaders has been better management, not less. But I love to hear you demystify what management means and what does product management and people management really entail. If you have a framework for what good management is, I know there's "Trillion-Dollar Coach." I would love to hear Marty's thoughts.

Oh, I would like to think that anything I say is consistent with "Trillion-Dollar Coach," but this is more—yeah, and I wouldn't frame what I have as a framework because I don't know if it deserves that level.

It's more that there are responsibilities of managers that are absolutely critical. I think because we are now talking about just, to be clear, first-level managers of product managers.

Okay, good. This is what I consider the most important role for really making all this stuff happen, so this is the one I like to talk about.

So, number one is staffing. Staffing, and you know, all of these things are on their own right, so I don't want to do too much of a disservice, but staffing is huge.

The main thing I'd say is good managers of product managers do not depend on HR. HR is a sourcing model, but good managers are using the recruiting model.

What that means is you are going to events like this, and you are getting to know people, and you are building a network—a pipeline of people that you think are right for your team. That's really important.

And then, man, I've worked for years to get the right people, you know, where you build trust and you know, waiting for the right point in their career. But the point is you go recruit them; you do not just look at resumes that are coming through HR.

Second is coaching. The biggest responsibility I would argue you have as a manager of product managers is to coach and develop your product managers.

Of course, actually, Google has a good history with that, and I hope many of the people I have sent over there have told me how it's real. It's like they benefited from active coaching, helping people reach their potential.

And then the third is this point with the team objectives. Because you, as that first-level manager, you're really the one who can herd the strategy into objectives.

So you're in the best position to see what each team should really be best positioned to do. And you know, you're right in the middle of that negotiation between what you need them to do, what they think they could do, and what is necessary to be done.

So, those are the three fundamental responsibilities of managers. It's also true that some managers are leaders of the organization, and those people have even more responsibilities.

Now we're talking product vision; we're actually talking product strategy, we're talking product principles, and a big evangelism responsibility, which is really back to Tom was asking about with the strategic context.

Yes, and if you're interested, I did write an article called "Empowered Product Teams" that talks about the responsibilities of managers, and that's really been a big focus of mine.

I want to see a lot more people get it. [Applause] [Music]