Transcription
All right, thanks, Andre. I appreciate it, and thank you, everybody, for coming to this conference. I appreciate you inviting me here and having this chance to talk to you.
I have a new talk that I've been testing, actually prototyping. I'm a big believer in that, and I have decided this year to really focus on some adjacent set of problems, but bigger problems. I want to share that with you.
I will warn you in advance that I'm going to throw a lot at you. Some of it will probably be uncomfortable. One of the things I've learned as I do this longer and longer is that I don't think it's helpful to sugarcoat things. You know, it's more useful, I think, for all of us to be honest. So I'm going to be frank on a lot of this stuff—maybe too frank, you will see.
But I want to share with you some of the things that I think are important that not enough teams are really dealing with. First of all, I should say what powers me, what keeps me doing this, is that I am introduced to a lot of companies. I've been in the industry a long time. I'm based in San Francisco, so you get introduced to a lot.
What is amazing to me is the difference between how great product companies work and how all the rest work. To me, that difference is huge and unacceptable—really embarrassing at this point in our industry that there's such a massive discrepancy. It's very frustrating.
Now, normally, sometimes I have to wake this up here. Try it now. No? All right, old school. Normally, this is what I like to talk about: product discovery. It's my favorite topic. Honestly, I could talk all day. For those of you who were with me yesterday, I did talk all day on this topic—just this topic. I love it.
To me, what I find incredibly inspiring about building product is that we are solving hard problems, and that's what we're there to do. Between product design and engineering, we're there to work together and solve hard problems.
Now, the way I like to frame the world is this: it's called discovery, and there are four big risks in product, always.
1. Will the product be valuable?
2. Will people buy it or choose to use it?
3. Is it usable? Can they figure out how to use it?
4. Is it feasible? Do we know how to build it?
5. Finally, is it viable for the business? Does it work for the different parts of our business?
That's what discovery is—finding solutions with those characteristics. This is what we mean by the right product.
I love that, but I will also tell you that at this point, I have worked with a lot of organizations where I teach the teams how to work this way, and I find out later that they're not allowed to work this way. This is just, of course, a dagger. This really bothers me, and it especially bothers me because I know that unless they work this way, they are almost certainly going to go out of business.
It's not usually tomorrow, but if you follow the news in the U.S., almost every week, a major company falls to Amazon. The difference, in my book, is that Amazon runs like I advocate, and most of these other companies—well, really all these other companies that have gone under—are not even close.
To me, it's a pretty serious topic that we need to talk about. First, let me try to make this real to you. When we talk about a truly empowered team versus the rest, did I not use it? I've tried it. Well, thank you.
In most organizations, teams exist to serve the business—literally. I mean, you often hear that phrase: they are there to serve the business. But even if it's not explicit, it's implicit. The business gets together and gives the teams roadmaps and says, "You know, build these features." That is how it is in most organizations.
But in great organizations, they have a very different model. Teams are actually there for a different purpose. They are there to come up with solutions that our customers love but that work for the business.
Now, I hope you can see that's not a small difference. That is a massive difference. Everything is different.
Now, we often refer to the second as the product mindset or a product culture, and we refer to the first by various derogatory terms: IT mindset, project mindset, feature factories. You've heard all these different flavors of them.
Now, I would also point out that in the first model—this is going to be a little harsh—the first thing I would honestly say is that the first model is the vast majority of companies in the world. This is not just Silicon Valley versus the rest of the world. This is true in the San Francisco Bay Area. We have both kinds of companies—too many of the poor ones.
But I will also tell you that if your company is running in the first way, they really don't need product managers in that model. It's not product management; it's literally a product owner, of course, just administering the role in a scrum team, or it's a little bit of project management, a little bit of business analysis.
That'll be a role I hate to tell you, but if you're a product manager—a real product manager—you’re probably not very happy if your company runs in that way. I meet people like this all the time. They end up in a company like that and say, "You know, can you introduce me to a company that's a real product company?"
So that's kind of a harsh reality. But the real question is, why is this the case?
Well, let's talk about it. I'm going to talk about this idea of truly empowered teams. One of the reasons that's such a difficult topic is I have to talk about your entire organization. You know, when we talk about transformation—in fact, you've all heard the term digital transformation—my guess is almost all of your companies have a digital transformation initiative of some sort or another.
You may know that those almost never work, right? They almost always fail, and it's because they are not willing to really make the transformation that I'm talking about here. So that's why I say this is big and broad.
The first thing I want to say about this idea of truly empowered teams is that I am not even close to the first person to say this is a great thing. This is old news. This is absolutely old news.
These are just my top ten favorite books that make the argument for truly empowered teams. I know several others; I just didn't want to put more than ten on there at you. I'm reading another one by Simon Sinek right now. It's another great one called "Leaders Eat Last," which is also making the same argument. They all make this argument. I encourage you to read all of them, really. They're inspiring.
But for some reason, they have failed to convince leaders of most companies that this is a good idea. I mean, that's the reality. They haven't.
So to me, that begs the question: why don't more companies actually really empower their teams?
The way my world works is typically a venture capitalist will introduce me to a company, and I'll spend a little time with them. Just so you know, it is very easy to spot the clues of which kind of company we're talking about—this sort of product culture thing or the old school. It's easy to spot.
I can tell it from meeting any engineer in the organization. I can tell it from whether they do old-style roadmaps and project planning and all the sort of games people do. So it's easy to see.
But then I'll go to the CEO and say, "Look, you know this is not the way good companies run, right? You know that. So why are you running like this?"
Honestly, the answer comes down to one word: trust. Usually, I can get them to admit that they don't trust the teams. They'll phrase it like they can't trust the teams. They'll point out, "Look at these..." You know, mostly they do truly focus on product managers, and I hate to say this, but mostly they're right. Right? Mostly they're right.
The product managers in most of these companies are not worthy of being trusted. They're not. They haven't earned that right to be trusted.
Now, of course, I immediately point out to them that while that may be true, whose fault is that? They're the ones that hire them, right? So it's their fault.
So we need to get this out on the table. Then the real discussion becomes, "All right, if you believe that you need to run with truly empowered teams, then you need people you can trust." Clearly, you need people you can trust in these roles.
So let's talk about how you really do that. That's really what I want to talk about here—in an organization that works this way, what the real differences are, the important differences are.
The first way I'd like to describe that is with three companies that everybody knows. They are three of the most valuable companies in the world. We know that. You probably all know that. Just recently, Apple crossed the trillion-dollar mark.
As you also probably know, that's on the back of the iPhone. But those three companies, I would argue, are three of the most valuable companies for good reason. They have proven their ability to consistently innovate on behalf of their customers.
Now, here's the tricky thing and why I realized that this loose concept we talked about—about needing a product culture—is not really sufficient. Because if any of you have been inside these three companies like I have, you know that they all three actually have very different cultures.
So how could that be? What does that even mean? And they're actually those are two extremes. Apple is kind of in the middle; Amazon is well away on one side of the spectrum; Google is more like a party in most places.
So, you know, it's just all over. Yet all three managed to have a pretty amazing environment for product teams, and I think the results are the consequences of that environment.
One of the things I realized—and it's funny, it was just about a month ago over a very informal beer with a friend—I realized that one of the things we just having, luckily, lived in San Francisco, something I was aware of and a lot of people there are aware too, but most of the world is not aware of, but nobody talks about, and they should talk about, which is these three companies actually have something hugely critical in common.
It's just not well known. These three companies—the founders of the three companies—four people, right? Bezos, Steve Jobs, Larry, and Sergey at Google—whoops, the four founders—all were coached by the same person: Bill Campbell, known as actually the coach of Silicon Valley. Sadly, he passed away a couple of years ago.
But I will also say I was not lucky enough to be coached by him. I truly wish I was. But I was very fortunate in that two of the people that I worked for were directly coached by him.
I will also tell you several of the people that I have tremendous respect for, like Ben Horowitz and Chris Iger—these are leaders in our industry—they were personally coached by him, and they've really taught me a lot. So I feel like I'm a beneficiary of his teaching.
But this guy literally, for a decade through the formative years of Google, Apple, and Amazon, showed them how to set up a product company. He literally explained the process to these companies.
I could really talk for hours just on him. I actually, ten years ago, wrote an article that some of you may know. I published stuff for a while on product. I wrote an article talking about the real learnings I've got from him, and I asked him to review it. He told me that he'd rather I not publish this for the same reason he never agrees to press interviews.
He likes all the attention on the people he coaches, and that's why when he passed away, there was one of the biggest memorials in Silicon Valley, but almost no press coverage. The press really didn't know about him.
But it turns out, I would argue, that's pretty important. One of my favorite quotes from him is this. In fact, I'll tie my shoe while you read that.
So I love that quote, by the way. And you might even read that and think, "Oh, that's sappy. It's too sappy." But honestly, this was him. His personality came through. Anybody that knew him will tell you this. He was a genuine guy.
What I think is amazing is that if you look at Google, Amazon, and Apple, they all three—of course, there are four very different founders—but they all three managed to figure out how to do that in their own way. All three companies created this kind of environment.
Now, contrast that, of course, with most companies' environments. So this is really what I sort of decided I want to focus on for at least the next year. I want to focus on how can we get this kind of environment in more companies? Because to me, this is the root cause of why so many companies are just, you know, clueless on product.
Okay, so this leads to the topic of leadership. So let's talk about leadership first. Many of you probably have heard of Etsy. Etsy is another great product company. They're based in Brooklyn—a big global marketplace. Mike Fisher is actually their CTO. He's one of my favorite CEOs in the world.
His longtime friend, Marty Abbott—I didn't show his picture here, but he is also a CTO. I met both of them. Marty Abbott was the CTO at eBay when I was running product at eBay, and Mike Fisher was actually running PayPal's engineering when I met him. So I've known them for about 20 years.
What's really interesting about those two is that they both went to the U.S. Military Academy at West Point, and they both served in U.S. Special Forces. Now, I say that because to me, that's the main reason why they take leadership so seriously in that context. I mean, it's literally a life-or-death thing.
So I have actually written about a lot of the things that they teach before. I love this quote because it is true. I'm going to talk about leadership and management. A lot of people make this mistake of mashing those together.
It is true, of course, that most leaders are also managers, but the responsibilities are different, and I don't want them to get lost. So I'm going to talk about them separately. At a high level, of course, yes, leadership is about inspiring the organization, and management is about guiding us there. I think that's spot-on.
So this topic of leadership is honestly a massive topic. I could talk easily; whole books are on leadership. What I want to do here is make sure that everybody in this room—we're all sort of on the same page about what it means to have good leadership.
Now, the reason this is so important—hell, I should state this explicitly—you can't hope to have truly empowered teams unless you give the teams the business context of what we're all trying to achieve. That should be obvious, but I want to be explicit.
And this is how we do that. That is the primary role here of leadership. So there are five big responsibilities of leaders, and in particular, I'm talking about the leaders of product, the leaders of design, user experience design, and the leaders of engineering.
Of course, the leader of the company—that sort of team. There are more leaders in a company overall, but we're talking about the product leadership, product design, and engineering.
The first is product vision. The vision, of course, is our North Star. It's typically, for software, three to five years out; for hardware, five to ten years out. But a lot of people do call it the North Star because if you have 50 product teams in your company, this is the common objective.
A lot of people make the mistake of doing product vision per product team. That misses the point. The product vision is the whole; we're all contributing to the other thing.
I'll say this: this is our best recruiting tool for the kind of people we need to staff empowered product teams. The vision is really—that's the purpose. Every good product design engineer I know wants to contribute to something meaningful, and that's what the vision describes.
The product strategy is really how do we get from here, wherever we are today, to this great vision that we all are anxious to make happen. Now, there are many different valid ways to come up with strategy. That is a massive topic on itself.
It usually turns out to be a sequence of product-market fits, but there are other ways to do it too. What we're really trying to avoid there is product strategy representing some important choices. What we want to make sure doesn't happen is that the whole company tries to solve everybody's problems at once. That is a clear recipe for failure.
So one of the clear purposes of strategy is to make some intelligent, intentional choices about what problems we attack and in what order. Okay, that's the strategy.
One of my favorite parts of this—the really vision, strategy, and principles go together. Product principles describe the nature of the kind of product we're trying to create. What are the things we believe to be true? These are not requirements; they don't show up. They don't tell us specifically what to do, but they do inform the decisions we will make when conflicts come up.
Now, that's a big discussion. If you're not clear on that, I have lots of examples. Just Google the term "product principles," and you'll find them.
Product priorities—there are many different techniques out there for getting teams to focus on outcomes rather than output. As you'll see, that is a fundamental objective of—hey, no pun intended—of a modern product team.
But the most popular one today really is the OKR system, which most of you know: objectives and key results. Now, the OKR system is—if you've tried it, even though it's conceptually simple, most companies completely bungle it up for the first couple of times. It's just normal.
One of the first things they do is they get this wrong. They just basically ask every team to propose their objectives, and of course, you have 25 teams going in 25 different directions. This is nonsense.
So the product leadership's job is to define the organization's objectives. Typically, that's done on an annual basis, and that, of course, represents some choices, which is their job to make these choices. Because again, otherwise, every team has no context; they don't know what the priority really is.
Finally, and the bigger the company, the more critical this is, the organization—the leaders need to evangelize. They need to sell the organization on the vision.
Now, John Doerr, one of the most famous venture capitalists in our industry, likes to argue we need teams of missionaries, not teams of mercenaries. That's his way of saying truly empowered product teams versus the old-style mercenary teams that just build features on a roadmap.
But if we need missionaries, the leaders need to preach. They need to share that vision and convert the people to be true believers, to be missionaries. So evangelism is a huge responsibility in a large company.
I will also tell you it's a non-stop responsibility. You let up on that at all, and things start to go sideways.
All right, I also want to make this real. I'm going to show you some people so that it's not just theoretical. Stacy is actually a veterinarian. She's a doctor to animals, and I met her because she was running as a practicing vet in a small town.
She was very frustrated with the technology that they had, and she kept thinking there must be some suppliers out there, some vendors. Finally, she gave up and said she wanted to create a startup to do it. She felt like this is an important problem—completely passionate about the purview.
This is essential today to providing quality care for animals. I watched her. I watched her. I mean, as a startup co-founder, I watched her first learn product, and she still does the product role. Then I watched her learn running, managing engineers because effectively she was the engineering manager.
Then I watched her learn marketing, and I watched her learn sales. I watched her learn biz dev and fundraising. She's now the CEO of a pretty amazing startup that is disrupting the space and has thousands of passionate customers.
I was an advisor, so I was able to watch her grow like this. To me, one of the big lessons about how is it that this person—who, I mean, fundamentally a smart person, she was a vet but had no experience at all in the technology industry—how is it that she was able to build this business so quickly, so successfully?
I would argue it's because great product people at all levels know what they don't know. They know what they can't know. They admit what they don't know. It's just another way of saying they're humble. They're not arrogant. There is not an arrogant bone in her body. She completely gets this.
So when you've got that mindset, she just goes in, figures out what she needs to know, learns it, and goes. So that's what we're looking for in leaders—an incredibly articulate advocate for the vision in animal health care.
All right, let's talk about the role of management. I love this Steve Jobs quote because I think so many people miss the point of Steve Jobs. They misunderstand his legacy. They really, especially product people, have this myth in their mind that he was like a product manager, but he wasn't.
He was really good, actually, at looking at your prototypes and telling you all the reasons they were bad. That's a great skill. And yes, he was also an amazing product visionary—amazing—and I think that's critical for that team of missionaries.
But I love this point, and I think it gets right to the heart of what we need to talk about: why do you hire these people? You hire smart people not to tell them what to do by giving them a roadmap of features that mostly won't work.
What you do is you hire smart people and set them up so that they can show you what's possible. That's really the key.
All right, so let's talk about the responsibilities of management. There are three responsibilities of managers. Now, I'm not talking about, you know, the CEO level. I'm talking about the people managers, especially—and clearly not product managers.
I'm not talking about product marketing managers. I'm talking about the managers of product managers, the managers of designers, and the managers of engineers. Because honestly, the whole empowered team thing—this is where it either happens or not, right here—these people managers.
And it's usually the not, and you'll see why. So there are three responsibilities of these managers. The first one is staffing. It's kind of obvious. Their job is to put in place competent people. That is their job.
Now, we'll talk about why they often fail at that, but that is their job. It is not HR's job. HR is there to help, which they sometimes do, but it is not the job of HR. It is the job of the hiring manager to source, to go to things like this, meet the right people, to recruit, to sell, to close, and convince them of the vision and why they should come work here.
And then, of course, once they get them, they need to onboard them, and they need to manage their performance. That might include, if they can't do the job, ultimately moving them to somewhere they can succeed. But staffing is critical.
The most critical responsibility is the second, which is coaching. The more I progress in this business, I realize I was so lucky in my career to have worked in some places. It really is a form of a bubble.
My first ten years were at HP Labs. HP had this amazing culture back then of developing people. It was just all about developing people. They would basically just do career college hires, so I was one of millions, and they would develop them.
I will tell you, for my entire ten years at HP—and I was an engineer through engineering management—every single day, I had at least one people manager that was dedicated to coaching me to get to the next level. I thought that's what everybody had.
It wasn't until I left HP—I wanted to do a startup, and of course, I didn't expect anything like that. I started, but then I went and met lots of other companies, and I will tell you today, it's the exception when I meet somebody that actually tells me they have somebody helping them get good at their job.
I will very often—and I hate this—there's such a problem in product managers in our industry, whether they have the title product manager or product owner. They are not competent. That's the problem.
I ask them, "Look, okay, I can see you have no idea how to do your job. So the question is, who is helping you learn that?" And when the answer is, which is all too often, "No, nobody," that's like, "Okay, now whose fault is that?"
It's not the person's fault; that's their manager's fault. The biggest—if I had to point the finger anywhere, it is the managers of product managers.
You know, I only recently realized this, but a decade ago, Ben Horowitz wrote a piece. For those that don't know, you should read anything he writes. Ben wrote a piece where he argued that the director of product management—which is the typical title for the person managing product managers—he argues this is the single most non-executive position in a tech product company.
This is why he's like saying, "Because look, product teams are only as good as their product manager. Who's responsible for competent product managers? The director of product."
So if they're not able to do this job, or they're not willing to do this job, everything falls apart, and the notion of empowered teams—no chance. So this is huge. Everybody needs that.
I spend a lot of my time coaching, but as an advisor, that's kind of what you're supposed to do. But this just kills me. I meet so many people that I think have the raw talent for success, and they are given no guidance in how to do product right.
The truth is, they never seem good. This is sad.
All right, finally, if you're using a system like OKR, as I mentioned, there are objectives at the organizational level, but there are also objectives at the team level. This has to—this is the part where managers really earn their money here.
They have to go—if we have, you know, a big marketplace with buyers and seller teams and search teams and trust and safety teams, things like that—then the managers need to make sure each team has a set of relevant objectives.
The way it's supposed to work in the model is they're given—the managers get together and decide which objectives will deliver on the organization's objectives. They'll go to a team like the search team and say, "Hey, we need you to, you know, improve the experience in this dimension," or "These are the three KPIs."
But what can you do for this area? Maybe fix the onboarding experience, reduce our churn rate, whatever it is. And the team then looks at that and proposes back key results.
It's normal for there to be some give-and-take. Managers might come and say, "Well, nobody's working on churn rate. We need that. Which team can do something for churn rate?"
But without that active management, you can hopefully see it's obvious there's no chance that your teams are going to produce the results that the organization was hoping for.
So I can tell you what will happen next: back to roadmaps.
All right, so those are the three responsibilities of management. Here's another example of a great people manager: Christian. I met Christian because he was at a company I was advising in Richmond, Virginia. I've actually known him now for a decade, and I have seen him absolutely do fantastic things at three different companies.
He is one of the best people managers I know, and of course, the way you tell that is the people—they're just fantastic—in an area that in the U.S. is definitely not known as the tech hub. He can crank out absolutely, you know, Amazon-caliber people.
I was actually curious about how he got so good at developing people, and I should also say he has turned into—not he will always be a great people developer leader, but he has turned into a great head of product as well.
But I asked him, "Where did this come from?" Christian explained to me he wasn't actually from the U.S. He came from Nigeria, and in Nigeria, he went to school with African kids from all over Africa—80 different languages across the entire socio-economic spectrum.
He said the main thing he learned in school was you got to work with people. Everything is all about that, and you got to learn what they care about, and you got to help. And it just made him fantastic at that.
So let's get back to this concept of trust because I was saying before, for truly empowered teams, you have to provide that context. But then we need to provide—we need to get the teams to the point where the leaders trust them. That's really the two big elements.
So let's get back to this idea of trust. Many of you probably know Stephen Covey. He's a pretty famous thought leader. He wrote "The Seven Habits of Highly Effective People," but I believe he nails this. It's my favorite, most concise summary of what we're looking for, which is trust really depends on two things: competence and character.
Now, I'll talk about character next. That's also a very important discussion. But let's talk about competence because this is an area where I said, you know, I do think one of the big issues in our industry is product managers that have not been trained to competence, and mostly because their manager doesn't know.
Their manager really isn't—they've never done it before. This is why my single main piece of advice to a new product manager is: don't worry about the company. Find a high manager that you will work for that has been there, done that at a good product company, and is committed to coaching you for the next year or two. That's the best way to learn product.
The vast majority of people that have never seen it—so how do we expect a director of product management that's never actually done product at a good place or seen it to be able to hire competent product managers?
If you've ever heard the old adage, "A's hire A's and B's hire C's," this is really playing out every day in our industry. So you see the good ones just hire and develop great people, and the other ones just—they think they need a Google product manager, and then they come back to me and say, "Well, we can't afford them. We can't attract them. We can't even find them."
Yeah, because there's not enough, right? So then what do they do? They kind of say, "Well, I found somebody who's really skilled, but yeah, we're going to kind of overlook the fact that they're a bit of a jerk."
Yeah, I see that all the time. They lower their bar in other areas. Another problem is they think they need these "10Xers." You might have heard that phrase.
All right, so let me just say we need to hire competence. Now, that's why the head of product management hires product managers, the head of design hires designers, and the head of engineering hires engineers. They are supposed to know competence.
Now, I also want to be clear: once in a while, you can hire not for competence but for potential. I'm actually a huge advocate of that. Some of the proudest aspects of my career are the people I have helped that have gone on to do awesome things, and that's hiring on potential.
But here's the thing: you only hire on potential if—and only if—the hiring manager is willing and able to coach them from potential to competence. Unless they're willing and able to do that, you're just hiring people that are not going to be able to do what you need to do, and you'll just propagate this problem.
So competence is critical. Yes, there are lots of different views of what a product manager is even supposed to do. You've heard several. All I can tell you is they can't all be right of what you heard. There were lots of them that were in conflict, and that is—you need to know what good is on product if you're trying to hire more people like that.
Okay, so let's now talk about character. The New Zealand All Blacks—some of you may know—they're actually the most successful sports franchise across all countries, all sports, over a hundred years. They're more successful than anybody else—something like literally a hundred-year win percentage of 77%. Phenomenal.
The All Blacks have figured this out. They have figured out the empowered team thing. One of the critical things they figured out is it doesn't matter how talented or skilled a player is if they're an a**hole. That's what they figured out.
They literally have a rule, which is the "no a**hole rule," which is applied to both players and coaches because they're right: it's toxic.
Now, this, to me, is a hugely important point because this, of course, is in no—I've never seen in a company's HR guidelines have a "no a**hole" rule, but they should have that.
But you know what's worse? This is, by the way, this is a deadly serious problem. They have something in their guidelines which says, "In our interview process, we have to ensure cultural fits."
So I have come—I hate those two words because you know what that really means when you talk to the interview team? Because they don't—what the hell does that really mean, "cultural fit"? It is the most vague term.
But you know what it means in practice? It's like, "Okay, we're on the interview team. We work for this company, so if we're sufficient, we are cultural fit." Right? So what does that mean?
Well, we need to find people that are like us. Seriously, this is what happens. They hire people like us. For most of the companies I advise, that's like white guys that went to a top university with an engineering degree.
And you know what's even worse, by the way? In the interview process, they will have questions that are meant to determine how the candidate thinks about a problem. I'm like, "Look, you are institutionalizing hiring people just like you."
We don't want that. We want people to think differently. So I try to get these organizations that tell me they can't find competent people or they can't tell—they tell me they can't find these rock stars is what they complain.
"Oh, you can! You can!" Instead of just this big can't, you know, pool of candidates, at first, you shrink it way down to these perceived rock stars and then filter it even more to people that look like you.
Instead of that, you've got this big pool of people out there that are candidates. Filter it down to just the competent ones. That's a lot bigger set than the rock star ones—the competent ones.
And then just filter out the jerks—that's not a big group—and the rest are great candidates. I see this everywhere. The talent is there; it's usually hiding in plain sight.
But you know, we see organizations hire for—they're looking like them, acting like them, talking like them, went to the same schools. It's a deep problem, but this is a much more effective policy.
All right, so I just want to make sure and make this real. I'm going to highlight a few people from—these are people that are ordinary people. All of the people I'm talking about are ordinary people that did amazing things because they were in an environment that let them do amazing things.
So a product manager, a designer, and an engineer. Adi is actually a product manager on a team called Augury, which is in Tel Aviv. By the way, a lot of the best teams I've ever met are in Israel. I'm still trying to figure it out. My theory is because in Israel, unlike most of the world, at age 18, every man and woman has to go serve in the military.
Adi, they—the military actually looks at your high school grades and decides where they're going to place you. They decided she was a fighter pilot, so they sent her to flight training. She did that for about a year, and then they said, "Okay, your job now, with your technology aptitude here, is to build flight simulation software so that the pilots can know what to do in emergency maneuver situations."
The commanding officer explained to her, "And by the way, you need to get these pilots that come in twice a year to listen to you because it could literally save their life."
He said, "Look, they're not going to listen to you unless they trust you. So in order to trust you, you have to know your stuff, and they have to like you."
It's funny because she shared this with me, and I was like, "That's really good training for a product manager." That is like—because we do that, and that's what this is based on: this trust. They trust us because they trust us because we're competent and we're not.
All right, and Audrey is a designer. Real product designers—I'm not talking about somebody who's just graphic design. A product designer is worth their weight in gold. A competent product designer—many of you, I'm hoping, work with them all the time. They should sit right next to the product manager.
I've known Audrey for 20 years. She worked for me at Netscape. I was just blown away by her mind. Then she was lucky because at Netscape, we had a head of design who came from Apple. He was an original luminary there, and he just made her an awesome designer.
I have seen her over and over—I don't know how many teams now—just solve incredibly hard problems. This is what designers really do: they solve for constraints. In fact, the harder the problem, the more they like it.
I don't have time to really go into what great design is about, but that's one of them right there. And then Lindsay is an engineer. The reason I like to highlight her is in an empowered team, we do not want engineers that just roll over and build whatever you tell them to build.
Good engineers on an empowered team are like, "Show me why we should build this." They challenge the product manager. You need engineers that will go toe-to-toe with the product manager and the CEO.
Lindsay is fearless. I think that key mystery, by the way, is she's now a top-rated answer on Stack Overflow. She's an iOS app native developer. She's done many good apps, but you know, she had a rough childhood. She was bullied a lot, discriminated against a lot.
Fortunately for her, she liked to code. She went and studied computer science and, interestingly, drama, and went on to become a very competent developer for sure. She still pursues her acting, and she's had a pretty amazing career in that as well.
But this is what we're looking for out of our engineers. Again, these are just ordinary people that when you put them in the right environment, they do amazing things.
I have seen this so many places. Google, for those that don't know, they did research on this probably longer than any other company I know, and they published fairly recently some of their most interesting findings. You can Google the topic "Project Aristotle," and they shared that, you know, they thought if you've got a really important thing, you take these rock stars from different parts of the company, you put them together in a team, it's going to be amazing.
No, not amazing at all. It turns out the teams that consistently produce are the ones with the ordinary people that trust each other, that have this relationship where they don't have an a**hole on the team poisoning the environment and making people not feel safe or not feeling comfortable to do what they need to do.
So, okay, just to close because I am out of time, I want to leave you with a test. Because I hope—well, I would love it if most of you were to tell me you are working in a truly empowered product team, but I would not believe it either because I have talked to a lot of you, including yesterday, and it's just not that common.
So if you're not sure, there are clear litmus tests that have been listed for quite a while on this. The first question is: is the team staffed with competent people covering the range of skills we need? For most product teams, that's product design and engineering with access to data science or data analysts and user research.
But that is a typical team. If you don't have that team, you're basically being set up to fail if you're going to be truly empowered. So this is table stakes. You have to have a competent team.
Usually, the issue there with competence is our designer and our product manager, usually because the managers of those areas have not either hired to the competence or coached them to the competence.
The second test—and this is clear—this is the most well-defined litmus test for it: is the team actually assigned problems to solve versus just given features to build?
That's often referred to as the difference between—you know, this is—well, that's actually the next point—the difference. They're held accountable to solving problems—outcome rather than output.
We, of course, have to do output to get to those outcomes, but what matters is the outcome—the business results. This is actually—you can see OKRs were intended for this—to stop people chasing features and output and to start them focusing on problems to solve. That's what the objectives are supposed to be, and key results are supposed to be business results.
Okay, clear, easy test. You can decide if you're in that or not. Now, if you are, congratulations. But if you're not, I would argue it's only a matter of time. It's a race. You either get to here, or you will fall prey to somebody that knows what they're doing in the tech space.
So on that cheery note, I hope this was useful. My email is right there. Thank you very much. [Applause]