Lenny's Podcast: Product | Career | Growth - Shreyas Doshi on pre-mortems, the LNO framework, the three levels of product work, why most execution problems are strategy problems, and ROI vs. opportunity cost thinking

Episode Date: June 7, 2022

Shreyas Doshi is a treasure trove of knowledge and tactical insights on product, strategy, psychology, leadership, and life. Over the course of his career, he’s PM’d at Google, Twitter, Yahoo, and Stripe, where he joined as its fourth product manager, later becoming Stripe’s first PM manager and helping define and grow its product management function (from ~5 to more than 50 people). Since leaving Stripe, Shreyas has amassed a huge Twitter following in large part thanks to consistent sharing of high-quality insights on the art of product management.—Find the full transcript here: https://www.podpage.com/lennys-podcast/shreyas-doshi-on-pre-mortems-the-lno-framework-the-three-levels-of-product-work-why-most-executio/#transcript—In this episode, we’ll explore five big ideas from Shreyas Doshi:1) How to predict and prevent problems with pre-mortems* How did pre-mortem meetings impact the culture at Stripe?* What are the best practices in running a pre-mortem meeting?2) How to prioritize your time with the LNO framework* What is the LNO framework? How did it change the way Shreyas went about his day?* What is the two-step tactic you can apply to overcome procrastination on important tasks? 3) The three levels of product work* What are the three levels of product work? Which level should you optimize for?* How might these product work levels cause conflict or influence your company culture?4) Most execution problems are not really execution problems * What are the common types of problems hiding behind the execution label? * What are the two traits you need to identify a fake execution problem?5) Why ROI thinking is detrimental to product planning* What is the pitfall of ROI thinking?* What is opportunity-cost thinking and how can you apply it?—References:* Coda template: https://coda.io/@shreyas/pre-mortems-how-a-stripe-product-manager-predicts-prevents-probl* Pre-mortems: https://twitter.com/shreyas/status/1221257568510603264* LNO framework: https://twitter.com/shreyas/status/1492345184171945984* Three levels of product work: https://twitter.com/shreyas/status/1370248637842812936* Execution problems: https://twitter.com/shreyas/status/1427116991274307588* Opportunity-cost thinking: https://twitter.com/shreyas/status/1409726218438549514* High agency: https://twitter.com/shreyas/status/1276956836856393728—Where to find Shreyas:* Twitter: https://twitter.com/shreyas* LinkedIn: https://www.linkedin.com/in/shreyasdoshi/—Our amazing sponsors:* Coda: https://coda.io/lenny* Productboard: https://www.productboard.com/* Sprig: https://sprig.com/lenny This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.lennysnewsletter.com/subscribe

There's no one out there today who shares more wisdom, more consistently, on the art of product management than Shreas Doshi. Shreos kind of came out of nowhere a few years ago, and started tweeting gems of insight about building product and the role of product management, and rightfully so has built a huge following on Twitter. What I love about Shreos is that his insights are often framed in really memorable and interesting ways, and they're often contrarian and not ideas that you've heard elsewhere. Shraeus has worked at some of today's most important tech companies, including Yahoo, Twitter, Google, and most recently Stripe, both as an IC and a manager, and his advice is always

rooted in his real-life experiences at these companies. In our chat, we focus on five topics and go deep on them. We talk about the power of premortems, we talk about how to best use your time as a product manager. We look into the three levels of product work and how getting them wrong often leads to tension on your team. We dig into why most execution problems are really strategy problems, and we talk about a common pitfall in prioritization. And if you listen to the end, we actually throw in a bonus topic. I really appreciate that Traos made the time for our chat, and I cannot wait for you to hear it. This episode is brought to you by Coda. Coda is an all-in-one doc.

that combines the best with documents, spreadsheets, and apps in one place. I actually use Cota every single day. It's my home base for organizing my newsletter writing. It's where I plan my content calendar, capture my research, and write the first drafts of each and every post. It's also where I curate my private knowledge repository for paid newsletter subscribers, and it's also how I manage the workflow for this very podcast. Over the years, I've seen Cota evolve from being a tool that makes teams more productive

to one that also helps bring the best practices across the tech industry. to life with an incredibly rich collection of templates and guides in the Cota Doc Gallery, including resources for many guests on this podcast, including Shreos, Go Cool, and Shashir, the CEO of Kota. Some of the best teams out there, like Pinterest, Spotify, Square, and Uber, use Kota to run effectively, and have published their templates for anyone to use. If you're ping-ponging between lots of documents and spreadsheets, make your life better and start using Kota. You can take advantage of a special limited time offer just for startups, head over to coda.io-slash-lennie to sign up and get a thousand dollar credit on your first statement. That's c-o-da-d-a-dot-I-O-slash-Lenny to sign up and get

$1,000 in credit on your account. This episode is brought to you by Product Board. Product Board. Product Leaders trust Product Board to help their teams build products that matter. From startups to industry titans, over 6,000 companies rely on product board to get the right products to market faster, including companies like Zoom, Volkswagen, UiPath, and Vanguard. Product Board can help you create a scalable, transparent, and standardized process so your PMs understand what their customers really need and then prioritize the right features to build next. Stakeholders feel the left, too, with an easy-to-view roadmap that automatically updates so everyone

knows what you're building and why. Make data-driven product decisions that result in higher revenue and user adoption and empower your product teams to create delightful customer experiences. Visit product4.com to learn more. Traos, the man, the myth, the legend. Thank you so much for joining me and for having this conversation. It's great to be here, Lenny. So we strategized about how to make this podcast as concretely useful and actionable for as many people as possible. And so we decided to do as instead of a regular interview where we talk about a lot of stuff, instead we're going to go deep on five of your ideas, teachings, lessons that you've shared on Twitter that have stuck with me

and I know have resonated with a lot of other people. And we're going to call it the five big ideas from Shreos Doshi. Does that sound about right? Sounds great. Okay, cool. So before we get into that, before we get into the meat of all this stuff, you share a lot of wisdom on Twitter, but you don't share a ton of about yourself and your background where you grew up, where you're born, things like that. So I'd love to learn a little bit more about the human that is Shreos. And so maybe we start there. Like, where are we born? Where'd you grow up? What did your parents do for work? What did you want to be when you grew up?

So I was born in Mumbai, India, and I lived there for the first 21 years of my life. I actually did not really even get to see many parts of India while I grew up in India and basically just was in Mumbai the whole time. And then I moved here to the United States for graduate studies at age 21. My parents, my father was a businessman. And so he started his own business.

He manufactured spices and marketed them. So growing up, I saw him work on packaging and pricing. And when he was short on staff, I used to be packaging the spices into the little box or creating some marketing material for him, not the creative part, but the grant work. So I kind of grew up in that environment where the lines between what was my dad's business and our personal lives were very blurred. My mother, just growing up, was a homemaker, and so my dad was largely kind of just busy and all consumed in his business. And I ended up spending a lot of time growing up with my mother.

And so both of them have had a pretty significant influence in different ways, but both significant influence on who I am. When I grew up, I changed that a lot. I think when I was very young, one of my uncle is a doctor. So I kind of saw him and I was like, oh, maybe I should be a doctor. And at some point later, I changed that. In high school, I took French. And I ended up being really good at it, like surprisingly good at it. And I was very passionate about it. So for a while, I was thinking, oh, maybe I'll be like, maybe teach French after graduate from college. Maybe I'll go to France, learn the language a little more. And maybe I'll teach French. That lasted for a few years.

And it turned out that I ended up not pursuing that. And instead, got a degree in computer engineering. Partly, I think, because if you were in India back then, if you were good at science and mathematics, you would usually take up engineering. And so that's what I ended up doing. I was also quite passionate about computers, so maybe that was part of it.

But once I started on that path, it became much clearer what I wanted to do. How's your French these days? Very bad. Sad to say, my son is now taking French, and I am just embarrassed at my inability to assist him in any way other than to point out some conjugation errors. So you said you studied computer engineering.

That's kind of what you moved to the US for. How did you move from that to product? Oh, yeah. So I started my career as an engineer. Orwell, backtracking. So I completed my undergrad in India. I came here to the United States to pursue a PhD in computer science. About one month in, I realized that PhD in academia wasn't for me.

So I decided that I was going to drop out of the PhD program. And once I dropped out, this was like 2001, 2002. So the climate was very different. There were basically no jobs for tech people. Certainly there were no jobs for people who required a visa, which I did. So it was very difficult. But I ended up working as an engineer at a couple of startups. And that started my career in tech.

I was an engineer for about four or five years. And when I moved here to the San Francisco Bay Area, I got a little taste of product management. So I was part of this team that used to be LoudCloud, and they were acquired by a larger company, EDS, at the time. So it was a startup team within a larger organization. And I was an engineer there, and I just started doing some product work. And I found that my managers over the time would kind of send me to customer meetings.

We had an internal product. So these were internal customers. And I thought it was a little surprising because I was fairly junior and I was an engineer. But I was like, okay, I'll just. go to the customer meetings. And I really enjoyed that. I really enjoyed understanding what our customers were trying to do, kind of helping them out. I also enjoyed thinking about creative ways to solve their needs and whatnot. So that was my taste of product management. I was in for a year, for about a year, I was kind of doing the product job without having the title. And I was also the engineer. So I was in

this great state where I'd figure out what needed to be built. And I would just build it myself. So that's how I started. And at some point, during that one year, I realized that while I was a good engineer. I was perhaps a top 20% engineer. I realized that I would never be a great engineer, that I would never be a top 10% engineer, because I saw those engineers at the fortune of working with them, and I just could tell that I couldn't be that. And I increasingly got interested in this product thing. So I said, okay, let's try out this product thing. And so that's really what started my product career. And I think what I have to be really thankful and grateful for there is the people who gave me a chance to do the product work. And there were many people involved. And so I think without

their support, it would have been much harder for me to become a product manager. I didn't know that you moved from engineering to product. And your journey is very similar to mine where I was also an engineer. And I, once I got to Airbnb, I was like, okay, I am not good. And I will not last as an engineer at a company like this. And I should think about what other options exist. And it worked out. great. And so that's, I wonder how often that happens of PM's moving into PM because they aren't going to make it as an engineer. Yeah, I think it might be a common occurrence because engineering is a really great job. And like, particularly on Empower teams as an engineer, you can do a lot. You don't have to just like, quote, write code, but you can do a lot. And so I also think it's a great place for people to

start their career if they have a technical background and if they enjoy the part about building software, because sometimes people will ask me like, hey, I'm doing this technical degree, whether it's computer science or something else, but I want my first job to be product management. And I often respond with try out engineering, because again, in many companies, fortunately these days, you can do a lot more than just, you know, the core engineering job. And so you get exposure to many different things. And once you do that, you can decide what path to pick. It's such a bonus to have that background as a PM. I wanted to go back to some of you mentioned that you worked at LoudCloud. I had no idea. That was Mark Andresen's second company, right?

Yes, I joined that team. I was interviewing with them for, again, this was the time when, like, there were very scared jobs in the valley. And I was interviewing with them for nine months or something like that. And they had just been acquired by EDS. So they split into two companies. One got acquired by EDS, and the other became Opsware, which was the product company. And so I joined the Loud Cloud part of that organization. Got it. Is there something, that you took away from that company. Was Mark Andreessen still working there? And I think Ben Horowitz also.

Yeah, they were still there. They were working on the Opsware side. It turned out, again, because even though I was hired as an engineer, the first task I was given, the non-engineer task I was given, was to manage a relationship with Opsware, because the way that split worked is EDS would use Opswheres data center automation technology. And my team was responsible for deploying and supporting that technology for EDS. And so I was given this role of managing the vendor relationship.

And I have no idea. I'm in my early 20s. I have no idea how to manage vendor relationships. But I ended up doing that. And as part of that, I got an opportunity to work with many folks over at Opsware, including folks on the leadership team there. And that was my first experience of what a really highly talented and energetic team looks like. Both on the Opsware side, like I said, I worked with a number of people there,

but also on the sort of former. or Lautlout side, who were my team members. And that magic, a very high caliber team, people who are really great at their job and brought high degree of energy and collaboration to their work, I was just lucky to have been part of that team early on. And then following that, you worked at a bunch of really important, well-run, successful companies, Stripe, Twitter, Google, Yahoo. What's one thing you took away from each of these companies that you've worked at, that is kind of stuck with you? And you share a lot of this on Twitter, but if you just think about Like somebody took away from each of these companies or even the founders that ran these companies.

What might those be? Yeah, let's do this rapid fire style because, you know, me, I could like spend an hour just talking about this topic. But just starting with Yahoo, I think I learned the importance of building multiple services under a single account. I think that was, you know, the one Yahoo ID was such a powerful thing. It wasn't easy to pull off back in the day. And Yahoo was perhaps the first company that kind of like,

pulled it off really well. And so that idea of bundling under a single account, which then Google really did extremely well later on, was something that I got to experience very firsthand because I was working on the identity team at Yahoo. Google taught me the power. Real quick on Yahoo. Because it makes me think about it. I remember they tried to do that with Flickr and they had a bunch of trouble with that, right? People on Flickr didn't want to log in with Yahoo. Is that right? Yes, that's the story of every acquisition. There are some raving fans of the service. that are perhaps not entirely happy about their beloved service being acquired by a large company. So, in fact, we encountered this at Google as well.

If you remember, YouTube accounts used to be separate from Google accounts or Gmail accounts. And at some point, Google decided that you should be able to use your Google account to log into YouTube. And also over time, that, like, everybody who uses YouTube should have a Google account. So they went through a multi-year migration of accounts, Google, and they had similar backlash. The interesting part, though, is nobody remembers that now, right? Like, people happily use YouTube. So this is one of those things where sometimes it's painful in the short term, even though it might actually be the right answer over the long term.

Great advice. Okay, sorry, cut you off. Google. Yes, Google, I think the main thing I learned was the power of thinking really big. and I know it sounds very, sounds like a platitude, but like really big. And I only actually realized that when I left Google and I started working with other teams and these were all capable teams. And I was struck by how many teams kind of just limited the potential of what they could

achieve. And I think Google helped people sort of think big by default. And so I think my, the six years I spent at Google really kind of help me understand that really well. and just make it a normal part of how I operated. So that was really useful for me. Is there an example at Google that something you worked on that was like, holy shit, this was going to be big.

Or let's think bigger about this. Yeah, well, as with anything, right? Like there's pluses and minuses. So I worked on the ads team at Google for a number of years. And there was this kind of unwritten kind of rule of thumb that, hey, if it's not going to generate more than $100 million in revenue, it's not what talking about it. Right?

because the ads business was growing so fast and was so large that we would regularly not pursue opportunities that were just, quote, $100 million. And so why do that? That's because Google had access to billion dollar opportunities for its ads business. So they were very clear on pursuing the big opportunities. And in some cases, these opportunities were not obvious. So we kind of had to create those opportunities. If you think about some of the innovations Google brought over the years in monetization,

including things like video ads and whatnot, right? Like those were not obvious opportunities, but Google decided that it wanted to pursue those big opportunities. And in order to do that, it had to sometimes just let go of these seemingly smaller opportunities. So that tendency to kind of think about, well, yes, there is a $10 million business here, but like, can we make it a $100 million business? Or there is a $1 million business here. Can we make it a $10 million business?

What does it take to make it bigger is a habit, I think, that got kind of ingrained for me at Google. Now, of course, there's the other side of it, which is, I think Google missed out on some trends simply because of this filter or this high bar, where sometimes it's not clear if something is a $100 million opportunity or a billion dollar opportunity. And so that is a downside of this. What I mainly took away is, for instance, even at Stripe when I joined, I was just a thinking a lot bigger about the business I was responsible for Stripe Connect. And that helped us make different decisions about what to prioritize and at what pace to go after it. So that was Google.

Moving on to Twitter, I think at Twitter, the main thing that struck me with all the challenges they had infrastructure challenges and also some challenges around leadership and culture is just the stickiness that comes with combining network effects with core product differentiation. right? So because Twitter had both. Like we talk about network effects all the time and I don't have much more interesting things to add beyond what's already added. But this combination of core product differentiation, because if you think about it, there's still no product like Twitter, right? Despite it now being a long time since the product was launched. And that core product differentiation combined with network effects has what enabled Twitter to kind of have the staying power it's had. And I think unless something terrible happens, I think Twitter will be around for a really long. long time. So that's something I got to observe very closely when I worked at Twitter. And then at Stripe, I think the main thing I took away was that when you combine high energy, sound judgment, low ego, and small teams, you just get magic. And so I just, Stripe wasn't by any means flawless, but I saw that combination of high energy, sound judgment, low ego, and small teams more at

stripe than any other place I've been at. And so that was very impactful in kind of my growth and thinking as a leader. And I can go on with the founders because I know you had asked that question. Let's do it. Let's do it. Okay. With regards to the founders and what I learned from the founders, Yahoo, I didn't work much with the founders. At Google, I had some interactions. I was in meetings with Larry, Sergey, Eric Schmidt. And I think I particularly, if I were to pick one thing, I really appreciated Larry's strategic insight, and particularly his ability to simulate the future to make better decisions. And so Twitter, I just overlap very briefly with Jack's comeback as CEO back when he came back.

And I think I was struck by his ability to listen and ask great questions in a few meetings that I was with him. And so I was really impressed by like he would just listen a lot more than you would expect, say, the CEO to listen. and then he would just ask one vital question. And that's something I've tried to use in my leadership style ever since I saw that. Is there an example of a story of that happening that you think about? Yeah, I think forget the details and they're not that important anyway, but there was a time when we were discussing a potential acquisition. And I was on the fence on that acquisition.

It would be something that my team would acquire. Jack was in the room. And I remember we went through, as is common in many calls. corporate settings. We went through all the pros and cons and all the intellectual arguments and the strategic arguments and the metrics arguments and all of that. And Jack was just listening through all of that. And then I remember very distinctly, he asked me one question, which was something to the effect of how does this make our users love Twitter more? Right? Like a simple question. But then at that point, I realized, yeah, we never really talked about that. Because we

were so engrossed in all the other stuff, right? And we talked about it as a proxy, because we were talking about metrics and impact and integration and those sorts of things. So I still remember that. I still remember him asking a simple question. And frankly, at the time, I did not have a good answer to that question. So that was a lesson for me to get more rigorous about my own thinking. That's a question that a lot of PMs would hear and be like, oh my God, I can't. Come on, man. We're trying to move some metrics here. But I love that you took that as like, okay, really find this really important and this is a really important question to think about and as a lesson of how to approach this kind of stuff. So I love that. And oh yeah, I think you were

going to talk about Stripe too, right? Yes, Stripe. I worked a lot with Patrick and John. John was my manager for a while and from John, I learned a lot about marketing. John is a master marketer, among many other things that he's absolutely great at. He's just a great marketer. and I just learned a lot about how to think about talking about the product in terms that, you know, again, obvious stuff, but talking about product in terms that customers really understand. And then sometimes emphasizing things that we as product people might not think are really important. And because maybe we didn't spend much time on building it. And we want to talk about things that we spent a lot of time that are sort of truly innovative,

et cetera, et cetera. And John would often make these, again, these kind of observations about, well, if we just talked about the product in this manner, that will likely resonate a lot more with customers. And that got me thinking a lot about how I need to kind of reframe my approach to basically separate the effort involved in kind of building something with the effort you want to put behind talking about said thing. And that doesn't have to be the same features that you talk about.

So that's something I learned a lot working with John. From Patrick, I think the main thing I learned was just how to think and kind of. communicate more clearly. Patrick did that extremely well. And then overall, from both, I sort of learned the importance of setting the culture you want simply by consistently being an example of the behaviors you want to replicate in the organization. So instead of kind of talking about values, I saw both of them just kind of live the values that they wanted the company to replicate, especially as the company was scaling. And so whether it's a culture of being, user-centric or it's a value around humility. They just lived those values so consistently.

And I think that consistency spoke louder than anything that you might write on a poster on the office walls. It's just hearing you describe all these companies and all these founders that you've worked with. It's pretty incredible the set of experiences that you've had and kind of like the primordial soup in which you became a PM. And it explains a lot about how you're able to squeeze so much wisdom and insights about the role of product management and the art and skill of product management because you've seen so many ways of doing it and so many companies that have kind of done in different ways. And so it's a good segue way to kind of shifting to talk about the five big ideas. The first is around this concept of premortems. There's something that stuck

with me when you tweeted it. I think it was a couple years ago at this point. And I see it come up occasionally in your tweets and amongst people chatting your super follower threads. And so I also like that there's something you can actually implement and act on pretty quickly and see impact. And so I'm curious to kind of hear your thoughts on this idea of premortems, just unpack this idea for folks. Yeah, we're all familiar with a post-mortem, or as they call it in the military, I think, after-action reviews. Right. So every company I've worked at, we've had some form of post-mortem when a launch had problems or an initiative did not go as planned. Or we suffered an unacceptable system downtime.

Somebody would say, oh, we need to post-mortem that. And over the years, I really saw the effectiveness of a post-mortem. Some really great insights came out of a post-mortem about what went wrong and what we could have done better. And as I saw the effectiveness of a post-mortem, that's what made me wonder, why do we need to wait until after things go wrong? Because like, why can't we extract some of these insights before they go wrong? So it was around that time that I discovered the idea of a premortem. I learned about it from in Howard Business Review article written by Gary Klein. And the idea is simple, which is when you are working,

on an important project or initiative, you get together with your team early on in the products or the project's life to see in advance what could go wrong. And the way I describe a premortem is that if you do a premortem right, you will not have to do an ugly postmortem. You might still do a postmortem to learn, but odds are very high that it is not going to be a bad postmortem. And the genius of the premortem ritual is the initial prompt. So it's not just about like, well, what could go wrong, right? Like the initial prompt is the genius, which is the prompt starts with imagine this project that we are working on has failed six months from now or this launch we are doing has miserably failed. Let's just all imagine that. Now, let's work backwards from there

and ask ourselves what went wrong? What could have contributed to this utter failure? And that's how a premortem meeting will start. The leader will start. The leader will start. with this prompt. And then the way the meeting goes is you ask your team members to share what could have caused this utter failure. And the magic of this type of approach where you kind of like work backwards from a failed outcome, a hypothetical failed outcome, is that it just somehow enables two things. One is much greater psychological safety for team members to talk about things they are concerned about, but that they were just hesitant to bring up because nobody likes to be negative in modern organizations, right? Everybody wants to be optimistic and

positive. So a premortem setting gives everybody the license to actually think about what can go wrong. So that psychological safety is a big, big factor in why a premortem works. And what I've found is, and at Stripe, I did this regularly with launches that my team was involved in. Sometimes, you know, some teams or some people were like just surprised or skeptical. Like, is it really going to work. And then we go through the premortem meeting and there's a whole process that we can talk about. But like as we complete the meeting, I ask everybody, so how did that go? And just everybody's smiling. Even though we've spent, say, you know, 30 minutes or an hour, just talking about terrible scenarios of things that could go wrong. But everybody's feeling a little lighter, right, because it's great

catharsis for them. So that becomes really important. And the last kind of thing I found with premortems, now that I've done them with, you know, various other companies as well, that I advise and whatnot is the shared vocabulary. And the shared vocabulary that you get about being able to talk about things that will fail. So I have a specific approach, which is I ask the team to talk about three things. Each member on the team should bring up three things. One is a tiger. So you can bring up tigers in the shared dock that we create. And a tiger is a threat that will actually kill us, just like a tiger would. So these are like actual problematic things that could be really harmful to the product or the project. So that's a tiger. The other. The other,

is paper tiger. So this is a seeming threat that others might be worried about, but you're not worried about. So that's the paper tiger. And then the last one, and I think this one was also used at Airbnb in other ways, is elephant. And the elephant is the elephant in the room that nobody's talking about. So it might not be a tiger. It won't kill us. But you're still worried that we are not kind of like seeing reality as it is. And so an elephant could be like, well, we are assuming that just because we launch this and do a bunch of PR that we'll get users, but are we sure we're going to at users, right? Like, that's kind of like the elephant in the room that nobody's talking about, that, like, again, this gives you that psychological safety to bring it up. And then what I noticed

as I ran premortems is that in future meetings that the team had, where I wasn't even present, people started talking about, oh, I have this tiger, can I bring up this tiger? And all of a sudden, it became okay for people to bring those things up, which I think is perhaps the best part about a premortem is that shared vocabulary. Such a simple idea that is clearly going to benefit you in your team. And so, and it's interesting that people don't don't often do this or haven't even thought about doing this. And so just to get a little bit deeper, how do you actually execute this meeting? Who do you invite?

What are the questions you ask? When exactly do you do this, that kind of stuff? Yeah. And so as I started doing premortems, they got more and more popular at Stripe. Other teams started doing them. And then afterwards, I, you know, helped some startups kind of also do premortems. And at some point, I decided I should just, like, write down my template for premortems. So I worked with the folks at Koda to create a Koda.

which you can find and we can put in the show notes if possible. Basically, that's an entire kind of template for how to run premortems using this method that I talked about, including tigers, paper tigers, elephants, all of that. The main thing about a premortem is to include people from every function that is going to be involved in, say, if you're doing a launch. And so if it's a really large launch, sometimes I will separate it into two groups. One is everything related to kind of like the engineering side of things where you can kind of bring in, usually the engineering team is fairly large.

So you can bring in every engineer. So that's really important. Every engineer needs to be in the meeting. And so it might be a meeting of 10, 15, 20, whatever engineers and maybe a PM, maybe a design counterpart and so on. That's just focused on the product engineering side of things, like what could go wrong. And then again, for a large launch, I like doing a separate premortem for the goal. to market side. And so that will involve sales, team, support team, marketing team,

involved design team. Some of the core engineering leads will also need to be at that meeting. Over there, we'll talk about more of the go-to-market risks. So that's what I like to do for a very large launch. For a smaller launch, I just like to do one meeting where everybody is present. And like I said, start with the prompt of imagine this has failed. So as the premortem meeting leader, it's my responsibility to share the prompt. And then, I like doing these premortems where we alternate between speaking and quiet time. So I'll share the prompt and then I'll say, okay, now the next five minutes or the next 10 minutes is quiet time where I already have that template like the Coda doc, where people start

entering their own kind of tigers and paper tigers and elephants in a way that nobody else sees. And so people do that and then we go around the room and kind of share. And the one other innovation I added as I did this often was I also, after people shared, I asked people to pick the tiger that they find more scary, but then somebody else mentioned. So not their own tiger, but some other tiger that somebody else mentioned that they found more scary. So that ends up being sort of, you know, people basically are voting. And then as the premortem leader, it's my responsibility to take all of that, like,

output that the team has generated in this document and then prioritize. Because again, the point is not to solve every problem, right? The point is to identify threats that we are not talking about openly or that we might just be missing. Or we might be assuming that somebody else is going to deal with it, only to find nobody was thinking about it. So then I like to create a post-premortem action plan and then share that with the team and kind of keep myself as the leader accountable for actually making progress on it. Having started doing this, have you noticed less need for post-mortems? Basically, projects failing less and having less problems. Like, what kind of impact have you seen executing on this idea?

Absolutely. I've seen us identify certain issues that just wouldn't have come up and likely, you know, you can't really run a simulation and see what the counterfactual look like in real life, but those likely would have resulted in a problematic situation afterwards. Like, you know, a great example is sometimes you'll see a company announce something and they have massive backlash. And then one reasonable observer might say, well, how did this company miss this? Right. Because what happens? is they have the backlash, then the company realizes, oh, we have this backlash, then they start doing damage control. They sometimes might even backtrack and undo whatever they did. They'll say, sorry, we didn't think about these issues, like give us some more time and we'll kind of come back and we'll perhaps relaunch the feature, but in a better way, right? To the casual observer, like, it may seem like that it should have been obvious. And sometimes it's not. But oftentimes, I agree it should be obvious to these teams what issues these things are going to cause. In fact,

It is obvious to team members, some team members, but the problem is that they perhaps haven't created that psychological safety and that vocabulary to be able to talk about it in an objective way and to decide with intent, are we going to solve for this or not? So I do see a lot of those scenarios in our industry, which end up just actually wasting a lot of time, whereas premortem is like a very sort of inexpensive way to see these things because all it is is one meeting followed by some work that the leader needs to do to prioritize, followed by some mitigating actions, which you would have had to take anyway. So that's why I'm a huge fan of premortems is one of those very low downside, but very high upside things that

have experienced. I'm excited to see this template. I haven't seen yet. I don't know that you put one together. So that's awesome. And yeah, we'll link it in the notes of this episode. I want to move to our second big idea, which is about something you've called the LNO framework, which is all around prioritizing your finite time as a PM and as a team. And so I'll just kind of try. turn that up to you to share what that's all about. Yes, and so I'm going to share a short kind of personal anecdote related to the LNO framework, which is that when I just joined Google as a relatively new PM, this is back in 2008. For the first three years, I was overwhelmed and stressed.

And that was because, one, I was a new PM in this, like, really high performance environment. I was working on some important products and launches. And I just had too much to do. And I looked back at that time and it was perhaps the most stressful time of my career where I would long hours, et cetera, but even at the end of the day, I'd feel highly dissatisfied because my to do list was endless. And I wasn't able to make a dent on it. And I was also a little bit of a perfectionist. So I was like, no, no, no, I need to do this well. And yeah, I was just constantly, I would come home and talk to my wife and kind of basically just complain to her about how I'm not able to.

to make progress or as much progress as I want when that was accompanied with like, you know, not being able to sleep very well because I was concerned about how much output I was producing and whatnot. And so again, very stressful time in my career. And then things changed when I discovered the ideas related to this LNO framework in a blog post. Unfortunately, I can't even find that blog post somewhere. But it had some ideas that I took and then kind of created this LNO framework on myself, which is essentially that, like, as a product manager or as anybody in a creative, high impact, high leverage role, all your tasks are not created equal. There are actually three type of tasks that you end up doing in such a role. So there are L tasks, which are leverage

tasks. And the L tasks are such that when you put in a certain amount of effort, you get 10x or 100x in return in terms of impact. So those are L tasks, leverage. tasks. Then there are neutral tasks. So that's N. And those are tasks where you basically get what you put in or just a little more than that. So you put in 1x and you get 1.1x. Those are neutral tasks. And then there are overhead tasks where you get back in again in terms of impact. You get back a lot less than you actually put in. And it turns out that many people, many people who are ambitious or are perfectionists like myself, by default, treat each of these types of tasks. the same way. And therein lies the problem. So this was the epiphany for me back at Google when I

kind of discovered some of these ideas. And what I realized is that among the things in my to-do list, there are actually only very few L-tasks. And so it made sense for me to focus a lot on those L-tasks, to take on those L-t tasks when I was feeling most productive, most energetic during a certain time of the day. And for the L tasks, let my inner perfectionist shine. Because I'm going to get so much more in return, right, it makes sense for me to spend that time on that PRD, for instance, related to an important feature that will meaningfully impact our revenue, right? I'm going to spend more time on that than I ordinarily would. So now where does that more time come from? Because it cannot come from just working more hours. Well, it comes from spending less time on end tasks and

O tasks. And so there are some tasks that you do. Classic example of an O task is say an expense report, right? Like, sounds silly, but I used to try to make my expense reports really good. Wow. And sometimes like that made no sense, right? Like, no, no, I need to do that. And again, this is the silliest example. But there are many examples and something I realized is that the same type of activity can actually be either an L task or an N task or an O task. So what's an example? So say like a classic PM task activity of filing a bug report, right? And so many companies have these bug templates, etc., etc., right, like that you use to file a bug report.

Well, it turns out that filing a bug report, depending on the situation, depending on what type of bug it is, can actually be an L task, high leverage task. And over there, you want to file a very detailed, explicit bug report. And in other cases, might actually be an O task where you don't fill up. the template that diligently. And you don't add 15 screenshots with annotations, right? Instead, you just have one screenshot and you hit submit on the bug report. So that shift, usually for the same type of activity, we provide the same type of engagement. The last example I'll use to illustrate this is taking notes. It turns out even taking notes, taking notes synthesizing

them and then sharing them can actually be an L-task, an N-task, or an O-task, depending on what type of notes they are. So if it's like, you know, after I understood this, previously, I would just send all notes like I tried to make them really good, which took a lot of time. But then I realized, well, this is a meeting where, yes, I need to send notes. But again, it's like, it's just standard stuff. I just need to like quickly list out. People need to really know is the three action items that came out of the meetings. Who owns them? That's it. And it is not about something highly strategic or controversial. Well, in that case, I'm just going to send the notes out the moment the meeting is over. I'm just going to hit send because I've already taken the action item, right? I'm not going to try

to make my notes look great so that others can appreciate, oh, Shreya's always sends great notes. On the other hand, if it was a product review with the CEO about a very contentious topic that you have gone back and forth multiple times, and now you made a decision about something, you want to perfect those notes before you send them out, right? Like, you want to get the language right, you want to be very clear on what the decision is, so there's no room for misinterpretation, so you don't backtrack afterwards or people say, well, but I thought we said this. So that's in a case where it's an L task. And yeah, I would say just spend an hour or even two hours perfecting those notes because it's an L task. So hopefully that helps illustrate some of the ideas behind

the LNO framework. Yeah, and that's the last piece is a really good segue to the next big idea around optics and the important of optics. This episode is brought to you by Sprigg. If you've been a member of my community for a while. You know I'm a user, fan, and investor in Sprig. Sprig is a user research platform that makes getting user insights from your product as easy and fast as getting analytics. The best product and research teams, and companies like Loom, Open Door, and Dropbox, use Spriggs in-product surveys to target specific users, start collecting insights, and identify issues and opportunities related to activation, onboarding, engagement, and network. Talk about a platform that pays for itself.

But I'm perhaps most excited about Sprigg's newest launch, which extends the power of the platform pre-launch, and makes it possible to test mock-ups and prototypes with your own users in minutes. The testing interface is super slick and doesn't require any of the typical plugins that make testing with your own users unappealing. And with unlimited seats,

you're able to invite anyone from your company to view and use insights generated by Sprig. If you want to get started, head over to sprig.com slash Lenny and mention that I sent it. But before we get to that, I wanted to have one follow-up question. What are some classic examples of high leverage tasks that PM should try to do more often and think about? What's in that bucket generally?

Even though you pointed out a lot of times they could be in any of the buckets depending on how you execute them. Are there things that are just like, you should probably spend a lot of your time doing X, Y, Z? Yeah, so it turns out that the L tasks, PMs implicitly just deep down they know what their L tasks are, because those are the tasks that are bothering them the most. because they are not doing them or because they're not doing them as well as they know they should. So the classic, classic example of this is the case where a PM will say, I know I need to work on getting our strategy right, but I don't have time because I'm busy firefighting.

I'm busy just dealing with all these execution issues and I just don't have time to work on the strategy piece. Sometimes we console ourselves by saying, yeah, yeah, yeah, that's because. we have all these things going on this month, but trust me, next month, we're going to have ample time and I'm going to just spend a whole week working on strategy. Well, the next month rolls around and it's the same thing. You've got other issues. The reason we procrastinate on these tasks are one, because we know that they are all tasks, we know the impact they'll have, and we are a little scared. That's one. The second is they require dedicated attention. And

again, we are afraid about whether we'll have anything interesting to say, right? That's the deep fear why many people procrastinate on strategy because deep down, they just, they don't know if they can formulate a good strategy. So time becomes a convenient excuse for us, where we say, well, it's not me. It's just, I don't have time to work on it. So, and by the way, everything I say here, like, I have been that person. So I have been that person who's procrastinated on an L task, whether it's the strategy or whether it's writing the PRD for this really difficult feature,

or it is working on aligning two teams, where that alignment would create a lot of impact. But it's hard. It's an L task, but I don't do it because I don't want to deal with this other person, this manager I'll have to collaborate with to make it happen. And perhaps, you know, I don't know if we'll get along. I don't know if I can have that tough conversation, right? And so again, it's an L task.

but I'll try to apply band-aids instead of like just tackling it head-on. And so, yeah, this is tough stuff, right? And what I found useful there is two things, two tactics make a huge difference in helping us target L-tasks better. One is the idea of placebo productivity. So what I do is before I have to tackle an L-task, the couple of days leading up to it, I do all these placebo productivity tasks. Basically, I intentionally do N tasks and O tasks.

right just I fill up my day with N&O tasks and I keep reminding myself yeah you're just doing neutral and overhead tasks because then that kind of just like tricks me into thinking okay if I've been doing this placebo productivity task for the last two days now it's the right time for me to do this L task so that's one tactic the other is change of location nothing for me at least fights my procrastination for L tasks better than changing the place from which I'm working so if I normally work from this desk, the day, the appointed day, I did my couple of days of placebo productivity tasks. And on that appointed day, when I'm slated to do an L task, I will actually go out and work from somewhere else, whether it's a coffee shop or a co-working space or some other

space. And I find that, like, that change of place just forces a kind of focus and a shift in mindset that helps me bang out that L task very quickly and do it really well. That is some great advice. There's so many layers of advice in that answer. Your point about the leverage, high leverage tasks being the tasks that you know you kind of should do but don't want to do. Makes me think of a quote that I always come back to that the cave you fear contains the treasure that you seek. And I often find that to be true. And it's kind of this reminder to just wherever the compass is pointing where it's most difficult, it's probably where the biggest opportunity lies.

And so it's a really good reminder of all that. That's so wise. Yeah. Pay attention to your fears because they're telling you something. Speaking of fears, our third big idea is around the three levels of product work. basically the three things that a PM should be focused on, and how often when you're not aligned on what is most important to you and your team, it often leads to conflict. And so I'm excited for you you to unpack this idea of these three levels of product. We're going to all share what they are,

impact execution and optics. And when I saw this for the first time, I always come back to these three things because it's so simple and so accurate. And so I'm excited for you to unpack all this. Yeah, this idea that there are three levels of product work, impact execution and optics. Once you understand it, it explains a lot of what you see in on product teams and organizations in general. And so I'll perhaps start with an example that most product people, product leaders and founders are used to seeing, which is, and something I've seen dozens of times in my career, that there is a product review, say, where you as a PM are presenting to the CEO. And as you're presenting, you know, what the plan is, obviously since this is a real world product,

there's going to be some compromises that you're taking. So the CEO perhaps asks about, okay, well, why is our customer service response time going to be so high in this case? And so you've thought about it, right? Like, it's not like you did not think about that issue. But there is a good reason why, right? Like you talk to the VP of customer support and they don't have the funding this quarter to support your product fully, which will then result in a poor customer service experience for this kind of new product that you're launching. But then you've agreed, you've used your skills of influence to agree that, okay, next quarter,

they're going to allocate a lot more people to your product so that the customer service experience will get better next quarter. And so the CEO asks, like, why is the customer service experience going to be poor here, or they make a remark like that? And then you reply with all these good reasons, like, quote again, good reasons. And, you know, needless to say, the rest of the product review doesn't go as well. And, like, after the product review, you wonder what happened. maybe you ask your manager, like, what happened?

And particularly you're wondering, like, why couldn't the CEO see your very rational argument about why you can't do this at launch, right? It never happened to me. Never happened. Yeah. And so it's kind of like, why doesn't he or she see that, right? And the reason is that you are thinking at different levels, right? Like, so you as a PM perhaps are fixated as you are dealing with this launch or this

project, you are fixated. on the execution level, which is what does it take to get something done and how can I do it? How can I hit the next milestone? Those are all the things we tend to think about when we are thinking at the execution level. The CEO, on the other hand, is approaching it from the impact level. And particularly perhaps in this case, what is the impact to the customer experience? And often like CEOs are the ones, founders are the ones that are thinking about what is the impact to our brand. And so the CEO is thinking at the impact level, you're thinking at the execution level, there is that mismatch, we litigate the minutiae of whatever issue we're discussing, but we never really

recognize that it's because we are kind of default thinking at different levels. And so this realization helped me better understand why there were conflicts between two very smart and well-intentioned people or groups within a company. And time and again, I noticed that, and I was myself guilty of this as well earlier on in my career, like time and again, I noticed that we can again keep litigating the specific issue without understanding that, oh, no, there's actually just like a fundamental mismatch. And it's not like people are stuck at one level and can never think at a different level. It's just that we tend to default to certain levels. And that's like sometimes our preferred level. We can switch levels,

but that requires a nudge sometimes. And so that observation helped explain a lot of things, including, you know, what kind of people an organization will promote, right? Like, does it promote people who default operate at the impact level? Does it promote people who more who default operate at the execution level or at the optics level? So it has like very wide ranging impacts on just like overall how an organization functions. What's an example of optics and when optics matters when you might not be thinking about the importance of that, just unpacking that one a little bit? Yes. So optics is about creating awareness of the impact. and the execution that you're doing or your team is doing. That is the most compact definition

I can come up with for optics. And optics is a good thing, right? So like, I'm not saying don't think about optics whatsoever. I think it's actually important to think about optics. And now I'm talking about just internal optics. External optics is an entirely different thing and that's like marketing PR and that's definitely highly important. But even when we talk about simply, we limit scope to internal optics, I'll make the observation that you should be spent. some time on internal optics because it creates energy, it creates awareness, it creates excitement, it creates opportunities for feedback, those are all really great things and they will enable greater impact and better execution for you. The challenge is, the challenge with optics is that

in certain organizations, that balance gets thrown off, right, where optics sometimes becomes the goal, right, where somehow implicitly the organization or its culture has indicated to its people that as long as you do the optics well, you are going to be fine. You are going to be appreciated here. You're going to be rewarded here as long as you do the optics fine. And it's not like the organization woke up in the morning and said, this is the culture we want to create. It just happens again through little actions that occur every day. It happens through who you hire, who you fire, who you promote. And what kinds of things do you appreciate at all hands as the CEO or the founder? Do you appreciate a launch? Do you appreciate results? Do you appreciate? Do you appreciate?

appreciate an, I don't know, an awesome status update that somebody sent. So a status update doesn't on its own accomplish anything. I mean, they are important, but a status update is an optics activity. Now, it is a necessary optics activity. But if you start appreciating the necessary optics activities constantly, the signal you are sending to people is, oh, you got to focus on this optics activity, right? So then that becomes the goal, and that can be really harmful. So there's these three levels of product work.

Do you have advice for, should I? I just like default to one of these normally based on just like as a PM I should always be thinking about impact or is it more just make sure you're aligned with your leader with your team. Is that the more important takeaway? Yes, I think that's the more important takeaway is again, it's about now we have a vocabulary that we can talk about in an objective manner without kind of pointing fingers. It's like, oh, you tend to be, you know, fixated on all these execution details and like that's not the right thing. That's the type of feedback sometimes that get shared. So now you have vocabulary to talk about this.

And once you have that, you sort of can, as a team, decide what is most important, given your context. I'll give you an example. Like, for early stage teams, yeah, of course, they need to be thinking

about the eventual impact, right? But what they should actually, I think, most early stage teams should actually optimize for execution, assuming that they have

come up with a reasonable hypothesis about what's going to win, their main emphasis, net, needs to be on execution. Because you will not see impact readily on a one-week horizon or a one-month horizon or perhaps even on a quarterly horizon, right? So that's an example of a situation where let's be explicit, right? Like we need to get great at execution. We have a set of core insights that were informed by our desire to make an impact.

But now that we are like responsible for converting these insights into a product, let's be largely operating at the execution level as an example. Say there is a platform team and that platform team has had some issues lately with availability that has disrupted some other teams within the company and their products. Perhaps that platform team should have a conversation that, you know what? Yes, we need to focus on impact obviously to kind of avoid this negative impact. But also, let's pay some more attention to optics because we haven't been communicating with teams as much, teams that rely on us. Right. So let's create a better communication channel with them. let's create better status updates for that whatnot.

So again, the point is not so much like, oh, you should just, this is the right level and all other levels are wrong. It's about being sensitive to what's right in this situation. So you talked about execution and how maybe for early stage startups, that might be default, the most important type of work to be focused on. And that's actually a really good lead way to our fourth big idea, which is kind of a provocative tweet that you put out a while ago, that you said that most execution problems are actually strategy problems or culture problems. And so I'm excited to hear a little bit more about kind of how you discovered that and what that means and maybe how to address those problems. Yeah.

And so I realized this somewhat late in my career as a leader, most execution problems that I encounter in a high-performing environment where everybody has the right intentions are actually not execution problems. they are either strategy problems or interpersonal problems or cultural problems. And so just to illustrate it, I'll make the observation that, you know, many leaders are extremely busy in such environments, whether it's a fast growth startup or a fast growth larger company. They're extremely busy.

They're usually overwhelmed. Like I said earlier, I was one of those people. Take a deeper look at what they're engaged in and I got a chance to look at it with my peers that I was kind of mentoring or coaching or people on my team, PMs or PM leaders, who were extremely busy and usually overwhelmed. I noticed two things that like what made them busy is two things. One is that somehow the organization had imposed very high optics requirements. So they had to do a lot of optics related work, show up at certain status meetings and blah, blah, blah. So we talked about that. So let's leave that aside. But the other reason they're so overwhelmed is that they are constantly

solving execution problems. So they solve the most important ones, the new ones come up. And they solve those. and then there are two new ones to solve and on and on, right? Like it's a classic vacuum-mole. And as I noticed that, and I'll share a concrete example of where this might happen, where an execution, a seemingly execution problem surfaces. So say two teams are misaligned, right? There's lack of, they need to work together with they're misaligned. Everybody knows it.

And that is affecting our execution. That misalignment is affecting our execution. It's affecting our ability to hit our OKRs. It's affecting their ability to hit their OKRs. So as a leader, say you're a director of product or VP of product responsible for one of these teams, you now charge with fixing this execution problem so we can move faster. So you do a dozen beatings to figure out what's going on. You try to diagnose the issue, how to better align.

And then you talk to your peers on the other side. And then you decide, okay, here's what we're going to do to solve this execution problem. We are going to create a new review process. And so we're going to create this process. and we're going to review priorities on a regular basis across these two teams. And then we're going to also as the managers of these individual teams to do regular one-on-ones so they can stay in sync. So this type of scenario is extremely common, again, especially in high growth organizations

that want to accomplish a lot. You'll come up with this solution after many meetings and a lot of work, a lot of conversation. And so as I grew as a leader, I got increasingly curious about this type of situation. And when I looked at it more closely, I started. realizing that what looked like an execution problem, this misalignment and kind of causing execution issues, wasn't usually an execution problem. Instead, it was a strategy problem in some cases because the reason we are misaligned is because we are pursuing different strategies. Or like that is the more often the case is the reason we are misaligned is because we don't

know what the strategy is. We don't know what the strategy is. We craft some OKRs based on what makes sense. The okay-Rs are not very well aligned. We don't have a sense of priorities. And we also don't have a sense of what we do when reality changes. This is all stuff that a strategy, a clear, correct strategy should help inform. But actually, like, this lack of strategy is what's causing this misalignment. It's not because they're not meeting regularly. And what happens in these meetings is, again, you're arguing the minutiae of like, well, are you going to work on this feature? I depend on this. So can you swap two engineers from this team? Like, all of this stuff that PMs are very familiar with. You're talking about all the small stuff, but like nobody recognizes

that like, oh, this, like, can we fix that? Right. So as I started seeing this, often was a strategy problem. Sometimes it was not a strategy problem. It was a culture problem. So what is a culture problem in this situation where two teams are misaligned? It's basically that you have a problem where you have set a culture that you are supposed to mainly optimize for your OKRs, right? In a culture like that, it becomes. really hard to allow two teams to work better together because if one of the teams doesn't hit their okayers because they were helping rightly for the sake of the company they were helping this other team that team's manager is going to get his or her wrist lap at the next performance review

right so that is a culture problem now yeah you can set up the meeting and you can request all the sinks you want between these people it's not going to solve the culture problem it's the execution problem is going to manifest in different ways right a month down the road so that's like an example of a culture problem. Or it could be an interpersonal problem, right? It's simply, and this is actually quite common, it's simply that these two people cannot get along. The two team managers do not get along, right?

And they just constantly might be creating friction, right? And so as a leader, it is important for you to spot that, right? And then coach them through their differences, coach one or both of them through that, so that they can better work together. When you solve that, you won't need that monthly review meeting and all these sinks and 50 other things because they're not going to work anyway. So that's just one concrete example of like team misalignment, which is often viewed as an execution problem, but is not

an execution problem. Are there signs that tell you, okay, we're like dates are slipping, people are surprised like of execution problems that you have? Like, are there signs that maybe it's one of these other factors? Or is your experience like it's almost always one of these other things? So there are some problems that are truly execution problems. So an example of that is Say you have infrastructure issues, right? Like your infrastructure is just like old and it can no longer sustain all the usage that you're getting. That will cause execution problems where you'll move slower or you will have outages or high latencies or whatever the case is. Yeah, that's an execution problem.

Another such example of what is really an execution problem is you have a skills gap. You have, say, engineers who are not particularly skilled in. a certain technology or a certain type of scale that happen to be working in that area, well, that is going to create execution issues, right? Or you have a PM who is more of a zero to one person, but now you made them responsible for this like scale, mature initiative. So that's a skill gap. And that can cause execution problems. Right. So there are very concrete instances where there is a real execution problem. It's just that in high performing organizations that are growing really fast, we ignore the other factors that might be at play.

And so now what tells me if something is seemingly an execution problem but not actually an execution problem? A surefire way of identifying those is when you put on a band-aid and the band-aid falls. So like there are many organizations that are constantly just solving the same problem over and over again, right? Like, oh, we can never get along. Like we can never like get these two teams to work together. Right. Like this team is always slow, right? And so you put the band-aid, but the band-aid doesn't work.

So an organizational memories tend to be surprisingly short. So we forget three months ago we put this band-aid and it's no longer working. We just approached it as, oh, let's create a new solution. So voila, there's a new meeting, right? And so that's where that honesty is important and memory is important. And no, no, no, this is a band-aid we put. But the problem still exists. So it's probably not an execution issue.

I love that visual of a band-aid falling off. That's okay. So this is like a segue way to our fifth and final big idea. Maybe the most mind-bending of all your ideas that I want to talk about. and it's about prioritization. And you make this really interesting point that instead of thinking about the highest R.I. work you should be doing, which is how I've always thought about it, how I think most PMs think about puritization. Your point is you should think about it from a minimizing opportunity cost perspective versus an R.I.

And so I'm excited to hear your take on this and where this idea came from. Yeah, I think I learned this by kind of just observing Patrick at Stripe, particularly over the last couple of years that I was there. And then I kind of like encapsulated what I learned and observed in this tweet, which is when you are in a high leverage role, you should stop doing work that simply, that simply provides a positive return on investment, ROI. And you should start focusing on work that minimizes opportunity cost. And what drives that is the observation that in a high leverage role. So like product management is a good example of a high leverage role. founders by definition are in a high leverage role, engineering leaders, design leaders, designers.

These are all fairly high leverage roles. And in a high leverage role, there will be hundreds of things that you can do that will provide a positive ROI, right? And what is positive ROI? It's simply that the value created is greater than the value of your time that essentially will ensure positive ROI, right? More than zero. So the problem is you should not be doing most of these things.

And the reason this kind of ROI mindset is suboptimal and perhaps even harmful in high leverage roles, the formula for ROI is value created minus cost of your time divided by the cost of your time. So the cost of your time is in the denominator, right? And just for the sake of simplicity, let's just call it time taken, right? So when the time taken to do something is in the denominator and whether it's at an individual level or at a team level, what we end up doing to get high ROI on our work is we end up. up trying to decrease the denominator. So when it's a ratio and you decrease the denominator, the value of the ratio grows. And so how do you decrease the denominator in this case, where time

is the denominator is you start working on things that take less time, right? So you start working on the low-hanging fruit. You start prioritizing the quick wins, right? And the quick wins are very popular, right? Like any team meeting or sprint meeting, oh, that's a quick win. Yeah, let's do it. And I don't have anything against quick wins. The problem is we just fill up our place. with quick wins. And while that may be fine in most cases, in most situations, in high leverage roles, you miss the upside and you miss the opportunity that you could have gained by focusing on other things. Right. Let's take opportunity costs now. Like how do you calculate opportunity cost? Opportunity cost is simply the value of the optimal option minus the value of the

chosen option. Right. So the difference between what could have been the optimal option to pick and the option you did pick is the opportunity. cost, right? So you need to minimize the opportunity cost, meaning you need to be working on the optimal things, right? So when we reprogram ourselves to think in terms of opportunity cost, we are no longer thinking, oh, is this a good use of my time? Right. Instead, you are thinking, is this the best use of my time? And it's a subtle but profound shift in our thinking, because when we think about opportunity cost, we will pick certain things that we would have never picked if we just had the ROI mindset. And again, this applies equal.

at the level of individuals of the work we decide to do as individuals on a day-to-day basis, and the work we do with our teams, the things we prioritize. So that's sort of the basis of this statement that, like, you should try to minimize opportunity costs and focus on those things rather than simply chasing positive ROI. Is there an example that comes to mind of when you did this or maybe did it the wrong way that kind of helped inspire this idea? Or is this just kind of more of a broad lesson that you've learned over time? Oh, I mean, I saw that all the time. The work. kided at pretty much every company. And again, I've been guilty of this myself where I think typically

the type of situation where I have seen this as an example is you are trying to prioritize the next quarter. Right. There are five sure things you can do that will have small to medium impact. And it's very clear. And then there are two ambiguous things that perhaps deep down, you know you should pursue them, but you don't end up picking them because it's again, you're satisfying yourself by observing, oh, each of these is positive ROI, right? Each of these five things that we can do that are very well defined is positive ROI. And so you don't touch those two things. Now, it could be that one of those things could meaningfully change the trajectory of your business and cannot, but doing that requires more work to figure that out, to flesh it out. But we convince ourselves that positive

ROI is great, right? And so we make ourselves busy. And this is what I have seen myself do. I've seen other teams do and certainly like when I sit down with PMs often or even founders, I find that there is this gravitation towards these types of tasks which are simply providing positive ROI. So it shows up most often in our planning essentially. And again, I'm not against things that are quick wins or things that provide positive ROI, but I always want to check what are some big opportunities that we are not paying attention to by default. And under what scenarios can we start changing? that. So when I started working on Stripe Connect, which is a major, major product for Stripe and a large business for Stripe, there was a time when I noticed when I just started working on it,

I noticed the team was working on a lot of positive ROI things. And I came in and kind of like just simply instigated that like, hey, how about we work on this big, scary project? Because I was hearing from customers that there is some need and that the instinct that this need is going to grow in over time of being able to sort of manage marketplace payments in a more flexible way. And we wouldn't have looked at it if we were just focused on positive ROI. But as we started looking at it, we realized, oh, yes, this is a huge opportunity. And we were able to then pursue it because we were sort of shifting the mindset from just positive ROI to minimizing opportunity cost.

More and more question along this line, just to like tactically. Every PM ends up with like a spreadsheet of their ideas and ROI and cost and benefit and all that stuff. Do you recommend folks create kind of a column for opportunity cost? Or is this more of a broad thought process you go through when you're looking through your list of ideas. Yeah, it's more of the latter. I do not recommend trying to quantify opportunity costs because it's a lost cost. Instead, what teams need is just the, sometimes the freedom and sometimes just permission to explore and attack these things that minimize opportunity

cost. And so as leaders, that's the best thing we can do is to give the teams that freedom or the permission to pursue these things. And the way it manifests and the way I've kind of tried to do it is when we are planning, I often give guidance to the team around what percentage of our time we want to spend on what type of activity. And I learned this from Google's classic 70, 2010, where during its fast growth years, Google had the 70% search and ads, 20% apps, which was like things like Gmail and whatnot, and 10% on kind of other big bets. right so i have found that approach very useful during planning where what i will say is like look yeah we need to spend again depends on the context but when the team is starting to plan the next quarter or the

next half or the next year my role as a leader is hopefully i've already clarified the strategy so they have that as an input but the other thing that i see in my role as a leader is to clarify the rough allocation right so what i'll share as a guidance with the team is given our situation and given our strategy and given what's going on in the market, I would like us to target about 60% of our time on incrementals. And by that I mean incremental features that improve users' lives on a day-to-day basis. So these are like actually high ROI things that we do. So 60%. And again, these numbers are whatever they are. If you pick whatever is right for you. But 60% I want to go towards incremental. 30% I want to allocate towards big new initiatives. And because,

it's 30%, it can't be five big new initiatives, it's probably one or two, right? And then 10% I'd like us to allocate towards stability and infrastructure. So this is the guidance I'll share with the team. And then I will ask the teams to create their plans and proposals based on this rough guidance, right? So this kind of gives people the space to like say, okay, we do need, we do have this 30%. So there's no sense putting in more high ROI tasks in there or quick wins in there. And I think just this simple guidance enables the team to kind of just do the right thing and I often get surprised with

all the awesome stuff they come back with. I really like that rule of thumb. What an excellent nugget to include along with this big idea. I'm realizing we've going for an hour and a half now and I don't want to suck up all your time. So there's this idea that I think it might be a really good one to end on. It'll be a bonus sixth big idea

around high agency and the importance of PM's being high agency. And the reason that it stuck out to me is this I found to be really important my career. And I think it led to a lot of the success that I saw along the way is just always feeling like I have agency and feeling ownership of what I was doing and where I was going. And so I'm curious to hear your take on this and to kind of dive into this trade of high agency and how important that is for PMs. Yeah. And I think Eric Weinstein coined this term high agency,

which like once I discovered it kind of resonated a lot and kind of aligned with some of my ideas. And the way I had defined this concept in my head for many years, that high agency is about finding a way to get what you want without waiting for conditions to be perfect or otherwise blaming the circumstances. Right. And so we've all seen such people. They just either push through in the face of adverse conditions or often they manage to reverse the adverse conditions to achieve their goals. And so while this is an important trait for many areas and endeavors, I think this is particularly important for product managers because as product managers, we are constantly fighting adverse conditions, not enough resources, challenges with legacy infrastructure,

staffing issues, customer problems, and on and on, right? Like, there's no dearth of problems to solve as a product manager. And I noticed consistently over the years that it wasn't the, you know, as I started thinking about sort of like, what differentiates the PMs who've had just a large impact and even more important than just impact to the company or to the team. PMs who've surprised me in a positive way, PMs who really exceeded expectations, exceeded perhaps their own capabilities on paper, right? Like you see somebody's credentials on paper and then you see their work and their impact. And there's like a big difference between what you might assume on paper and the impact they're

achieving. And also the reverse of that, which is sometimes you have PMs who just have tremendous potential. They look great on paper. And you know when you're working. with them or you're managing them that they're not achieving that potential. They're nowhere close to achieving that potential. And as I look at both of those situations, it became clear to me that high agency was a big contributor, which is the PMs in this first category were like, despite all the disadvantages and other things, they just took strong ownership. So ownership is one component. Ownership mindset is one component of high agency. They took strong ownership. And then they creatively executed through the challenges. So creative execution is another aspect of

high agency. And they did that with a high degree of resilience, which is a third aspect of high agency. And so as I realized that, it became very clear as to why this was happening. And then it's one of those things that like once you see it, you start seeing it in people much more clearly. And so that's when I wrote about the PM version of high agency. I think that's why it resonated with a lot of people because it kind of like gave, again, it gave vocabulary to people for what they already kind of understood and they had seen it, but did not have the words for. I think that's a really good way to wrap this up, just leaving people with that point of just the empowerment, basically, taking responsibility, feeling high agency, resiliency.

Shreos, this has been incredibly illuminating. I suspect this is going to be helpful to a lot of product managers and even non-product managers. And so just two last questions. Where can folks find you online if they want to reach out or learn more? and then how can listeners be useful to you? Yeah, so follow me on Twitter. I'm just at Shreya's. If you don't have a Twitter account, follow me on LinkedIn.

You can just find me there, Shreya's Doshi. If you really enjoy the tweets and want to see more, then you can super follow me on Twitter. So this is a smaller community that I'm really enjoying of product managers, founders, product people, designers, engineers, etc. where we go much deeper into these types of topics and more. And yeah, if you'd like to learn more about my views on various things related to product,

super following me perhaps is a great way to do that. And in terms of other things I'm working on, I am going to be launching a course on Product Sense and Product Management later this year. So be on the lookout for that if that's of interest. And then lastly, I think the best help I can ask for from listeners is just if any of these ideas resonated with you, share them with others. And of course, if there are questions, feel free to ask. But I think my mission here is to really help perhaps bring greater clarity on what is going on around us when we're working in teams and working on projects and products.

And so I really like it when people share the ideas, whether it's on Twitter or publicly or even with others privately. So that is perhaps the best thing you can do. Help me in my mission. Amazing. What a beautiful way to end it, Shreos. Thank you so much for this conversation. Thanks, Lenny. This was a blast. Thanks for having me. It's really a privilege. And I am looking forward to another conversation sometime in the future. Ten big ideas by Shreas Doshi coming up. I'm really excited about that to you. Thank you again. Great. Bye. That was awesome. Thank you for listening. If you enjoy the chat, don't forget to subscribe to the podcast.

You could also learn more at lenniespodcast.com. I'll see in the next episode.