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

1. 0:00 – 7:49

   The biggest misconceptions about what a good product team does and looks like

   1. MCMarty Cagan0:00

      People don't buy the problem, they buy your solution. Obviously they don't buy it if they, you, (laughs) 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- I tell them, "Look, be careful. 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."

   2. LRLenny Rachitsky0:37

      (instrumental music) What can I say about Marty Cagan that hasn't already been said? He's the author of Empowered and Inspired, two of the most widely read and 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 was VP of product at Netscape. He was also senior VP of eBay. I am humbled to have Marty on this podcast. He is an absolute legend in the PM community and I can't wait for you to hear this episode. And with that, I bring you Marty Cagan. This episode is brought to you by Whimsical. When I asked product managers and designers on Twitter what software they use most, Whimsical is always one of the most mentioned products, and the users are fanatical. Whimsical is built for collaborative thinking, combining visual, text, and data canvases into one fluid medium. Distributed teams use Whimsical for workshops, whiteboarding, wire frames, user flows, and even feature specs. And it includes thousands of built-in icons and a rich library of templates. See why product teams at leading companies call Whimsical a game changer. Visit whimsical.com/lenny to have my own templates added to your account when you sign up. That's whimsical.com/lenny. Hey, Ashley, Head of Marketing at Flatfile. How many B2B SaaS companies would you estimate need the import CSV files from their customers?

   3. NANarrator2:17

      At least 40%.

   4. LRLenny Rachitsky2:19

      And how many of them screw that up? And what happens when they do?

   5. NANarrator2:22

      Well, based on our data, about a third of people will consider switching to another company after just one bad experience during onboarding. So if your CSV importer doesn't work right, which is super common considering customer files are chock full of unexpected data and formatting, they'll leave.

   6. LRLenny Rachitsky2:41

      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 her aha moment more quickly and reliably is so incredibly important.

   7. NANarrator2:56

      Totally. It's incredible to see how our customers like Square, Spotify, and Zuora are able to grow their businesses on top of Flatfile. It's because flawless data onboarding acts like a catalyst to get them and their customers where they need to go faster.

   8. LRLenny Rachitsky3:13

      If you'd like to learn more or get started, check out Flatfile at flatfile.com/lenny. (instrumental music) Marty Cagan, welcome to the podcast.

   9. MCMarty Cagan3:26

      Oh, thanks for inviting me, Lenny.

   10. LRLenny Rachitsky3:28

       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, uh, 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.

   11. MCMarty Cagan4:16

       Yeah, sure. I mean, it's, uh, it's frustrating and that's kind of what caused me, occasionally I go through these sort of philosophical waves (laughs) 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 and the rest. There's such strong incentives, like just the profit motive alone. What, why don't more companies want to work like the best? So I, I find that just perplexing. And, and yes, it's true when I, um... And one of the funny things, and I bet you could relate to this, Lenny, I have friends on both sides (laughs) . You know, 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 how... And then when I tell my friends-

   12. LRLenny Rachitsky5:15

       Yeah.

   13. MCMarty Cagan5:15

       ... 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, this is mind-boggling to me. And anyway, I, I, um... 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 want to say old school, because it's not the fact that it's old, it's just the fact that it's obsolete. It's, um, 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 is taking its sprint planning to the engineers and you say, "This is what you need to build next." That is so ingrained. You know, and, and the roadmaps, the quarter, you know, the quarterly roadmaps come and it's so ingrained and they think that the job is, "Yeah, we, 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, 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, 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, that feature teams and real product teams should not use the same string product manager. (laughs) The job is so radically different that it just is, it's misleading to call them both product manager.

2. 7:49 – 16:20

   The qualities that separate the best product teams

   1. MCMarty Cagan7:49

   2. LRLenny Rachitsky7:49

      For folks listening to this and they're like, "Hmm, which one do I work on? I'm not even sure," what are some, uh, maybe like three to five signs that you work at a, a feature factory or feature team as you describe it?

   3. MCMarty Cagan8:00

      Yeah. Well, it's not hard to tell for

   4. NANarrator8:02

      (laughs)

   5. MCMarty Cagan8:02

      ... fortunately. I mean, if you've seen both, it's not hard to tell. Um, in a, 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 have the same thing, that it's a prioritized list of features and projects. So some stakeholders got together, usually quarterly, and they say, "Look, you know, 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 they're 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 this. Those are the ones you want to 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 (laughs) 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, in a real product team, you know, you celebrate when you actually solve the problem, when you accomplish those results. That's why we say product teams are about outcomes, they're not about output. So feature teams and product teams, they, you know, they 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 as 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, um, 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 'em in whatever tool you're using, in Jira or something. And then you need to get it to sprint planning. You need to make sure it comes out. That's herding cats. It's essentially a project management role, but on an empowered product team where you're trying to come up with a, 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. (laughs) Those are hard. That, that, 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.

   6. LRLenny Rachitsky11:45

      You touched on, uh, this idea that people mention this, this way of working sounds like a dreamland to folks that haven't experienced it. And I asked folks on Twitter what questions to ask you and that came up a couple times is people are like, "I read your stuff," and I'm like, "Does this actually exist anywhere? I've never experienced this way of working," just to like make people (laughs) feel like this is possible.One, is there companies that are, like, good examples of this way of working that you like to describe? And then two, just to reaffirm, this is possible, this happens at companies out there. Correct?

   7. MCMarty Cagan12:16

      Oh. I mean, it's funny. So first of all, and I, 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 in Inspired, nothing I've written about in 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, have you heard about this process?" Or, "Have 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 (laughs) . We just try to share it. There's a little bit, I mean, I don't want to... The, the, I'd say the, the, the thing that we do is we try to untangle the company's culture from the technique. Because every cult- 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, 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, um, 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 s- what Slack has 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 of them 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.

   8. LRLenny Rachitsky14:42

      Do you have a sense of what that fraction is? What percentage? (laughs)

   9. MCMarty Cagan14:44

      You know, I, I had this conversation actually... You know Sreyas Doshi too, don't you?

   10. LRLenny Rachitsky14:48

       Uh-huh. Mm-hmm. He was on this podcast.

   11. MCMarty Cagan14:49

       He's one of my favorite thinkers.

   12. LRLenny Rachitsky14:51

       Same.

   13. MCMarty Cagan14:51

       Yeah, he's one of my favorite thinkers in product. He's just terrific. 'Cause he's also one of those people I, I... At first he was asking me, "Do people really work like you write about? You know, are you really... They're, they're that clueless?" (laughs) 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, we, we'll get to that. But anyway, um, uh, you know, I don't know. Uh, 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 that 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 (laughs) products? And then what percentage? My purely anecdotal guess is, uh, maybe 10 to 15% are good product companies, something like that.

   14. LRLenny Rachitsky16:10

       Sweet. I love that there's a number. All right. (laughs)

   15. MCMarty Cagan16:13

       (laughs) Who knows? Who knows? It could be orders of magnitude off.

   16. LRLenny Rachitsky16:17

       Seems, seems reasonable. So a lens that

3. 16:20 – 17:43

   The downfall of innovation in great product teams

   1. LRLenny Rachitsky16:20

      I, I want to use for, uh, part, 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 they interview Steve 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, and thinking about. And I'm excited to kind of chat through this. So first question is just what about this interview has struck you most, um, in- initially broadly?

   2. MCMarty Cagan16:53

      Yeah. Well, I, I... One of the reasons I loved it is, you know, he very rarely talked about product. He talked... He loved to talk about his products (laughs) , right? 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, you know, secret sauce if you will, is he had a very good un- insights to this. And so to find this hour plus interview where he's very thoughtful, very sort of, um... You know, he'd had a chance to kind of think through what went well, what went wrong. And one of the... I, to answer your question (laughs) , you know, in my own writing, and in fact in the recent book, Empowered,

4. 17:43 – 19:23

   The gap between the best and the rest

   1. MCMarty Cagan17:43

      I share my theory for why there's such a big difference between the best and the rest. In other words, why, why isn't every company trying to work like the best companies? I'm... I mean, why not? You're valuable. Look at the valuation they get. For, 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 good looks like.And then, I watched this video, which as you know, sort of be- surfaced, resurfaced recently. And it's, it, he, Steve Jobs shared his theory from 1995, for God's sakes (laughs) . And I l- 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 I, 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, the whole thing. So, don't let my summary discourage you. It's worth watching. But anyway, he shares that he thinks what happens in general as companies get bigger, you know, 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?

5. 19:23 – 27:46

   The pitfalls product teams can fall into

   1. MCMarty Cagan19:24

      And his argument was because as a company gets bigger, product historically became less important. The people in a company that would be h- that would, that would be celebrated were marketing people, salespeople, finance people. These are people that, 'cause at, you know, at, if a company stops innovating, these are the engines for growth, right? Sales, marketing. Or not growth with finance, but cutting costs. And, and his argument was this, this happens over time. Pretty soon, these are your leaders. They're the ones that have been promoted. So then what happens? Good product people don't wanna 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 w- 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's spot on.

   2. LRLenny Rachitsky20:43

      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, taking over your, your culture and, and product and company. And I think there's, like, market share, and then just generally it happens that company's just doing well. Things are going well. We... Let's just keep at it. Let's not break anything. Why launch something risky and, and new, and why not just keep selling this thing that everyone seems to want?

   3. MCMarty Cagan21:13

      And actually, Lenny, I think it's worth highlighting 'cause that is an anti-pattern I see a lot, especially after the founders leave. You know how a lot of times in product we'll talk about there's, there's value creation activities, there's value capture activities. Discovery is all about value creation. Optimization's all about value capture. And bo- 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 'cause they don't know what is essential and what is incidental. They're scared they're gonna, like, hurt the thing that's fueling the business. Now, of course, the founders knew the thing 'cause they were there from the beginning. They have all this institutional knowledge. They know what's important, they know what's not. And, and they have that confidence. Sometimes we talk about the moral authority of the founder. They, they know, and they know deeply w- what is essential and what's not. But when they're gone, very often we see companies that are scared. Uh, I can tell because all they're doing is little low-risk optimizely A/B tests, you know? They're just doing these little A/B tests. They're just tweaking, um, the th- the workflows, the main flows, growth, you know, 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 it... So once they stop doing real discovery, to me, it's just the beginning of the end.

   4. LRLenny Rachitsky22:55

      What's interesting there is if folks at the top are kind of running out of 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 'em, "Oh, let's just build this thing. It's... I, I don't know, but it's probably the best idea, and I probably know more than you do." And they don't.

   5. MCMarty Cagan23:16

      And in fact, that was one of the diseases that Steve Jobs highlighted in that interview. He called it the disease of, uh, 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. And he's like, "You do not... They don't understand. The idea is minor. The idea is just the start." I think he said, you know, 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, you know, 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 prioritized 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'd 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 an idea is just sort of the, the very sparkle in the eyes, just the start. Getting to a product is what matters. And that's work.

   6. LRLenny Rachitsky24:50

      This 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, you don't, and you think you do, and a lot of the magic happens in that process of it- it, building, iterating, learning, talking to customers. Is that, is that how you see it?

   7. MCMarty Cagan25:15

      Absolutely. Um, 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 s- there's discovering the problem to solve that you should focus on and discovering the solution that you're gonna 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, you know, 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, that again, in an ideal world with no constraints, not really a problem. (laughs) But in the real world, the clock is ticking. And if you use say, two weeks of 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, you, if it's not (laughs) 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, I tell them, "Look, be careful. 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 this, that was solution discovery when he was describing the sort of 5,000 things you'd keep in your head. That's dis- solution discovery. So that's important. Product teams need to know that that's where they will either succeed or fail.

   8. LRLenny Rachitsky27:35

      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, the what and not the how. And just to reinforce this point, you're,

6. 27:46 – 35:26

   The role of user research in building a great product

   1. LRLenny Rachitsky27:46

      you're a big fan of no, that's completely wrong. PMs are very responsible for the, the how also.

   2. MCMarty Cagan27:51

      That one always makes me laugh because I was thinking, do you know how, how many hours a week I'd need to work if that was my only job? (laughs)

   3. LRLenny Rachitsky28:00

      (laughs)

   4. MCMarty Cagan28:00

      Just to sp- You know, and probably I'd phone it in 15 minutes a week. "I'm done. I did my part." (laughs) This is ridiculous. And of course it misses... A- 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 gotta be valuable, usable, feasible, viable, but most products fit... Those are the risks. You can call 'em 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. (laughs) That is hard. That takes real work. And that's part of the how. That's a pretty integral part of the how as well. Now, you don't tell the engineers how to code. You don't tell the, uh, designer how to design, but you do have a big part. All of us together are coming out with that har- how. So the how is how it all works and obviously how you monetize, privacy issues, security issues, how it's gonna go to market. These are all how, but they're product responsibilities, product management responsibilities. They're no- they're not more or less important than what the designer or 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 whys." It's so trivial (laughs) and it's, and it's just so uninformed. I just don't know where the origin is for all that stuff.

   5. LRLenny Rachitsky29:45

      Makes me think about... Men always joke that they're like, "Oh, I wanna wear something more interesting to events. Like, I always wear a suit and it's always gotta be a suit, so boring." And other folks are like, "Shut up. It's so..." Like, why would you wanna complicate the life of, of men and having to dress more creatively?

   6. MCMarty Cagan30:01

      (laughs)

   7. LRLenny Rachitsky30:01

      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.

   8. MCMarty Cagan30:12

      No.

   9. LRLenny Rachitsky30:12

      Yeah. Uh, (laughs) anyway, your, your last point also made me think about this recent tweet by, I think it was Patrick Collison or John Collison about how...A lot of people think user research, it's kind of like user research informs exactly what you... Or informs what 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, uh, 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 on user research to answer all your questions. What's your take on, on that perspective?

   10. MCMarty Cagan30:52

       Yeah, I mean, first of all, what they've done with Stripe is so awesome. Uh, and I... That's another great example, and I, I love what they, you know, sort of picked and choose from great companies to create a culture for themselves. So, I'd, um, absolutely agree, but I'd go a little further. Um, 'cause user research is a great topic. I mean, right there. It's a great product topic. I love it. I'm a big fanboy of user research. What 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 s- he's saying that too. He's trying to talk about being, 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, uh, this morning (laughs) that was saying that, yeah, what they do with user research is they, they test their prototypes and as... And, and when they get enough of users saying how much they like it, they build it. And I'm like, "No. That's not why we do user research." And that is not gonna fool any smart leaders. The main reason... And 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. We're, we're 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." Uh, even though Elon Musk has some issues right now-

   11. LRLenny Rachitsky32:48

       Mm-hmm. Mm-hmm.

   12. MCMarty Cagan32:48

       ... he's pretty good at product. (laughs) And so, um, 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- They are 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 'cause the report is too often ignored. And so, to me, the rule is – and I tell this to user researchers at the companies that I coach – if the product manager and the designer are not available to be there during your product, their product's test, cancel the test. They need to be there. This is what makes them useful to their team.

   13. LRLenny Rachitsky33:48

       I 100% agree. I, I have this memory of going to, uh, Paris with a research team, our head of eng, head of design, on our team at least, and I, and the, 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, that it's not just her coming back with tons of insights. And so, uh, 100% find value there. And, um, and engineers especially being involved in that process I find to be super important.

   14. MCMarty Cagan34:17

       (instrumental music) That's when the magic happens.

   15. LRLenny Rachitsky34:20

       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, ride-sharing marketplaces, instant lending, and more. They work with high growth companies like Gusto, Pipe, ClassPass, and Marqeta. Modern Treasury's 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 compliance 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 Combinator. Check them out at moderntreasury.com. I wanna come back to this, uh, idea of feature teams and just what folks... Specifically,

7. 35:26 – 41:04

   What individual contributors can do to shift product culture

   1. LRLenny Rachitsky35:26

      what, what can people do when they're working at a, what you'd 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, a new way of building products broadly?

   2. MCMarty Cagan35:42

      Sure. Well, you know, a lot of companies are intentionally trying to change to, to real product teams. This is w- what most people mean by a transformation, so a lot of 'em 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 try." And I suggest you go to your manager and say, "Look. What do you think about us doing an experiment? For the next quarter or two, 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, uh, it's not that hard to try it on a product team by product team basis. Where it gets expensive and risky, of course, is changing a whole business units. So if it's just a product team, usually they'll let them try. Especially if the, the person making this argument says, "You know, I've learned that the, some of the companies we admire are not working the way we are, and maybe we should try this."

   3. LRLenny Rachitsky36:49

      Just while we're on that topic, what is it they, they try or do? What are some of the things that a team could do? I know you'll, you might have got, you might be getting into this, but I'm curious.

   4. MCMarty Cagan36:56

      That's exactly, though, what I was gonna 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, where, 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, 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 buy now, pay later on our e-commerce site," which is like on a thousand roadmaps right now (laughs) , right? If somebody tells you that, it's not that hard to go to the stakeholder that requested that and say, uh, "You know, we're gonna 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 cart value or whatever. It's just some KPIs that they care about. So you'd say, "All right, you're under, your, your belief is that if we add buy now, pay later, a lot more people will be able to buy and transact and so it's gonna pay off and it'll show here. Do I have that right?" And they'll probably say yes, and they might say, uh, "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, 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, trained to do. But the product manager usually needs to do some work to get themselves to be able to do this. 'Cause a typical... You know, I, I hate the idea of those companies that have separate product owners, 'cause a product owner is just an administrative role. Product owners almost never have the skills to be a product manager. And so, uh, 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 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, 'cause I was a developer before the, and I was building products for developers. I'm like, "Oh, man. 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, um, 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 has that changed 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, uh, 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

8. 41:04 – 44:06

   How PM's can set themselves up for success when trying to change product culture

   1. MCMarty Cagan41:04

      them that if, 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 area 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, uh, do that. So those are the four things you, you bring to the team. Realize the designer doesn't have this info. The pr- the engineers don't have this info. If the team is gonna be an empowered team and they're gonna 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 gonna 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 gonna have to go learn what that is, especially the product strategy. All right. And then finally-The product teams need the skills, uh, discovery skills and techniques. Which to me is the fun part. You know, 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 the, the, you know, read something, learn the techniques. There are good techniques today, better techniques than we've ever had. I mean, 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 know, you need to learn the techniques. That's the tools of the trade for a project manager. So, to your question, you're a feature team, you want to become a, you know, want to give it a shot being a real product team, these are the four things you need to go out and do. Uh, and they, uh, 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.

   2. LRLenny Rachitsky43:39

      Wow. That was, uh, incredibly insightful. I'm curious how a PM could 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, "Um, um, this sucks, doesn't work. We're not gonna do this." Um...

   3. MCMarty Cagan43:58

      That happens.

   4. LRLenny Rachitsky43:59

      You mentioned... (laughs) Yeah. Uh, you mentioned a lot of things people can do, and then you mentioned reading Inspired.

9. 44:06 – 55:33

   How product management is changing

   1. LRLenny Rachitsky44:06

      Is there anything else, just like things that would set people up for success in one of these experiments within their larger company?

   2. MCMarty Cagan44:12

      Well, in particular about-

   3. LRLenny Rachitsky44:14

      Yeah.

   4. MCMarty Cagan44:14

      ... what we're talking about now, uh, Teresa Torres' new book, Continuous Discovery Habits, that's a very good book. It's right on point, talks very much about these skills, and you know, it's, uh, uh, it will basically hold your hand through those first weeks. Another good book is Sprint, you know, Jake Knapp's 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 hand 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.

   5. LRLenny Rachitsky44:54

      Same.

   6. MCMarty Cagan44:54

      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 (laughs) and they were like, "This is what you need to do." I remember when I first learned about the discovery concepts, I was, I was an engineer and then I, I was, I was, I had been promoted to tech lead. And my manager said, "You know, now that you're tech lead, you, you have to care as much about what you build as 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." And 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 call discovery today. I started getting involved. I started going out to customers. I started learning these problems. So, um, 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.

   7. LRLenny Rachitsky45:58

      How do we, how do we make that possible?

   8. MCMarty Cagan46:00

      You know, one thing I, because sometimes I have a tendency to be kind of cynical, (laughs) you know, and it's, uh, 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. Do you notice that? I mean, literally, uh, Sundar at Google has been saying that, uh, the number one thing they look for in their leaders is-

   9. LRLenny Rachitsky46:33

      Mm-hmm.

   10. MCMarty Cagan46:33

       ... a good coach. The number two thing is that they're not a micromanager and they know how to empower their teams.

   11. LRLenny Rachitsky46:40

       Mm-hmm.

   12. MCMarty Cagan46:40

       But at Microsoft, they are looking at, they have three principles for, um, their leaders, their managers that they've been advertising. Number one, coaching. Number two, caring. I forget what number three is. And then, uh, 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 and your career."

   13. LRLenny Rachitsky47:22

       Yeah. I know that you, um, you teach coaches. You, you have con- you have a conference, I think recently where you're coaching coaches. Is that right?

   14. MCMarty Cagan47:29

       Yeah. Not so much a conferences. You know, our problem is, uh, you know, I mean, SVPG were very small. We're, we're just five people and we've been- we're 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, um, do a session in Europe and a session in the US where we invite people that are co- independent coaches. Uh, we don't charge 'em anything. 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 gonna do it in New York in December.

   15. LRLenny Rachitsky48:19

       That'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, you're creating more coaches and helping coaches get better. Along this, that same line a little bit, how do you think the role of product management is, is changing and evolving?

   16. MCMarty Cagan48:34

       Hmm. This is, this is one of those sort of two fork answers. At good companies, it really hasn't changed much at all. (laughs) And I mean, for more than 20 years. It really hasn't changed at 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, um, you know, 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 gonna teach you Scrum, and then you're gonna 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, uh, (laughs) we, we don't, 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. Um, we have other things going on, sort of, you know, there are some very good implementations and definitions of product ops out there, but 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 'cause 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. Anybody 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 in customer success to do that," or, "My job in 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. There's a, you know, 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 haven't innovated for years. That's why they cut that critical thing. And then the third is unencumbered access to the stakeholders, uh, 'cause 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, you know, as long as you're willing to work crazy hours, that can work. But if you're working, you know, 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, you know, they, they think they're, they don't realize the damage they're creating when they do that. And, of course, w- why they do it is no secret. They say, "Oh, that product manager job is too hard for one person, so we're gonna split it in half." And they, you know, it's, they have no idea the damage they're creating, but that's what they're doing. So, uh, 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.

   17. LRLenny Rachitsky53:23

       Awesome. I was exactly gonna ask that, that the PM role is so, uh, full of things to do and such an intense job with so many responsibilities. And so the intention is good, take some things off the PM's plate, specifically product ops I've been seeing grow as you've said. Uh, 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, or is there times when that's actually helpful?

   18. MCMarty Cagan53:48

       Well, this is where if, 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-

   19. LRLenny Rachitsky54:02

       Mm-hmm.

   20. MCMarty Cagan54:02

       ... it's bad. If product ops is there to take my favorite def-, I mean, there's lots of good definitions of product ops too, 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 billed 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. But one of the common definitions is they're like, "Oh, well, we get so much data on how our products are, are being used for our customers, we've created a product ops person that's gonna sort through that data, and they'll tell the product manager what they think they should hear."

   21. LRLenny Rachitsky55:12

       Just to, uh, reinforce this point, what are the three things again? In case folks didn't catch it all.

   22. MCMarty Cagan55:17

       Yeah. Direct access to customers, direct access to the engineers, direct access to the stakeholders.

   23. LRLenny Rachitsky55:25

       Awesome. Um, maybe a last question is, are there other trends that you're worried about in product management of where the role of PM is going?

10. 55:33 – 59:49

    The pitfalls Marty warns to watch out for in product management

    1. LRLenny Rachitsky55:33

    2. MCMarty Cagan55:33

       Well, I am very worried about the, 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. So, you know, the truth is, and I know where this comes from, I understand it, but you know, scaling is hard. Does any- Do you know anybody who doesn't think it's hard? (laughs)

    3. LRLenny Rachitsky56:05

       I do not. (laughs)

    4. MCMarty Cagan56:05

       You know? 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 S- 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 w- 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, you know, people are fooled. It's just marketing. So they call themselves Agile, but it's nothing to do with Agile. This is 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. And all the best leaders I know, whether we're talking Bezos or whether we're talking Elon Musk or, you know, anybody ... Steve, Steve Jobs was saying it in the video, "Be careful of the disease of process people. They will destroy your company."

    5. LRLenny Rachitsky57:39

       What an incredible way to wrap up. Um, where ... Just two last questions. Where can folks find you online if they wanna reach out, learn more, and how can listeners be useful to you?

    6. MCMarty Cagan57:50

       Well, I mean, all of, all of our stuff we publish for free at svpg.com, Silicon Valley Product Group .com. You can also find me, uh, reluctantly on social media, but, um, I do the minimum possible.

    7. LRLenny Rachitsky58:03

       (laughs)

    8. MCMarty Cagan58:03

       The signal to noise ratio on social media is so terrible, I try to focus on other places. But, um, uh, that's where you can find me for sure. And, um, yeah, I mean, I'm, I'm ... I mean, at this point in my career, I'm just having fun. I'm not looking for, uh, I, I'm not looking for anything from anybody. I hope, uh ... 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 ques- same question enough, I realize maybe I should write about it. And I love that especially, and if it's something I need to go learn more about, and I ... I do have, at this point in my career, a great Rolodex of people, uh, that I can go to and say, you know, "Hey, Lenny, what do you think about this?" Or Sreyash or Theresa, all these people I know that are very smart and I can go to them and say, "What do you think about this?" And, uh, and I sort of put everything together and I, I write about it. So yeah, if you've, if you really have tried and can't find a good answer to a hard question, feel free to email me.

    9. LRLenny Rachitsky59:12

       Amazing. Send your hard questions to Marty. (laughs) Marty, thank you so much for doing this. Uh, this is everything I hoped it would be. I'm really thankful that you joined me, and thank you for being here.

    10. MCMarty Cagan59:23

        Well, thanks again for inviting me, Lenny, and good luck to everybody out there. (instrumental music)

    11. LRLenny Rachitsky59:28

        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 leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.

Episode duration: 59:49