Marty Cagan on The Four Questions of Great Product Management

My interest has actually never been really product management. My interest has always been product teams, because I’ve never seen a product come from a product manager. I’ve only seen great products come from product teams. I started as an engineer for ten years, and I was lucky. I was at a great place, HP Labs, and I was working on tools and products for other developers, other engineers. So very fun ten years. I had a great time, and that was during the time where they were in their prime.

They were known as the most consistently innovative company in the world at the time, and that’s why I went there. And I had a great time. I did get interested there in more than just engineering. I started asking the questions about who decides we should build this particular product. How do they know that’s gonna be a good thing to do? I started asking those questions beyond the little swim lane of a typical engineer. And I learned about product. I learned about design, and I learned about go to market.

I learned about all these things. My lucky break happened actually because I had done all these products for developers and as Netscape was really the original Internet company, and I got to work for Marc Andreessen. Was there was already a browser team, there was already a server team, but I was for Platform and Tools. In other words, again, doing products for developers. In this case, though, was the Internet, new platform instead of just Windows. That was a dream job, honestly. I’d still be there if it was still going as a company.

But after about five or six years, we lost the browser wars to Microsoft and your Internet history. During my time at Netscape, I got to meet the founder of eBay, Pierre Omidyar, and I really liked him. I loved his vision for the company. EBay was probably the first real app in the Internet era, the child of the Internet. I was brought on to be the original head of product and design. Really, he was the original head of product. That’s the truth. But he was the founder, and they had got some real traction really because of his innovations.

great people, but totally different. Marc Andreessen is literally the, I think, the smartest person I’ve ever met. It took all of my mental energy just to keep up with what he was explaining to me. And I was so impressed because he was really the epicenter in those years. People don’t realize how incredibly valuable this was. He was meeting with the engineering teams every day. He was meeting with prospective customers every day. He was meeting with startups every day. He got to assimilate all this knowledge about where the industry was really going, and I think it helped him to see the future way before the rest of us.

I learned way more from him and actually from Ben Horowitz, who was a peer. I learned more from them than they would ever realize.

Ironically, the lesson that I took away the most, and I remember him saying this over and over, was the most important thing is to know what you can’t know. Isn’t that essentially a lesson in humility? It’s like, you need to know what you can’t know. Because that is really the essence of product discovery. We can’t know. We can’t know if our customers are really gonna buy this. We can’t know if how hard it’s gonna be to build until we actually go figure it out. Honestly, that has had a huge impact for me.

I genuinely believe it made me a much better product person when I realized he was right. Because I had grown up in the era where product people were expected to have the answer. That’s not only not right, but it misses such an important point. Ben is a different character. He’s one of the best product minds I’d ever seen. Ben, I say, one of the things I really got from him was this sort of tough love, give it straight, but give it with from the right place.

He, of course, was lucky enough to be coached by Bill Campbell, and you could really see the impact of that. You could see him coming through. So anyway, those were great people. Pierre was really a different kind of person, but I loved what he’s trying to do for the world. You meet startup founders all the time, and some of them just have that burning fire that’s so addictive. That’s my favorite thing about working with startups. It’s just contagious. And he had that. He saw that the Internet would enable something that’s never been possible before.

And I don’t usually talk about this, but the truth is, in my whole career, I’ve always focused my interest is really on product teams, helping product teams, mostly engineers. But I made an exception with eBay. It was the one time in my career because the customers were not developers. The customers were buyers and sellers. And the reason I made that exception is because up here, it was such a persuasive vision. After eBay, I wanted to get back to at that point, I was pretty tired to several big rides.

And I wanted to get back to what I really loved, which was working with startups. I started SVPG as just a way to work with a bunch of startups. My timing was incredibly lucky, because if you remember back then, we’re talking, like, 2000, 2002, that sort of time frame. A lot of the early startups were getting going and a lot of the people either came from Netscape or they came from eBay or they came from PayPal. And so I knew a lot of these people. I knew the early Google.

I knew early Amazon. I knew these people were calling me up and saying, hey, the stuff that you used to share with us at Netscape and at eBay, can you share that with our team? So it was a perfect timing, really.

And I’m really talking about product slash company founders there, startup founders. It’s usually one of the founders that is the product leader. And, of course, there are all kinds of risks when you do a startup. One of the tools I like actually is goes by various names, but a business model canvas, a startup canvas, a lean canvas. The reason they’re nice tools is because they make you face your risks. They spell it out. There’s all kinds of risks. There’s how are you gonna make money? There’s do you have a effective go to market channel?

Do you have a unique value proposition? But what I find is that most founders gravitate to the risks they’re more comfortable with. So for example, if the founders are, like, fresh out of business school, they will gravitate to the business model. They’re super excited about how they’re gonna monetize, and they’re already excited about their spreadsheets and how much money they’re gonna make. And I’m like, okay. Yes. That’s a risk. But you know what? It’s not the primary risk. My point to them always is, look, all this other stuff, it is only relevant if you can come up with a product that people are willing to buy.

Full stop. Everybody acknowledges that, but too many of them think of it as like an exercise left for the reader. Worse than that, they think they know. They have this idea. They think they know what that is. In fact, I just couple days ago, I did a a call with a founder. And by the way, I think this founder’s quite a smart person coming from the right place, but he had, out of frustration, asked for a little time because he had been pounding away for three years, and they couldn’t get the product market fit.

So we had this discussion. He showed me this stuff, and literally, they had not changed their MVP in a significant way in three years. He figured, I know this is a great idea. There must be a market somewhere. They were trying different pricing strategies. They were trying different, like, freemium strategies. And I’m like, look, dude. The problem is you don’t have a product. Your product is not valuable. That’s the issue. They had basically been dancing around every other risk and not tackling this head on, which is unless the product is right, you’ve got nothing.

It’s worth double clicking on one part of that, which is when we talk about getting the product right, there’s really two sides to that. The first side is, does anybody have this problem? Does anybody need this thing? It turns out though, that’s the easy one. People spend all this time on that one again because it’s easier, but they spend all this time. That’s not hard, honestly. We have very good tools. Most of the time, there’s no doubt. All you have to do is look at the competitive marketplace and see how much money people are paying for solutions in that space.

Most of the time, it’s not rocket science. But if it is a little different, we have very good tools to test demand. The issue is rarely demand. The issue normally is the solution that you’ve come up with is not significantly better than the alternatives that are out there. And if it’s not significantly better than the alternatives, people won’t switch to your product. And then none of the other risks, none of the other cool marketing strategies, none of the other cool sales models, none of the other cool monetization, none of these things matter because people don’t really want your solution.

I do not know how to do product without intense immersion with customers. Everybody says that today, but usually when I describe what that really means, they’re going, oh, wow. I need a lot more time for that. To your question, and this you’ll see why you need to go to customers. In product discovery, there’s really four questions that we always have to consider. Now sometimes it’s easy. Any one of these questions might be easy, some are hard, you never know. But we always have these four questions.

The first one, is it valuable? In other words, will people buy it? Or if they’ve already bought it or if it’s a free service, will they choose to use it? That’s the value question. Usually, that’s the hardest one. Second, assuming they wanna use this because it does something that they need or they want, can they figure out how to use it? That’s the usability question. There’s very rarely an excuse to do bad on that one unless you just don’t realize you need product designers. So normally, if you have the right skills in the startup, that one we can address if you just do the basics.

The third, is it feasible? Now this can be a very big one, especially with things like machine learning technologies. Feasibility means do we know how to actually build this solution? Do we have the skills on the team to build this solution? Do we have the technology stack available in order to build this solution? Do we have enough time? All that is feasibility. And the fourth risk is can this sustain a business? This is viability risk. In other words, is it legal to actually do this? Can we afford to pay for it?

Can we actually get this to market? Do we have the marketing mechanisms, the sales mechanisms? Do we have the channels set up so that we can effectively get this to market? These are all viability questions. A product to succeed needs to be valuable, usable, feasible, and viable. Any one of those, of course, can kill

At one level, it’s very superficial, the difference between a feature and project, and a lot of times, we’ll just have a definition around the level of effort, so that’s not really helpful. The way I try to get people to think about it, it’s the difference between output and outcomes. So the difference is features are just output. We can crank out features faster than we’ve ever been able to crank out features. So if you notice though, the percentage of companies or products that do better is not really going up.

So it’s not about cranking out features. We call those feature factories. It’s just that’s all they do is optimize for features. What it’s really about is solving problems for customers and for your company, and that’s what we mean by outcomes. So when we talk about a product, we mean solving problems for real people. And again, could be meeting a need like, in the entertainment space or the gaming space, but you’re doing something valuable as opposed to just a bunch of features. When

Usually, the clock is ticking. There’s a certain amount of runway there. That it is true that some companies have had much longer runways in the last few years than I’m used to. And I don’t necessarily think that’s a good thing, because people did a lot of really dumb things because they had so much pushing off the getting to product market fit, because they could buy customers, you know, things like that. But the clock is ticking for a startup. So difference between a good company, a bad company, you don’t really need to use product discovery techniques.

If you have essentially unlimited time and money, you could do we used to call this the old Microsoft model, and to their credit, they would pull it off. You just assume you’re gonna spend three, four, five major iterations, and you’re taking about a year for each iteration. So that’s why it was normal for Microsoft. Their first couple years were terrible versions of the product. But by the third year, fourth year, it was starting to get pretty good. Most of us do not have monopoly profits to fund that stuff.

We have to be smarter. And that’s really the difference between good discovery. Because even what Microsoft did, that’s product discovery. It’s just very slow, very inefficient. But that’s what it is. You’re trying out an idea. You’re seeing if it’s valuable, usable, feasible, viable. If it’s not, you take another shot at it. In teams that really have constrained resources by the way, this is not just startups. Because even in a big company, it’s not like they’re running out of money, but they do run out of management patience.

We like startups. And I tell them, look, here’s the reality. You will probably need to do between 50 and a 100 attempts before you get to Product Market Fit. So you either need a boatload of money and time, or you better learn some skills. It’s not that hard to learn the skills. We have great techniques today. This is the part I love about product. The techniques have got so much better over the years. So we can do 50 to a 100 attempts at getting the product market fit in months instead of literally decades.

make a difference. And also, first of all, I should say, you just tapped into a very big topic and product, so we could talk literally all day about this. But the truth is there are quantitative and qualitative techniques. The quantitative techniques are about collecting the data. That’s actually the definitive set of techniques that will tell us for sure if something is working or not. But the qualitative techniques, first of all, they’re much, much faster. And second of all, they do something very different. They tell us why our product is not working.

The quantitative techniques can tell us it’s not working, but that doesn’t really help us that much. It just says it didn’t do what we need. Now what we need to do is figure out why and the qualitative techniques do that. And good product teams are doing a combination of both all the time. So the short answer is most of the time, we can figure out in hours that this is not right. In fact, it’s not unusual to do a dozen iterations in a day. Now when you’re doing that, you’re not putting it out into the market with a 100,000 people using it.

That’s not what you’re doing. But you are putting it in front of real users and customers and trying to understand two things. Number one, could they use it? Could they figure it out? Could they do what they need to do? And most importantly, number two, would they use it? Would they really buy this? And, of course, we have a whole bunch of techniques. For the first, that’s pretty straightforward. We’ve been doing that for years. That’s called a usability test. For the second, a value test that’s more involved because there are lots of different ways to measure value.

It depends if we’re talking b to b SaaS, if we’re talking a consumer product. There’s a lot of different factors there and a lot of different techniques because of that. But the bottom line is, as soon as you’re convinced as a product team that this is not there yet, you iterate. You don’t wait a month for some statistically

I know. This is Product one zero one. And also, to be honest, we don’t really care what people say. You have to realize the reason we don’t care is because they our customers, as much as we love them, they don’t know what’s possible. They don’t know what’s possible. So, no, we’re not that’s why there was a great quote from Steve Jobs. He would hold up his iPhone and say, you can conduct a 100 focus groups. You are never gonna get an iPhone. So then does qualitative feedback even matter?

If Oh, yeah. Because that’s not what we’re doing. We’re not asking them what would you like in the product. What would people that don’t know what they’re doing, they’ll often ask things like, so pretend you’re the designer. What would you change? No. That’s totally missing it. What you can do, in fact, there’s a great Elon Musk. Of course, he’s very good at product, and his argument is with qualitative feedback, your goal is to find all the things that are wrong with the product. So that’s the difference.

You’re not looking for affirmation, which is what these naive founders are doing. You’re not doing that. You’re actually the opposite. You’re going after all the reasons they would not use it. That’s much more helpful to us. What are the reasons they wouldn’t use it? Now that doesn’t necessarily tell us what to do. We have to simulate all this together that what we’re seeing, and then we put together a model. And if we keep working at it, there’s no guarantees in this. You could never get there.

Some products are never gonna happen. But the idea is to dramatically accelerate the time to get to the point where we actually have something that resonates.

The general heuristic here is don’t go there. In other words, when we do qualitative feedback, we’re not looking for a number. When we do quantitative feedback, we are. So the quantitative, that matters, and there’s a function of how much time are you willing to wait to get the degree of confidence you need to be able to either have evidence or statistically significant proof. That’s where we go, but that’s different. We’re talking qualitative. We’re not like saying, oh, we got six people that didn’t have an issue.

We’re good to go. That’s not what we do. What we’re looking for with every user is what are the reasons that they would not use it. Now we’re also crafting a value test to see if they’re serious about it. Because most people, especially when you sit down with them, and they’re not gonna tell you the joke is they’re not gonna tell you your baby is ugly to your face. They’re gonna say, what a cute baby. But the truth is, they’re like, yeah, I’m never gonna use anything like that.

That’s I don’t think you get the truth out of them, Marc. There’s a lot of ways we have. One way is to see if they’ll actually pay for it. Literally, see if they’ll pay for it. Pull out a credit card. You’ve probably heard of this idea of a non binding letter intent to buy. That’s one of the techniques. To pull out a payment card is another technique. To be able to commit to time is another technique. To pay with your reputation is another technique. Book Inspired, I wrote that book a few years ago.

Inspired is meant to describe the major techniques that teams need to do good product work. There’s a lot more techniques out there, but those are the, like, the the ones that everybody needs, and it describes several of these tests you can do. Another test of doing to measure this is the Sean Ellis test,

I would say product development today is a great blend of the two. What I just described, the qualitative with the quantitative, that is a beautiful blend of the two. If you force me to pick one, I would definitely say it’s more art than science. Part of the art is deciding when to count on the science. When to use the science to when to really do that and really know, look, this is very risky. This is very important. I don’t wanna commit the resources to building this until and unless we have statistically significant evidence this is gonna succeed.

That’s a very reasonable statement. I work with teams where that is exactly what you wanna do. For other teams, it’s we don’t need that. We don’t need that. We just need some confidence that we’re not going in the wrong direction. That’s all we need. We can get that faster. This is the kind of judgment that product teams are making every day, and I would argue that judgment is much more art than science.

There’s different schools of thought on this. I’m a big believer in the founder as the product leader. I personally never invest in a startup unless at least one of the founders is a proven product leader. Now, of course, the equation, the calculus is a little different if neither or none of the founders are a product leader. First of all, I don’t have a lot of confidence in that company. But second, you’re gonna have to bring products expertise on much, much sooner. But if we can assume in this discussion we have at least one founder that’s a proven product leader, then it actually becomes quite clear.

And honestly, it’s a function of the number of engineers more than anything. That’s the heuristic I use. And that’s because at a certain point, there is no way for that founder to be close enough to all of the engineers to be able to make the daily decisions on the product that founder needs to make. Partly this depends on just how many hours is this founder willing to invest in this stuff. But realistically, once you get past about 25, 30 engineers, the teams are saying, I can’t get enough time with the founder.

I just can’t get enough time. We’re going too slow. We’re waiting. We’re making bad choices or no

Realize it’s not like 25 flat engineers where all are considered equal. What they are, they’re naturally gonna group around product teams. If you have 25 engineers, you’ve probably got a minimum of three, probably four, five product teams. Each one of those will have a very senior engineer. We usually call them a tech lead, but whatever they’re called. It’s those people that have to have that very close relationship with the founder. What is that? Five, four, five? That’s not too many for them to do, and then that tech lead, of course, is talking in detail with all the other engineers about how they’re gonna divide and conquer on the work.

Probably the most important, actually. Yeah. And I have this chat with a lot of founders like you about, let’s talk about what you really need. What kind of person are you looking for? Is it literally just your capacity is out, or maybe you’re much more the visionary and you need somebody that knows how to make this machine work a lot faster. These are some pretty different responsibilities that you’re talking about. We wanna be very clear on the kind of product person that you’re really looking for, and then we can get to work.

Yes. For sure. Most companies, in my opinion, don’t do a very good job on the whole hiring process. They’re just very random. Another big thing we need to talk about is what is your philosophy on this? Would you rather hire, say, university graduates and develop them into the kind of people you need? Or do you say, no, I want people that are been there, done that, and I’m willing to pay a lot more, but I’m paying for that experience. We have to have that discussion. Both of those can work.

Don’t get me wrong. A lot of people have no choice but to do that. I also believe this is what’s great about startups. The biggest reason somebody great would join your company is because of your product vision. You are trying to do something that inspires them. Look at all the people that go work for Tesla or SpaceX despite crazy everything because they are so passionate about what those companies are trying to do. This is our number one tool for attracting strong product people, is having a very inspiring and compelling vision.

Now sometimes the founders need a little help articulating that. They really can’t get it out clearly in a way that can sell people on an interview the right kind of people you wanna have. Here’s the thing though on hiring that’s most important. If you decide for whatever reason you’re gonna hire junior people, then the worst thing you can do is do that and not have somebody in place, best sense manager, to develop them. If you just hire junior people and they have no coaching on an ongoing basis, you’re just throwing good money after bad.

That’s exactly what happens in so many companies. So the prerequisite for hiring junior people and I wanna be clear, I love this model. And this is the most scalable model I know. Look at Google. Look at Apple. They do a ton of this, but they have the mechanism in place. Microsoft too. The mechanism in place, their managers know their number one responsibility is to coach and develop these people.

Yeah. And this is where it really is different. If you’re hiring experienced people, that’s one interview. If you’re hiring, by definition, inexperienced people, that’s a very different one. You’re looking and obviously, when you’re looking for experience, you’re looking for whether they can prove to you they’ve learned about the business, they’ve learned about customers, they understand the techniques. To me, that is much more straightforward. When you are hiring instead of experience, you’re hiring on potential, which is what we’re talking about. Right? Based on potential. Then you’re making a bet on really more innate traits.

And then you’re looking for things like, is this person got a strong work ethic? Does this person have a strong sense of curiosity? Is this person that gives up very easily when they run into roadblocks? There’s a lot of ways to test. I’m not a fan, by the way, of tests in terms of the people who will have these assignments that they’re doing. I’m not really a fan of that.

I know. They love simple, tangible things, don’t they? And there’s all kinds of examples of people failing tests that were just the dumbest. In my experience, they’re not very indicative of what you’re really looking for. And let me put it this way, I still haven’t found that test that I think is any good. What I do think though is there are traits that we’re really looking for, and we have good ways of drilling into that. It is true though that the risk for an inexperienced hire is higher.

And so I always tell the first of all, I tell the founder, please don’t do that unless you have a, like, a director in place who knows it’s their job to coach and develop those people. Don’t do it. Otherwise, you’re just setting them up to fail. But if you’ve got that person, we’ve got that strong director level person there that can do this, then I tell them that they basically have three months to get those people to competence. That’s what it usually takes, is about three months to get them to competence.

He’s absolutely right, but that’s a different question. This is a little bit of a sidetrack, but it’s a really important one. There has always been a debate in the product world about do you hire people from the domain, or do you hire product people based on product potential and expect that they can learn pretty much any domain. That’s the debate. I am squarely on the side that I think he is. My evidence for that is just look across our industry, across time, that all the innovative products, almost all of them came from people and teams that had no real domain experience.

The most recent example that just I think is hilarious is look at the frenzy around buy now, pay later. Did you notice that none of the companies that came up with buy now, pay later are the credit card companies that were doing this every single day for the last thirty years. Did you notice that? Why is that? You probably know Shirash Doshi. He’s one of my favorite Yeah. Know him very well. I’ve had him on the show. I love Shirash. One of my favorite product people.

I met him way back when he was an engineer. The way he phrased this, I give him credit. I love it. I’ve shared it with lots of people. But one of the things that’s critical about product is to be able to understand the difference between domain expertise and domain dogma. And it is very hard when you grow up in a domain to be able to know the difference. You’re too close that way. That’s my theory that explains why is it that so often the innovations come from people outside of that domain.

So now it doesn’t mean that you don’t go deep with customers. You don’t go deep with understanding the financial constraints, the regulations. You need to, but you need to bring the way I usually describe it is you don’t bring along all that baggage. I’m a big fan of hiring for product people and I expect them to be able to learn the domain in part of those three months. That’s part of the three months. I know I’ve had to do that. Now, to be honest, most of the time, that’s pretty easy.

There are some domains, like medicine, for example, that’s got more to it. But even in those companies, I would argue because those companies always have it’s sometimes called chief domain expert. Sometimes it’s called chief subject matter expert. But say, for example, they have a physician. And every Product Team can go talk to that physician about, like, how does this really work? We’re designing, say, a surgical instrument. How does this really work? And they are able to get that extra level of depth. Even in finance, Intuit has these experts around tax.

Do you really wanna hire product people that are tax experts? Of course not. But do they have to understand personal finance? Do they have to understand the basics of account? Of course, they do. I am a big believer. It’s not about domain expertise. I say that always because we all know, if you’ve been doing this long enough, we know exceptions. I know some people that came from the domain that are rock stars. It’s just that, for the most part, I would rather have somebody with good product skills that I know can learn what they need to quickly.

Recently, I started answering that question by telling what happened to me when I was onboarded as a product person, and I told it once and people seemed to say, oh, that gives me hope. It was harder for me to get to that confidence level than I think most. So my situation was I was an engineer for several years, and I wanted to learn product. And my manager, who was an engineering VP, said, I can’t. I don’t know it, but I can introduce you to somebody who we coach you.

And HP was really good about that. So they introduced me to a guy, it was remote. He was in Colorado. I was in Palo Alto. He had started four successful product divisions at HP. He agreed to coach me, and the first thing he did and by the way, I just copied what I learned from him for years. So the first thing he did was an assessment, and I have a tool to assess people. So you start with an assessment, because everybody’s different. Right? You’re different than I I am, and we’re all different.

I had been an engineer for several years, so the technology side was like my one advantage. Funny enough, I thought my big advantage was gonna be since the product I was building was tools for other engineers, I’m like, I know our customers. And he said, the only thing I know is that is never true. You are never your customer. He was so bothered by my confidence about that that he said, explicitly, I was not allowed to make a single decision for my Product Team until after I visited 30 customers.

And further, he wanted me to visit 15 in The US and 15 in Europe. He made a call to the sales organization. It was a three week business trip, and within about two days, I realized how right he was. I didn’t know anything about our customers. I thought that engineers are engineers, and I thought, there are how different could they possibly be from us in Palo Alto sitting on these very expensive workstations? Turns out I was way off, And I went to places like Walmart and FedEx and British Telecom.

I learned no. It’s not the same. So first of all, I learned I didn’t know our customers at all. But he was smart enough to know that was an area I needed to learn. Another thing he asked me about was, do you know HP’s go to market path? And I didn’t even know what that really was. And so he said, okay, this is also extremely important. On those same sales visits, he’s gonna make sure that I learn HP basically had two major channels, a direct sales channel and a reseller channel.

And he wanted me to learn both. He wanted me to learn how it worked. He wanted me to learn what they’re capable of and what they’re not capable of. And I learned that, and I it was all new, completely new to me. The next area he assessed, and this was pretty embarrassing actually, but I studied computer science. I had zero classes in finance. I regretted as soon as I learned this stuff. I regretted that was the case. And he asked me a few questions about the analytics around my product.

And I remember the only one I could get right was he said, do you know what LTV stood for? And I somehow knew that stood for lifetime value. And then he asked me, but do you know how that’s calculated? And I’m like, I have absolutely no idea. So he realized that I was totally incompetent around the financial side, which is pretty important when you’re responsible for a product. So he said, I’m gonna do two things. First of all, I’m gonna send you a book, Basic Finance for Business or something like that.

It was not fun to read, but it was straightforward and every page was new for me. The other thing he did that was incredibly helpful was he called a friend of his in the finance organization of my division, and he asked him to tutor me. And once a week, he sat down with me and he said, look, you need to understand. If you’re gonna be product manager for this product, you need to understand every one of the KPIs that’s used to judge your product. And more than that, you also have to know which ones are actually in good shape and which ones are in bad shape.

I know that the most embarrassing part was I didn’t even know our product was losing money. I was an engineer on the team. Nobody told us this stuff. And I remember going to the rest of the engineers and saying, do you know that we’re actually losing money? We were so clueless. But he not only explained to me the the meaning of each KPI, but he explained to me, like, just so you know, this is really bad. This number is not sustainable. If you don’t find a way to fix this, you know, the leaders are gonna kill this product.

And then other ones were like, this is above average. This is good. So I didn’t have any of that subjective sense.

It’s one of the most obvious differences between great product companies and the rest, how they think of their engineers. We say if you’re just using your engineers to code, you’re only getting about half their value. Bill Campbell used to say this, there is nothing more important than empowered engineers. Tesla, SpaceX, Google, Amazon, Stripe, Apple, that’s the foundation of every one of those companies, empowered engineers. And what really gets me, look at all those companies out there that out outsource their engineering. Literally outsource their engineering. I’m like, when I find a founder that thinks that engineers are somebody you could just do a contract with Accenture or somebody, I’m like, you’re not serious about this.

Come back if you decide to get serious.

My view is, you do this assessment, which honestly takes a few hours. To do an assessment is easy. Then you need to do a coaching plan. Every manager that manages individual contributors is responsible for a coaching plan for their people. At the beginning, that coaching plan is just to get the person to competence, getting them to the level where they can do their job their team needs them to do. After that, it gets more fun. It’s more about helping them reach their potential. In fact, I was taught at that same HP engineering program that my job was to get people promoted, to get them ready to earn a promotion.

That’s how I was judged as an engineering leader. So that’s the coaching plan side. Now, these coaching plans are different for everybody. Sometimes, they literally need to spend some time in the field. Sometimes, what they really need to do is spend some time on the phones in customer success. It just depends on that person. I am also a big fan of onboarding programs though, where whole cohorts of new employees go through training programs. These are less personalized, but it’s more like, look, I don’t care how good you are, Everybody that joins this company, you’re not gonna know our customers.

You’re not gonna know our culture. You’re not gonna know our leaders. You’re not gonna know how decisions are made here. So an onboarding program is a way to accelerate this for a whole cohort of people.

The biggest thing I see is that they assume, I’m just gonna hire somebody, been there, done that. So they get somebody from Amazon, they get somebody from Stripe, somebody that’s clearly experienced what good looks like. But then they assume that just because they were successful there, that they’re gonna be successful in our company. And that’s not a true statement. There are so many differences. So our job in onboarding is to close that gap. Our job more generally in coaching

Would you rather be in sales being forced to sell this piece of crap product, or would you rather be in product where you can actually make it a good product in order to sell? The bottom line is the responsibility for the sales is on the product team. And in fact, if you really care about something like the real meaning of OKRs, which is all about outcomes, it is designed that way intentionally. This is Andy Grove. He intentionally that if my product is not selling, I need to get my ass out of the office into the sales organization, sit with them to figure out why it’s not selling.

Is it because the customers are not seeing it? Is it because the Salesforce has no idea what this product is really doing or how it does? Is it because they don’t have the sales tools that they need? Is it because there’s no reference customers? The point is this is what we are supposed to do on a Product Team, and explicitly, this is on the Product Manager.

I’ve also heard Sriyar describe this, which I absolutely love, but there’s a whole dimension to this. In fact, I’m gonna write an article and I’m gonna ask him to review it that he doesn’t talk about, but it gets to what you’re describing. And I think this is huge because in general, those three buckets are right. There’s a whole dimension though, which is there are two kinds of operational people. There are those that believe in operation or scale, really, what this is usually about, with process and those that believe in scale with coaching.

The problematic behaviors that you’re describing, which by the way, you are spot on, and I hate to say this because I absolutely love Europe, but it’s a bigger problem in Europe than it is in The US. The reason is because so many of those people are process people, and they don’t understand. And I’ve been sharing all these quotes from people they respect, like Elon Musk says in big companies, process becomes a substitute for thinking. Or Bezos describing, be very careful because process ends up controlling everything.

Steve Blank talking about process people taking over. Steve Jobs talking about process people taking over and no good product people wanna work there anymore. This is such a serious disease, and it has killed so many companies, but not just in Europe, all over. But this is, for some reason, process is especially attractive to Europeans. You might have a better theory for why than I have.

I see some companies like Spotify has done fabulous, and they are much more set the dial like we would in Silicon Valley for sure.

You’ve probably also heard the think deeply to move quickly. Same idea. So for example, the written narrative is a way to force you to really think things through, and then you’re gonna move a lot faster.

The right answer, the short answer is Outcomes. If you deliver results, you are gonna do really well. That’s an outcome. Like I said, literally, it’s an outcome, but the best way to get there is to do your homework. So the biggest thing I emphasize to new product managers is do your homework. That means go deep with your customers, go deep with the data, go deep on the industry, and go deep on the enabling technology. How

This would have been a great topic in the bulk of our discussion because this is really the difference between an empowered product team and a feature team. In an empowered team, you are literally giving ownership responsibility to the team, and that they build those skills. They build that confidence. They build those muscles. In a Feature team, they’re literally just mercenaries doing what they’re told. The way you do it is you empower them. You say, look, you own this. This is why on a Product Team, on an empowered product team, a product manager is responsible for the value and the viability of the solution.

In a startup, the founder is responsible for the value and viability of the solution. That is not an accident.

Honestly, I get to beat a lot of product leaders. I’ll just mention that I came out with a book recently called Empowered, and I featured eight product leaders that I really admire. And I highlighted them because very few people know them. And that really bothers me. They should be well known, but, you know, they all worked in companies where the founder got glory, but they were awesome. Tell me,

I would say the first and foremost thing is you have to establish that foundation of trust with the rest of the leaders of the company. And the best way I know to do that is to immerse with customers and really become first name basis with major customers. Make it so that nobody in the company doubts that you know your customers, what the issues are, what you need to do going forward. What would you most like to change about the world of

There’s a lot of things, but if I could I am not anti agile. I’ve been a big advocate for agile, but agile has had this unintended consequence because agile is just a delivery process. But if I could remove one thing, it would be that there would be nobody calling themselves product owners, and all these people teaching product owners how to do their job would not be doing it. And they would instead be people that know product would be teaching them the job.

You mentioned TikTok. TikTok has been nothing short of amazing. I would say what Tesla has pulled off, nothing short of amazing on every level. And their product strategy has been a very visible product strategy. They had to because it tied in so closely with the financing strategy. Those are two very good examples. What Amazon has done with AWS has been brilliant. We could keep going. Stripe is just hitting on all cylinders right now.