The nature of product | Marty Cagan, Silicon Valley Product Group

People don't buy the problem, they buy your solution. Obviously they don't buy it if it's not solving something they care about, but there are many products that are solving what they care about. The real question is, do you solve it better than everybody else so that they buy you? And that's where you need to take time. So this is more like the coaching I give the teams. I tell them, look, be careful. If you need to spend a little time on the problem, you're fine, but don't spend a lot of time because you need to save as much time as possible to come up with the winning solution. (upbeat music) - What can I say about Marty Kagan that hasn't already been said? He's the author of Empowered and Inspired to the most widely read in influential books on product management. He's also the founder of Silicon Valley Product Group, which he started over 20 years ago. More than anyone else out there, he's been producing the most consistently great and actionable advice for product managers and leaders looking to level up their product game. Before getting into teaching, he is VP of Product at Netscape, who's also Senior VP of eBay. I am humble to have Marty on this podcast. He is an absolute legend in the PM Kim and V and I can't wait for you to hear this episode. And with that, I bring you Marty Kagan. This episode is brought to you by Wimzical. When I asked product managers and designers on Twitter, what software they use most? Wimzical is always one of the most mentioned products and the users are fanatical. Wimzical is built for collaborative thinking, combining visual, text, and data canvases into one fluid medium. Distributed teams use Wimzical for workshops, white-boarding, wireframes, user flows, and even feature specs. And that includes thousands of built-in icons and a rich library of templates. See why product teams are leading companies call Wimzical, a game changer. Visit Wimzical.com/Lenny to have my own templates added to your account when you sign up. That's Wimzical.com/Lenny. Hey Ashley, head of marketing and flat file. How many B2B SaaS companies would you estimate need to import CSB files from their customers? At least 40%. And how many of them screw that up? And what happens when they do? Well, things don't know data about a third of people will consider switching to another company after just one bad experience during onboarding. So if your CSB importer doesn't work right, which is super common considering customer files are chopped full of unexpected data and formatting, they'll leave. I am 0% surprised to hear that. I've consistently seen that improving onboarding is one of the highest leverage opportunities for both sign up conversion and increasing long-term retention. Getting people to your home moment more quickly and reliably is so incredibly important. Totally. It's incredible to see how our customers, like Squares, Spotify, and Zora, are able to grow their businesses on top of flat file. This because flawless data onboarding acts like a catalyst to get them in their customers where they need to go faster. If you'd like to learn more, forget started. Check out flat file at flatfile.com/Lenny. (upbeat music) Marty Kagan, welcome to the podcast. - Ah, thanks for inviting me, Lenny. - It's absolutely my pleasure. I'm just gonna jump straight in. I've noticed that you've been getting a lot more philosophical about product, especially in a lot of your recent writing, including a recent post that you call the nature of product, where you talk about a lot of these core misconceptions that people have about product management. Essentially how people don't really understand how different it is to build product at a company with a strong product culture versus what you'd call not such a strong product culture. And the way that you described it is that it's trying to explain to someone what the Grand Canyon is by just showing them pictures of the Grand Canyon. And so I'd love to just dive into that and just kind of hear your take on this new philosophical bent that you've taken on product and these misconceptions that you've been seeing across product and product management. - Yeah, sure. I mean, it's frustrating and that's kind of what caused me occasionally I go through these sort of philosophical waves where I look a little harder about it's frustrating because I really thought by the year 2022 we would not have such a chasm between how good companies work in the rest. There's such strong incentives, like just the profit mode of alone. Why don't more companies want to work like the best? So I find that just perplexing. And yes, it's true when I, and one of the funny things and I thought you could relate to this Lenny, I have friends on both sides. (laughs) I have friends on both sides. The ones that work in not very good companies, a lot of them honestly don't believe me when I describe how good companies work. They're like, nobody does that, you know? And then when I tell my friends at the good companies they often say like, nobody does that other. Why would they do that? Are they crazy? Who would want to work that way? And so this is mind-boggling to me. And anyway, when I try to explain to somebody that's never actually worked on a real product team, what it's like, you realize that sometimes it feels like I'm speaking a different language to them. And what I realize is that they are so ingrained in this sort of very, very, and I don't even wanna say old school because it's not the fact that it's old, it's just the fact that it's obsolete. It's some, they have this idea that a product manager does requirements in some form or another, PRDs, user stories, whatever you want. And then a designer's job is to basically make it pretty and maybe do some wireframes. And then the whole mess has taken its sprint planning to the engineers and you say, this is what you need to build next. That is so ingrained. You know, and the road maps, the quarterly road maps come and it's so ingrained. And they think that the job is, yeah, our job is to crank out features. And a lot of them don't even think twice because that's all they've ever known. And of course, I try to explain to them, you know, that's really not how it works in any of your favorite products. Any of your favorite products or companies, it's a very different animal. You know, you've got, you've really got true peers. They're not there to it. The developers aren't there to just implement your dumb ideas. They are there to help you come up with a great solution. The designer's not just there to make your thing look pretty, they're there to help create a great experience. And by the way, you have a very different job as product manager. You need to bring skills to that team that the team doesn't have in design and engineering because together you're able to really do what you need to do. So when I describe that, it's pretty different. These are not minor differences we're talking about. These are pretty dramatic differences. I really do believe at this point in time that feature teams and real product teams should not use the same string product manager. The job is so radically different that it just is misleading to call them both product manager. -Perfocus, listening to this and they're like, "Hmm, which one do I work on? "I'm not even sure." What are some maybe like three to five signs that you work at a feature factory or feature team as you describe it? -Yeah, well, it's not hard to tell for sure. Fortunately, I mean, if you've seen both, it's not hard to tell. In a feature team, basically, you are handed a typical roadmap and a roadmap like almost everybody, even though I wish this wasn't the case, almost everybody had the same thing that it's a prioritized list of features and projects. So some stakeholders got together usually quarterly and they say, "Look, to run our part of the business, "we need these features." It's not really complicated, we need these features. And so they're giving you these features. Now, realize these features are possible solutions. So you're being asked to do a little design and a lot of coding and then some QA and then deploy. And more generally, you're there to serve the business. Now, compare that to a real product team. In a real product team, first of all, instead of being given a roadmap of prioritized features, they're given problems to solve. So it might be a customer problem. It could be a company problem, it's all fair, but there are problems to solve. And the team is then given the skills so that they can come up with the best solution to that problem. I mean, that's sort of the Netflix principle is push the decisions down to the people that actually have the knowledge to best solve the problem. That the engineers are working with the enabling technology every single day. The product teams are working with the users and customers every single week. So of course, those are the ones that are closest to those are the ones you wanna push the decision down to. Another difference is when you're given a problem to solve, that's not output, that's outcome. So you either solve it or you don't. As you probably know, most good teams today are doing continuous deployment. Continuous delivery, they're releasing many times a day. Who cares if you make another release? If it doesn't actually solve the problem, it's nothing to brag about, right? It's nothing to celebrate. So in a real product team, you celebrate when you actually solve the problem. When you accomplish those results, that's how we say product teams are about outcomes. They're not about output. So feature teams and product teams, they, you know, they're superficially, they're both squads, but they are very, very different. Now it's worth double clicking on the product manager role because fundamentally, the designer and the engineering role are not hugely different. We're asking the designer and the product and the engineers to step up and care just as much about what you build is how you build, but they're using the skills that you learned in university or wherever. On the other hand, in a feature team, the product manager is basically there to herd the cats to get it now. And that's non trivial, but they need to get stuff organized. They need to get stuff gathered, these requirements, you need to document them in whatever tool you're using, or something, and then you need to get it to sprint planning and you need to make sure it comes out. That's hurting cats. It's essentially a project management role. But on an empowered product team, where you're trying to come up with a solution that solves the problem you've been assigned, that's much harder because that means we have to discover a solution that's valuable, usable, feasible, viable. Now while the engineers definitely own feasible and the designer definitely owns usable, valuable and viable, which are two of the hardest things to do, that's the product manager. And that's a pretty, those are pretty big shoes to fill. Those are hard. That takes skill. It takes knowledge. That's why we say, you know, in order to be a product manager on a real product team, you've got to do your homework. You touched on this idea that people mentioned this, this way working sounds like a dream land to folks that haven't experienced it. And as folks on Twitter, what questions to ask you and that came up a couple of times is people are like a reader stuff. And I'm like, this actually exists anywhere that I've never experienced this way of working just to like make people feel like this is possible. One is their companies. They are like good examples of this way of working. They like to describe and then to just reaffirm this is possible. This happens at companies out there. Correct. Oh, I mean, it's funny. So first of all, and I should always say this at the very beginning, whenever I work with teams, I always try to remember to say this somewhere. Nothing I talk about and honestly being very clear, nothing I've written about and inspired, nothing I've written about empowered was invented by us. All we do is share the practices we see being used in the best teams. So the heuristic is pretty easy. If it's used by several of the best teams, we're like, okay, let's start recommending it. Let's see how it works there and if it works well, we'll start advocating it. And on the other hand, somebody says, oh, if you heard about this process or if you heard about this tool, and if none of those companies are using it, I'm like, don't bother me. It's either it's either snake oil or it's not proven yet. We don't invent any of this stuff. We just try to share it. There's a little bit. I mean, I don't want to, I'd say that the thing that we do is we try to untangle the company's culture from the technique because every cup, you know, Amazon's got their favorite cultural stuff. Google does Netflix does, Stripe does and don't get me wrong. I love those cultures, but they're all different cultures. They're very different cultures. So what we're trying to do is untangle that and share the techniques themselves. But you can read books like working backwards from Amazon describes what I talk about all the time, but it's using Amazon terms. You can read no rules rules from Netflix. You can see how that's done. You can read build that talks about how Apple did it. You know, it's just, it's all great, but you've got to work a little harder to see the common threads. That's really what we're trying to do. But all these companies, Stripe, Fabulous Shopify, you know, look at what Slack is done, even props to Spotify. They've been able to hold their own against Apple and Amazon for so many years. I mean, and of course, I'm talking about well-known brands. There there's countless small companies that nobody's heard of. But most hopefully if they keep doing well, you know, people will hear what then one day, but no, it's not a few companies. And there's great companies all over the world today, but it is true that it's a small fraction of total companies. And that's the part that really bothers me. Do you have a sense of what that fraction is, what percentage? You know, I had this conversation actually, you know Shriosh Doshin too, don't you? He's one of my favorite thinkers. Yeah, he's one of my favorite thinkers in product. He's just terrific because he's also one of those people at first, he was asking me, do people really work like you write about, you know, you really, they're that clueless. And yes, they really are. They really, that's all they know. And of course, the bigger question is why, why would they really work like that? We will get to that. But anyway, you know, I don't know. One of the things that makes it hard is it's not just, there's a lot of people that write software in the world. And first of all, you can break it in half saying those did write commercial products, meant to be bought by lots. And those that just do custom solutions for a long time. And I don't know if this is still accurate. But for a long time, the industry analyst that I read said that it was actually much bigger number of people doing custom solutions around the world. And so, so none of those people would really count. So it's hard to say, I don't even know how, does anybody know how many companies really do commercial products and then what percentage. My purely anecdotal guess is maybe 10 to 15 percent are good product companies. Something like that. Sweet. I love that there's a number. All right. Who knows? Who knows? It could be orders of magnitude off. Seems seems reasonable. So lens that I want to use for part of the rest of our chat is this documentary that you've been recommending in some of your writing that I recently watched and I'm really excited to chat about it. It's a documentary called The Lost Interview where the interview steeped jobs after he was fired from Apple, but before he came back to run Apple. And there's a ton of insights that you've been able to extract that I also loved listening to and thinking about. And I'm excited to try to chat through this. So first question is just what about this interview has struck you most initially, broadly? Yeah. Well, one of the reasons I loved it is he very rarely talked about product. He loved to talk about his products. He loved to talk about why the iPhone was awesome. Why the iPod was awesome. Why the Mac was awesome. But the nature of building products was not. I mean, that was sort of his secret sauce, if you will, as he had a very good on insights to this. And so to find this hour plus interview where he's very thoughtful, very sort of, you know, he had had a chance to kind of think through what went well, what went wrong. And to answer your question, you know, in my own writings. And in fact, in the recent book, "I'm powered," I share my theory for why there's such a big difference between the best and the rest. In other words, why is it in every company trying to work like the best companies? I mean, why not? You're valuable. Look at the valuation they get for money alone. You'd think it would do that. And my best sort of theory was that, well, the biggest reason I see is that they they've never worked at a company like that. So they don't know what it looks like. They don't know what it looks like. And then I watched this video, which as you know, sort of resurfaced recently. And it's, Steve Jobs shared his theory from 1995 for God's sakes. And I'm listening to it and I'm going, oh my God, his theory is better than my theory for sure. And it's still more relevant. And I would say of all the things and he talks about product discovery, he talks about, process people, he talks about all these really relevant topics. But the one that struck me the most was his theory for why there are so many bad product companies. And his theory was, and by the way, I don't want, I hope, everybody that's listening to your podcast, it costs $4 to rent this on Amazon Prime. Definitely you should watch it. They'll all think, so they'll let my summary discourage you. It's worth watching. But anyway, he shares that he thinks what happens in general is companies get bigger. Obviously they wouldn't have got big if they didn't have a decent product at one point or another. But what he was talking about is the same thing I am. Why is it that so many companies lose that mojo? And his argument was because as a company gets bigger, product historically became less important. The people in a company that would be celebrated were marketing people, sales people, finance people. These are people that, because, you know, if a company stops innovating, these are the engines for growth, right? Sales marketing or not growth with finance but cutting costs. And his argument was this happens over time. I'm pretty soon. These are your leaders. They're the ones that have been promoted. So then what happens? Good product people don't want to work there anymore. And they leave. And they go to a company that values product. I think that's a better explanation than any other that I've heard. And it was so prescient because when he said this, this had yet to even happen to so many other companies, but it still happens all the time. I wrote an article a while ago called devolving from Good to Bad that was observing some of this, but he really tapped into it. And honestly, I think he spot on. I like that he describes these as diseases of a company. They own like enough market share. This is what happens. There's just growth is happening. They're winning. They don't need to keep innovating and it becomes this disease. And it's a really powerful way of thinking about it. That you want to try to keep this disease from taking over your culture and product and company. And I think there's like market share and then just generally it happens. The company's just doing well. Things are going well. We just keep at it. It's not breaking anything. Why'd launch something risky and new and why not just keep selling this thing that everyone seems to want. And actually, Lenny, I think it's worse highlighting because that is an anti-pattern. I see a lot. Especially after the founders leave. You know how a lot of times in product will talk about there's there's value creation activities. There's value capture activities. Discovery is all about value creation. Optimization is all about value capture. And they're both great. Absolutely. You should do both. But so many companies after the founders leave, they're scared. They're literally scared. The product teams are scared. The executives are scared. And the reason they're scared is because they don't know what is essential and what is incidental. They're scared. They're going to like hurt the thing that's fueling the business. Now, of course, the founders knew the thing because they were there from the beginning. They have all this institutional knowledge. They know what's important. They know what's not. And they have that confidence. Sometimes we talk about the moral authority of the founder. They know and they know deeply what is essential and what's not. But when they're gone, very often we see companies that are scared. I can tell because all they're doing is a little low risk optimizely A/B tests. They're just doing these low-TB tests. They're just tweaking the workflows. The main flows grows retention. They're just tweaking. And again, there's nothing wrong with that. But those things will not innovate. They will not cause major improvements to the company. And so once they stop doing real discovery, to me, it's just the beginning of the end. What's interesting there is if folks at the top are kind of running it. I have ideas or not confident about where to go. You think they would empower their teams on the ground to figure out what to do. Instead, they turn into these top-down feature teams and they tell them, let's just build this thing. I don't know, but it's probably the best idea. I probably know more than you do than they do. And then fact, that was one of the diseases that Steve Jobs highlighted in that interview. He called it the disease of the stakeholders, of the managers, where they think that an idea is 90% of the work. And that's how he called it out. He's like, "They don't understand. The idea is minor. The idea is just to start." I think he said, it is like the whole craftsmanship of going from an idea to a product. This is what we call product discovery. He was describing product discovery and how things change constantly with every iteration. You make trade-offs. It starts off one way. It ends up another way. And of course, he's pointing out that most of these executives have no idea, no appreciation for that's actually how you get a great product. It's not that a bunch of executives go in a room and they come up with their prioritize list of features and then they just tell the teams to build them. In fact, we know at this point only about 20% of those things will generate any kind of positive return. So you think there's enough evidence out there that they would realize that was fatal. But I think it's a lot of arrogance because every executive thinks they're smarter than every other one. And so theirs are the better ideas. But it's really not that way. I mean, good product teams and good product companies know that on ideas, just sort of the very sparkle in the eye is just to start getting to a product is what matters. And that's work. It touches on a question I definitely wanted to ask, which is sometimes founders or leaders think they're like, "I just know what to build. Why do we need to go through this whole thing just like just build this thing? I'm very confident this is the answer." And what you talked about just now is a big reason for that right is a lot of times you don't and you think you do and a lot of the magic happens in that process of building it or rating learning, talking to customers. Is that as I see it? Absolutely. And there is one sort of danger zone that a lot of product teams inadvertently fall into there, which is, you know, when we talk about discovery, technically there's two kinds of discovery, right? There's discovering the problem to solve that you should focus on and discovering the solution that you're going to deliver that people would buy. And a lot of product teams, the founder knows the problem. In fact, most of the company knows the problem. But a lot of times a product team thinks that they're supposed to, even if they're confident on the problem that they're supposed to go through these some number of weeks or months of problem validation, you know, making sure that people really have that problem. Enough of them have that problem. They understand that problem. And you know, again, in an ideal world with no constraints, not really a problem. But in the real world, the clock is ticking. And if you use say two weeks up, just verifying the same thing the founder already knew, that founder is probably very frustrated at this point because you haven't even got to work on the solution. And people don't buy the problem. They buy your solution. Obviously they don't buy it if they, if it's not solving something they care about. But there are many products that are solving what they care about. If you need to spend a little time on the problem, fine, but don't spend a lot of time because you need to save as much time as possible to come up with the winning solution. And it's worth pointing out since we were talking about Steve Jobs. He was all about the, that was solution discovery when he was describing the sort of 5,000 things you'd keep in your head. That's the solution discovery. So that's important. Product teams need to know that that's where they will either succeed or fail. I know that, I know this point is really important to you. This idea that PMs are taught that their job is to figure out the what and not the how and just to reinforce this point. You're, you're a big fan of no, that's completely wrong. PMs are very responsible for the, the how also. That one always makes me laugh because I was thinking, do you know how, how many hours a week I need to work if that was my only job? Just just, you know, I'd probably I'd phone it in 15 minutes a week. I'm done. I did my part. This is ridiculous. And of course, it misses again, all you have to do is think through it a little deeper. When you're trying to come up with a successful solution, I mean, there are different taxonomies out there. The one I use is it's got to be valuable, usable, feasible, viable. But most products fit. Those are the risks. You can call them different things, but those are the risks. And the product manager is responsible for making sure that the solution is valuable and viable. And that is hard. That is hard. That takes real work. And that's part of the how that's a pretty damn integral part of the how as well. Now, you don't tell the engineers how to code. You don't tell the designer how to design, but you do have a big part. All of us together are coming out with that how. So the how is how it all works. And obviously, how you monetize privacy issues, security issues, how it's going to go to market. These are all how, but they're product responsibilities, product management responsibilities. They're not more or less important than what the designer engineer does because all four of those risks, if any one of them fails, you've got a failure of a product. So those are table stakes. And that's why I laugh when I hear people say, oh, you just have to say the why is so trivial. And it's and it's just so uninformed. I just don't know where the origin is for all that stuff makes me think about man always joke that they're like, I want to wear something more interesting to events. Like I always wear a suit. It's always got to be a suit. So boring. And other folks are like, shut up. It's so like, why would you want to complicate the life of men and having to address more creatively. Like we got a good thing going with suits. And it makes me think about if the jobs of a PM are just to find the problems like, all right, let's let's let's go with that. Life's good. And turns out it's not. Yeah. Anyway, your your last point also made me think about this recent tweet by I think is Patrick callison or John callison about how a lot of people think user research. It's kind of like user research informs exactly what you or informs which you build. That's how people think about it. It's like user research leads to what you build. And his point is really interesting that research user research informs your model of the user and the customer and that model should inform what you build. And you're all constantly trying to refine this model, but you should have a model of your customer and your user in your head that you come back to versus like relying user research and so are your questions. What's your take on that perspective? Yeah, I mean, first of all, what they've done with Stripe is so awesome. And it's another great example. And I love what they, you know, sort of picked and choose from great companies to create a culture for themselves. So I'd absolutely agree, but I'd go a little further because user research is a great topic. I mean, right there. It's a great product topic. I love it. I'm a big fanboy. Use the research. Well, you just heard me basically arguing the same thing. Don't be going out there spending all your time just validating the problem, especially when we know he's he's saying that too. He's trying to talk about building the mental model of our users, which is so important. This is, you know, well designed products are feed off of that. However, there's another layer around user research that I find is even a bigger source of confusion. In fact, I was just talking to a team this morning. That was saying that, yeah, what they do with user research is they they test their prototypes. And is in and when they get enough of user saying how much they like it. They build it. I'm like, no, that's not why we do user research. And that is not going to fool any smart leaders. The main reason I now again, we're kind of back to the problem discovery solution discovery. But when we're most of our time needs to be on solution and that's prototyping that's testing with users testing with customers testing with stakeholders testing with our developers were testing constantly. We are not just trying to find out, you know, if they like it. In fact, it's just the opposite. It's we are when we're doing user research. We're finding all the reasons they don't like it. In fact, that's an Elon Musk quote is when you do user research, you should be focused on finding all the reasons they won't use your product. Even though Elon Musk has some issues right now, he's pretty good at product. And so he is very good at this. And that's that's how you want to think about that. This is often the user researchers will talk about the difference between generative and evaluative user research. And so most of it in terms of number of, you know, valuable things we get out of it is evaluative is there telling us the reasons they won't use it. The only other thing I'll add to that you didn't ask about this, but it comes up all the time. I hate it when the user researchers go off and do the research themselves and bring back a report. Not because they don't know what they're doing. They do know what they're doing. The reason is because the report is too often ignored. And so to me, the rule is, and I tell this to use a researchers at the company said, I coach. If the product manager and the designer are not available to be there during your product, their products test, cancel the test. They need to be there. This is what makes them useful to their team. I 100% agree. I have this memory of going to Paris with a research team ahead of engine, head of design on our team, at least. And I and the researcher all went to Paris to do these like focus groups with with Airbnb hosts. And our researcher was very adamant that we come with her. It's not just her coming back with tons of insights. And so 100% find value there. And engineers, especially being involved in that process, I find to be super important. That's when the magic happens. This episode is brought to you by modern treasury. Modern treasury is a next generation operating system for moving and tracking money. They're modernizing the developer tools and financial processes for companies managing complex payment flows. Think digital wallets, via crypto on ramps, right sharing marketplaces, instant lending and more. They work with high growth companies like Gusto, pipe, class pass and Martetta. Modern treasury is robust APIs allow engineering to build payment flows right into your product while finance can monitor and approve everything through a sleek and modern web dashboard. Enabling real-time payments, automatic reconciliation, continuous accounting and compliant solutions. Modern treasury's platform is used to reconcile over $3 billion per month. They're one of the hottest young fintech startups on the market today. Having raised funding from top firms like benchmark, altimeter SVB capital, Salesforce ventures and Y-combinators, check them out at modern treasury.com. I want to come back to this idea of feature teams and just what folks, specifically what, what can people do when they're working at what you call a feature team or feature factory to either understand what the experience could be like or just work in a better way, even if their company's not shifting to a new way of building product broadly. Sure. Well, you know, a lot of companies are intentionally trying to change to real product teams. This is what most people mean by a transformation. So a lot of them are, but even if they're not, I always encourage you know, a lot of people will ask me, should I just give up on this company and go to a decent product company? And I always say before you give up, just give this one shy try and I suggest you go to your manager and say, look, what do you think about us doing an experiment for the next corner to why don't you let us try running like this? And if it goes well, great. If it doesn't. No harm. You know, we'll just go back to the way we were. So it's not that hard to try it on a product team by product team basis where it gets expensive and risky. Of course, it's changing the whole business units. So if it's just a product team, usually they'll let them try, especially if the person making this argument says, you know, I've learned that some of the companies we admire are not working the way we are. And maybe we should try this. Just while in a topic, what is it they try or do? What are some of the things that a team could do? I know you might have got you may be getting into this. But I'm curious. That's exactly what I was going to suggest. So so let's say they're giving thumbs up. Go for it. Give you a quarter. Go for it. We'll see what it were. What it's like. I've been, you know, people are curious. So to me, there's a few things that you want to do. First of all, you want to make sure and the manager can help a lot. But the product team could help. You know, manage up enough to do this. The first is you need to make sure the team has a problem to solve. Rather than the feature to build. Now it's not that hard to reverse engineer. So if somebody tells you. You got to go implement by now, pay later on our ecommerce site, which is like on a thousand roadmaps right now. Right. If somebody tells you that it's not that hard to go to the stakeholder that requested that and say. You know, we're going to get to work on that. But can you tell me like how are you measuring success? We want to make sure that what we do, you consider it successful. How are you measuring success? For something like that, it's usually pretty obvious. It's like conversion rate or or average shopping card value or whatever. It's just some KPIs that they care about. So you say, all right, you're under your your belief is that if we add by now, pay later a lot more people will be able to buy and transact. And so it's going to pay off. And it'll show here. Do I have that right? And they'll probably say yes. And they might say, well, no, we're doing it for international purposes or some other thing. Good to know. Make sure you capture whatever it is. So that's the first thing. What problem are you trying to solve? Now the hardest part is like I said, usually we have a designer and engineers that are very up for really doing what they were born to, you know, train to do. But the product manager usually needs to do some work to get themselves to be able to do this because a typical. You know, I hate the idea of those companies that have separate product owners because product owner is just an administrative role. Product owners almost never have the skills to be a product manager. And so that's a problem. But let's just say there's a product manager and nobody's ever coached this poor person. And so they really don't know much. So the first thing that product manager needs to do is get themselves prepared to contribute to their team the way they need to in general. That means four things. First of all, they have to really get to know the users and customers. They have to be considered a pretty much one of the experts on the users and customers. I remember when I was an engineer wanting to become a product manager, the person coaching me said explicitly that I was not allowed to make any decisions for the team until after I visited 30 customers. His number was 30 15 in the US 15 in Europe. And it was a three week business trip that he arranged that fixed that. And the funny thing was I didn't think I needed to visit customers because I was a developer before that. And I was. was building products for developers, unlike only on it. That's the one thing I've got is I know our customer. And he said, well, all I know for sure is that's never true. And so I had to go visit customers. But anyway, that's the first thing. The second thing is they have to be an expert in the data. How is your product used? How is that change over time? What's the sales analytics? What's the user analytics? So you have to know how your product is actually used, which is just another way of knowing your customer, but important. The third thing is, and this is usually the hardest one, and it's the one that your stakeholders will judge you on, is you have to learn the different parts of the business. You have to know how it's marketed, how it's sold, how it's paid for, how it monetizes. If there are any compliance, regulatory, privacy, security issues, you need to know what those are. So that you have to convince those stakeholders that you understand what the issues are, and you understand what to look for, and that you convince them that if there's ever any question, you will bring them a prototype that they can see and make sure it's okay. So you need that trust with the different parts of the business. And the fourth thing is you have to know the competitive landscape. You have to know the industry, you have to know the trends. I consider this one of the fun ones. There's some good industry people to follow. You can do that. So those are the four things you bring to the team. Realize the designer doesn't have this info. The engineers don't have this info. If the team is going to be an empowered team and they're going to come up with solutions, they need somebody on the team that brings this knowledge. And that is you as product manager. That is the single biggest area empowered teams fall down. The product manager is ill equipped, or a nice way of saying incompetent. All right. Third, if the team is now going to make decisions, they need the strategic context. In other words, they need to know the big picture. What's the product vision? What's the product strategy? What are other teams doing? How does that relate to what we're doing? That's the strategic context. So normally we get that from our leaders, but at the minimum, the product manager's going to have to go learn what that is, especially the product strategy. All right. And then finally, the product teams need the skills, discovery skills and techniques, which to me is a fun part. That's why I wrote the book inspired was to share the most popular techniques. There are other books too that talk about those techniques for discovery, but read something, learn the techniques. There are good techniques today, better techniques than we've ever had. We've been doing product discovery for a very long time. In fact, Steve Jobs in '95 did a really good summary of it, but the techniques today are dramatically better than what they were when I first learned. And what he was talking about, dramatically better. So you need to learn the techniques. That's the tools of the trade for a product manager. So to your question, you're a feature team. You want to become a, you know, want to give it a shot, be in a real product team. These are the four things you need to go out and do. And they, just to be fair, they don't take long. The longest one is the product manager learning, you know, those skills if they've never learned them before. But even that typically takes two to three months. Wow. That was incredibly insightful. I'm curious how a PM gets set themselves up for success trying like this, trying something like this because I feel like it's a high stakes experiment. If it doesn't work, the company would be, oh, no, this sucks. Doesn't work. We're not going to do this. That happens. You mentioned. Yeah. You mentioned a lot of things people can do. And then you mentioned reading inspired. Is there anything else just like things that would set people up for success in one of these experiments within their larger company? Well, in particular about what we're talking about now, Teresa Torres' new book, Continuous Discovery Habits. That's a very good book. It's right on point. It talks very much about these skills. And, you know, it's, it will basically hold your hand through those first weeks. Another good book is Sprint, you know, Jake Naps book. That also will hold your hand. Now, that's a particular technique to hold 400 pages on one technique, but it is a good technique. Those will hold your hands through it as well. The other thing is you can go out if you can find somebody who can coach or mentor you. I mean, that's how I learned it. That's how most people I know learned it is they had a, you know, they had a manager that gave a shit about their career. And they were like, this is what you need to do. I remember why I first learned about the discovery concepts. I was an engineer and then I was, I had been promoted to Tech Lead. And my manager said, you know, now that you're Tech Lead, you have to care as much about what you build is how you build it. And, and he said that means you have to get involved in things you were never doing before as an engineer. I had been an engineer for several years sort of working my way up the, the little ladder. And, and I thought that was super interesting. In fact, that was my first taste of product because I started what we called discovery today. I started getting involved. I started going out to customers. I started learning these problems. So, yeah, it's, I wish more, you know, if I could change one thing in the industry, it would be we would all, everybody would have a decent manager that cared about their career and could help them get better at their job. How do we, how do we make that possible? You know, one thing, because sometimes I have a tendency to be kind of cynical, you know, when it's the world has changed so little over the years. But I have been very happy lately. If, now I know what caused this, it's the great resignation that's caused this, but executives at Microsoft, Google, Netflix, Apple, they've all been bragging about how much they care about coaching. Did you notice that? I mean, literally, Sundarn at Google has been saying that the number one thing they look for in their leaders is a good coach. The number two thing is that they're not a micromanager and they know how to empower their teams. But at Microsoft, they are looking at, they have three principles for their leaders, their managers that they've been advertising. Number one, coaching, number two, caring. Forget what number three is. And then at Apple, they have four big responsibilities for their leaders. Coaching is one of them. So they've all been more vocal about this. Now, of course, this is not an accident. They've been caring about coaching for a long time, usually because Bill Campbell impacted the companies, but they care about coaching. But now they're talking about it a lot more. They're essentially saying, come work here. We care about developing you in your career. Yeah, I know that you teach coaches. You have a conference, I think recently where you're coaching coaches. Is there a. Yeah, that's so much of conferences. Our problem is, I mean, SPPG were very small, we were just five people. And we've been booked out for nearly a year. So there's very. We are always asked, who can we recommend? And the truth is we don't have that many people that we know and can recommend. I mean, there's a lot of people that do feature team stuff, but the people that ask us are because they want to become like a great product company. And so we don't know that many. So we've decided to do a session in Europe and a session in the US where we invite people that are independent coaches. We don't charge them any of these. This is just a way to get to know them and hopefully help them. So we did that in London a couple months ago and we're going to do it in New York in December. It's definitely one of the most common questions I get is how do I. Where do I find a coach? Who's a good coach? And so I really love that you're creating more coaches and helping coaches get better. Along that same line a little bit, how do you think the role of product management is changing and evolving? This is one of those sort of two forky answers. At good companies, it really hasn't changed much at all. And I mean for more than 20 years, it really hasn't changed. Good product companies. Now the techniques they use have changed in some dramatic ways. But the job, the principles, hasn't. However, if you look more holistically at the industry, what a cluster. What a mess. Look at, you know, there's so many different product related titles, most of which are ridiculous. The two that really drive me nuts are all over Europe. You find product owners. And those product owners are taught by agile coaches. Most of which have never done product for a day in their life. All they know is process. So they're teaching a process. It's as ridiculous as taking somebody off the street and saying, I'm going to teach you scrum and then you're going to all of a sudden be an engineer. How ridiculous is that? Scrum doesn't teach you how to develop just like a product owner. Course doesn't teach you how to be a product manager. So the result is inadvertently the blind leading the blind and we have never had such a high proportion of completely unqualified product people. And of course, in the US, that's not as big a problem in the US. It is a problem, more on the East Coast than the West, but it's not as big a problem. We have other things going on, sort of, you know, there are some very good implementations and definitions of product ops out there. There's also some really bad ones. And those are causing the same problem. You know, one of the things I try to tell, forget all these stupid roles and terms and all this, there's really three things that are sacred for a product manager. And I don't really, I'm very flexible on everything else, but these three are sacred because they're right at the heart of what it takes to succeed at the job. The first is that that product manager needs unencumbered access to their users and customers. Somebody that tries to get in between of them and their customers is not helping. Even though they're often well-intentioned people, they say, "Oh, it's my job and customer success to do that," or "My job and sales," or "No." That is like you get cut off from your customers, you're screwed as a product manager. Second, product manager needs unencumbered access to the engineers. Because if you're not working every day with a set of engineers on solving problems, you are not a product manager. So, you, again, there's these helpful people called product owners or project managers or all kinds of different variations where they think their job is to interface with the developers and to play sort of a mediator role. And they don't understand why they have an innovated for years. That's why they cut that critical thing. And the third is unencumbered access to the stakeholders. Because a good product is solving what's just now possible. That's why the engineers are so critical. For real users and customers, that's why that's so critical. In ways that work for the business, which is why the stakeholder access is so critical. If you have those three things, direct access to those three things, that's what's critical. If you have other responsibilities, well, as long as you're willing to work crazy hours, that can work. But if you're working, if you want to have more of a sane life, you can take all this other stuff, project management, quality assurance, product marketing, all this stuff, runtime, production operations, literally, you can pass those to other people. But don't delegate those three things. I just keep begging companies. They don't realize the damage they're creating when they do that. And of course, why they do it is no secret. They say, "Oh, that product managed your job. It's too hard for one person." So we're going to split it in half. And they have no idea the damage they're creating, but that's what they're doing. So pulling off other responsibilities is no problem. It's a good thing to do, especially as you grow, but never when you touch those three sacred things. Awesome. I was exactly going to ask that. That the PM role is so full of things to do in such an intense job with so many responsibilities. And so the intention is good. Make some things off the PM's plate. Specifically product ops I've been seeing grow, as you've said, just to kind of double click on that is your sense that's not a great role to have and not a productive direction or other times when that's actually helpful. Well, this is where, so from what I just said, if you now talk about product ops, if product ops is created to replace one of those three things, which is some of the common definitions, it's bad. If product ops is there to take my favorite def, I mean, there's lots of good definitions of product ops to, but you know, some jobs, some, I should say some products have a big runtime responsibility, runtime production, production issues, triaging bugs, trying to figure out what's going on. You know, a little bit of that is totally normal, right? Everybody does that in every company. But sometimes it becomes so much that there's just no time left for figuring out what should be built next. It's just fighting fires every day. That's a good definition of product ops. Another good definition are the people who create the tools to help product managers be more productive. That's a good definition. But notice those aren't taking away any of those three things. So one of the common definitions is they're like, oh, well, we get so much data on how our products are being used for our customers. We've created a product ops person that's going to sort through that data and they'll tell the product manager what they think they should hear. Just to reinforce this point, what are the three things again? In case folks think at all. Yeah. Direct access to customers, direct access to the engineers, direct access to the stakeholders. Awesome. The last question is are there other trends that you're worried about in product management where the role of PM is going? Well, I am very worried about the two trends I just described. I'd say the thing that has always been a risk and it's just not going away. And by the way, Steve Jobs talked about this. This was the other disease he talked about. And that's the disease of process people, which by the way is another one of the bad instances of product ops is process people. Well, the truth is, and I know where this comes from, I understand it, but scaling is hard. Does anybody know anybody who doesn't think it's hard? It's hard. And fundamentally, there's two ways to scale. You can scale with process or you can scale with leaders. The only way I know that leads to good outcomes is scaling with leaders. But the easier, more appealing one to so many companies is scaling with process. And that's why you see, like you might look at something like safe and say, are these people freaking crazy? Are they nuts? There is no good there. It is just all, it's just repackaged waterfall. What the hell are they thinking? Well, what they're thinking is, oh, we have an answer to scaling with process. And that is very attractive, especially to some old school CIO that doesn't even understand software. And so it grows like crazy. And you know, that's not the only one. There's a bunch of those processes and the people are fooled. It's just marketing. So they call themselves agile, but there's nothing to do with agile. It's sort of the antithesis of agile. So I am very worried about that trend of thinking that process is ever the answer. Because it's not. It just isn't in all the best leaders I know whether we're talking Bezos or whether we're talking Elon Musk or, you know, anybody, Steve Jobs was saying it in the video. Be careful of the disease of process people. They will destroy your company. What an incredible way to wrap up. Where just two last questions, where can folks find you online if they want to reach out? Learn more. And how can listeners be useful to you? Well, I mean all of our stuff we publish for free at esppg.com, Silicon Valley product group. You can also find me reluctantly on social media. But I do the minimum possible signal, the noise ratio on social media is so terrible. I try to focus on other places. But that's where you can find me for sure. And yeah, I mean, I'm, I mean, at this point in my career, I'm just having fun. I'm not looking for anything from anybody. I hope, well, I'll tell you one thing I love. I love getting hard questions. Most of my articles are inspired by questions that I have never got before. And so I, when I hear the question, same question enough, I realize maybe I should write about it. And I love that, especially if it's something I need to go learn more about. And I do have at this point in my career a great role of X of people that I can go to and say, you know, Hey, Lenny, what do you think about this or Shriash or Teresa? All these people I know that are very smart and I can go to them and say, what do you think about this? And I sort of put everything together. And I write about it. So yeah, if you really have tried and can't find a good answer to a hard question, feel free to email me. Amazing. Send your hard questions to Marty. Marty, thank you so much for doing this. This is everything I hope it would be. I am really thankful that you joined me and thank you for being here. Well, thanks again for inviting me, Lenny. Good luck to everybody out there. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify or your favorite podcast app. Also please consider giving us a rating or a leaving review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lenny's Podcast dot com. See you in the next episode.