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

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 https://www.lennysnewsletter.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:03Lenny Rachitsky?

  There's no one out there today who shares more wisdom, more consistently, on the art of product management than Shreyas Doshi. Shreyas 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 Shreyas 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. Shreyas 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.

• 0:48Lenny Rachitsky?

  In our chat, we focus on five topics and go deep on them. We talk about the power of pre-mortems. 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 Shreyas made the time for our chat, and I cannot wait for you to hear it.

• 1:29Lenny Rachitsky?

  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 Coda 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 Coda 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 Coda doc gallery, including resources for many guests on this podcast. Podcast, including Shreyas, Gokul and Shashir, the CEO of Coda.

• 2:14Lenny Rachitsky?

  Some of the best teams out there like Pinterest, Spotify, Square and Uber. Use Coda 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 Coda. You can take advantage of a special limited time offer just for startups. Head over to coda.io/leni to sign up and get a thousand dollar credit on your first statement. That's C O D A dot I O slash leni to sign up and get a thousand dollars in credit on your account.

• 2:49Lenny Rachitsky?

  This episode is brought to you by 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 love 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.

• 3:33Lenny Rachitsky?

  Visit productboard.com to learn more.

• 3:41Lenny Rachitsky?

  Shreyas, the man, the myth, the legend. Thank you so much for joining me and for having this conversation.

• 3:48Shreyas Doshi?

  It's great to be here, Lenny.

• 3:49Lenny Rachitsky?

  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 is 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 Shreyas Doshi. Does that sound about right?

• 4:14Shreyas Doshi?

  Sounds great.

• 4:15Lenny Rachitsky?

  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 and things like that. So I'd love to learn a little bit more about the human that is Shreyas. And so maybe we start there, like where were you born? Where'd you grow up? What did your parents do for work? Or what did you want to be when you grew up?

• 4:35Shreyas Doshi?

  So I was born in Mumbai, Bombay, India, and I lived there for the first twenty-one 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 twenty-one. 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,

• 5:14Shreyas Doshi?

  I used to be packaging the spices into the little box or creating some marketing material for him, not the creative part, but the grunt 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,

• 5:57Shreyas Doshi?

  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, I'll 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 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,

• 6:37Shreyas Doshi?

  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.

• 6:50Lenny Rachitsky?

  How's your French these days?

• 6:51Shreyas Doshi?

  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.

• 7:03Lenny Rachitsky?

  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?

• 7:10Shreyas Doshi?

  Oh, yeah. So I started my career as an engineer, all while backtracking. So I completed my undergrad in India, 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 gonna drop out of the PhD program. And once I dropped out, this was like two thousand one, two thousand two, 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.

• 7:53Shreyas Doshi?

  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.

• 8:35Shreyas Doshi?

  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 twenty percent engineer. I realized that I would never be a great engineer, that I would never be a top ten percent engineer. Cause I saw those engineers, I had 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.

• 9:20Shreyas Doshi?

  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.

• 9:34Lenny Rachitsky?

  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 PMs moving into PM because they aren't going to make it as an engineer.

• 9:56Shreyas Doshi?

  Yeah, I think it might be a common occurrence because engineering is a really great job. And like particularly on empowered 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 in, 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.

• 10:41Shreyas Doshi?

  And once you do that, you can decide what path to pick.

• 10:44Lenny Rachitsky?

  It's such a bonus to have that background as a PM. I wanted to go back to some you mentioned that you worked at LoudCloud. I had no idea. That was Marc Andreessen's second company, right?

• 10:53Shreyas Doshi?

  Yes, I joined that team. I was interviewing with them for, again, this was a time when like they 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 LoudCloud part of that organization.

• 11:17Lenny Rachitsky?

  Got it. Is there something that you took away from that company? Like, was Marc Andreessen still working there? And I think Ben Horowitz also?

• 11:23Shreyas Doshi?

  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 our relationship with Opsware. Because the way that split worked is EDS would use Opsware's 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 twenties, 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.

• 12:06Shreyas Doshi?

  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 LoudCloud 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.

• 12:32Lenny Rachitsky?

  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 has kind of stuck with you? And you share a lot of this on Twitter, but if you just think about like, some I took away from each of these companies, or even the founders that ran these companies, what might those be?

• 12:53Shreyas Doshi?

  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

• 13:33Lenny Rachitsky?

  Real, 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 wanna log in with Yahoo, is that right?

• 13:42Shreyas Doshi?

  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?

• 14:26Shreyas Doshi?

  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.

• 14:36Lenny Rachitsky?

  Great advice. Okay, sorry, I cut you off. Google.

• 14:38Shreyas Doshi?

  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 Help people sort of think big by default. And so I think my, the six years I spent at Google really kind of helped me understand that really well and just make it a normal part of how I operated. So that was really useful for me.

• 15:18Lenny Rachitsky?

  Is there an example that at Google that something you worked on that was like, holy shit, this is gonna be big or let's think bigger about this?

• 15:24Shreyas Doshi?

  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 a hundred million dollars in revenue, it's not worth talking about it, right? Because the ads business was growing so fast and was so large that like we would regularly not pursue opportunities that were just, quote, a hundred million dollars. And so why do that, right? 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.

• 16:07Shreyas Doshi?

  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 ten million dollar business here, but like, can we make it a hundred million dollar business? Or there is a one million dollar business here, can we make it a ten million dollar 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

• 16:50Shreyas Doshi?

  on some trends simply because of this filter or this high bar, where sometimes it's not clear if something is a hundred million dollar opportunity or a billion dollar opportunity. And so, so that is a downside of this. What I mainly took away is, for instance, even at Stripe, when I joined, I was just 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 in 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

• 17:34Shreyas Doshi?

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

• 18:19Shreyas Doshi?

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

• 18:45Lenny Rachitsky?

  Let's do it. Let's do it.

• 18:46Shreyas Doshi?

  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 overlapped 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.

• 19:30Shreyas Doshi?

  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.

• 19:38Lenny Rachitsky?

  Is there an example that or a story of that that happening that you think about?

• 19:41Shreyas Doshi?

  Yeah, I think I forget the details and they're not that important anyway, but like 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 we went through, as is common in many 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?

• 20:24Shreyas Doshi?

  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.

• 20:52Lenny Rachitsky?

  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, I 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?

• 21:08Shreyas Doshi?

  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.

• 21:50Shreyas Doshi?

  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, so that's something I learned a lot of working with John. From Patrick, I think the main thing I learned was just how to think and 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

• 22:34Shreyas Doshi?

  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.

• 23:08Lenny Rachitsky?

  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 to kind of shifting to talk about the, the five big ideas. The first is around this concept of pre-mortems. There's something that stuck with me when you tweeted it. I think it was a couple of 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.

• 23:52Lenny Rachitsky?

  And so curious to kind of hear your thoughts on this idea of pre-mortems. Just unpack this idea for folks.

• 23:58Shreyas Doshi?

  Yeah, we're all familiar with a postmortem, 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 postmortem. 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 postmortem that. And over the years, I really saw the effectiveness of a postmortem, right? Some really great insights came out of a postmortem about what went wrong and what we could have done better. And as I saw the effectiveness of a postmortem, that's what made me wonder, why do we need to wait until after things go wrong? Because like, why can't we extract these, some of these insights before they go wrong?

• 24:42Shreyas Doshi?

  So and it was around that time that I discovered the idea of a pre-mortem. I learned about it from an Harvard 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 pre-mortem is that if you do a pre-mortem 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 pre-mortem ritual is the initial prompt. So it's not just about like, well, what could go wrong, right?

• 25:23Shreyas Doshi?

  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 pre-mortem meeting 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 out.

• 26:08Shreyas Doshi?

  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're 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 pre-mortem 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 pre-mortem works. And what I've found is, and you know, 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, ah, is it really going to work?

• 26:52Shreyas Doshi?

  And then we go through the pre-mortem 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, thirty 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 pre-mortems, now that I've done them with, you know, various other companies as well that I advise and whatnot, is the shared vocabulary. And it's 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.

• 27:35Shreyas Doshi?

  One is a tiger. So you can bring up tigers in the shared doc 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 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. That, and so an elephant could be like, well, we are assuming that just because we launched this and do-

• 28:18Shreyas Doshi?

  A bunch of PR that we'll get users, but are we sure we're gonna get users, right? Like, that's kinda 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 pre-mortems 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 OK for people to bring those things up, which I think is perhaps the best part about a pre-mortem is that shared vocabulary.

• 28:44Lenny Rachitsky?

  Such a simple idea that is clearly going to benefit you and 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 you do this, that kind of stuff?

• 29:01Shreyas Doshi?

  Yeah, and so as I started doing pre-mortems, they got more and more popular at Stripe. Other teams started doing them. And then afterwards, I, you know, helped some startups kinda also do pre-mortems. And at some point, I decided I should just like write down my template for pre-mortems. So I worked with the folks at Coda to create a Coda doc, which you can find and we can put in the show notes if possible. Basically, that's an entire kinda template for how to run pre-mortems using this method that I talked about, including tigers, paper tigers, elephants, all of that. The main thing about a pre-mortem is to include people from every function that is going to be involved in, say, if you're doing a launch.

• 29:43Shreyas Doshi?

  And so if it's a really large launch, sometimes I will separate it into two groups. One is everything related to kinda like the engineering side of things, where you can kinda 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 ten, fifteen, twenty, 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 pre-mortem for the go-to-market side. And so that will involve sales team, support team, marketing team, involve design team. Some of the core engineering leads will also.

• 30:28Shreyas Doshi?

  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's present. And like I said, start with the prompt of imagine this has failed. So as the pre-mortem meeting leader, it's my responsibility to share the prompt. And then I like doing these pre-mortems 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.

• 31:10Shreyas Doshi?

  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 most scary, but that somebody else mentioned. So not their own tiger, but some other tiger that somebody else mentioned that they found most scary. So that ends up being a sort of, you know, people basically are voting. And then as the pre-mortem 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.

• 31:55Shreyas Doshi?

  So then I like to create a post-pre-mortem action plan and then share that with the team and kind of keep myself as the leader accountable for actually making progress on it.

• 32:04Lenny Rachitsky?

  Having started doing this, have you noticed a 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?

• 32:13Shreyas Doshi?

  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.

• 32:57Shreyas Doshi?

  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 a pre-mortem is like a very sort of inexpensive way to see these things.

• 33:37Shreyas Doshi?

  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 pre-mortems is it's one of those very low downside, but very high upside things that I've experienced.

• 33:54Lenny Rachitsky?

  I'm excited to see this template. I haven't seen it yet. I didn't know that you put one together, so that's awesome. And yeah, we'll link it in the 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 turn it over to you to share what that's all about.

• 34:15Shreyas Doshi?

  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 look 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.

• 35:00Shreyas Doshi?

  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 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

• 35:42Shreyas Doshi?

  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 types 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.

• 36:23Shreyas Doshi?

  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 tasks when I was feeling most productive, most energetic during a certain time of the day.

• 37:07Shreyas Doshi?

  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 N tasks and O tasks. And so there are some tasks that you do. A 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, no, I need to do that.

• 37:51Shreyas Doshi?

  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, et cetera, et cetera, 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 out the template that diligently

• 38:36Shreyas Doshi?

  and you don't add fifteen 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. And 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'd try to make them really good, which took a 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

• 39:20Shreyas Doshi?

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

• 40:02Shreyas Doshi?

  Or people say, well, but I thought we said this or 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 the, some of the ideas behind the LNO framework.

• 40:18Lenny Rachitsky?

  Yeah, and that's, that last piece is a really good segue to the next big idea around optics and the importance of optics. This episode is brought to you by Sprig. 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 at companies like Loom, Open Door and Dropbox use Sprig's in-product surveys to target specific users, start collecting insights and identify issues and opportunities related to activation, onboarding, engagement and that. Talk about a platform that pays for itself. But I'm perhaps most excited about Sprig's newest launch, which extends the power of the platform pre-launch and makes it possible

• 41:03Lenny Rachitsky?

  to test mockups 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 on a feeling. 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/lenny and mention that I sent.

• 41:26Lenny Rachitsky?

  But before we get to that, I wanted to have one follow up question. What are some classic examples of high leverage tasks that PMs 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?

• 41:43Shreyas Doshi?

  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,

• 42:27Shreyas Doshi?

  but trust me, next month, we're gonna have ample time and I'm gonna 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 L 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.

• 43:08Shreyas Doshi?

  So, 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-

• 43:35Shreyas Doshi?

  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 love 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, so yeah, this is tough stuff, right? Like, 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,

• 44:19Shreyas Doshi?

  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 and 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,

• 45:02Shreyas Doshi?

  whether it's a coffee shop or a coworking 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.

• 45:15Lenny Rachitsky?

  That is some great advice. There's so many layers of advice in that, 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 that's a really good reminder of all that.

• 45:39Shreyas Doshi?

  That's so wise. Yeah. Pay attention to your fears because they're telling you something.

• 45:44Lenny Rachitsky?

  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 to unpack this idea of these three levels of product work and I'll share what they are. Impact, execution and optics. And when I saw this for the first time, I always come back to this, these three things because it's so simple and so accurate. And so I'm excited for you to unpack all this.

• 46:12Shreyas Doshi?

  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 a, 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. And so the CEO perhaps asks about, okay, well, why is our customer service response time going to be so high?

• 46:56Shreyas Doshi?

  In this case, and so, and 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.

• 47:37Shreyas Doshi?

  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. Why couldn't the CEO see a very rational argument about why you can't do this at launch, right?

• 47:56Lenny Rachitsky?

  Never happened to me, never.

• 47:57Shreyas Doshi?

  Yeah, and so it's kind of like, why, 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're 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 are 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, right?

• 48:40Shreyas Doshi?

  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 are 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 the specific issue without understanding that, oh, no, there's actually just like a fundamental mismatch.

• 49:23Shreyas Doshi?

  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, right? So it has like very wide-ranging impacts on just like overall how an organization functions.

• 49:58Lenny Rachitsky?

  What's an example of? Of optics and when optics matters, when you might not be thinking about the importance of that, just unpacking that one a little bit.

• 50:06Shreyas Doshi?

  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 spending some time on internal optics because it creates energy, it creates awareness, it creates excitement, it creates opportunities

• 50:51Shreyas Doshi?

  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're 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

• 51:34Shreyas Doshi?

  do you appreciate at all hands as the CEO or the founder, right? Do you appreciate a launch? Do you appreciate results? Do you 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've got to focus on this optics activity, right? So then that becomes the goal and that can be really harmful.

• 52:09Lenny Rachitsky?

  So there's these three levels of product work. Do you have advice for, should 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?

• 52:23Shreyas Doshi?

  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 gets shared. So now we 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, right? Assuming that they have come up with a reasonable hypothesis about what's going to win.

• 53:08Shreyas Doshi?

  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.

• 53:51Shreyas Doshi?

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

• 54:21Lenny Rachitsky?

  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.

• 54:48Shreyas Doshi?

  Yeah, and so I realized this somewhat late in my career as a leader. Yeah, 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

• 55:33Shreyas Doshi?

  leaders were like 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're 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 hole. And as I noticed that, and I'll share a concrete example of where this might happen, right? Where an execution, a seemingly execution problem surfaces.

• 56:17Shreyas Doshi?

  So say two teams are misaligned, right? There's a lack of, they need to work together, but 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, or 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 gonna do to solve this execution problem. We are going to create a new

• 56:58Shreyas Doshi?

  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 ask the managers of these individual teams to do regular one on ones, so they can stay in sync. And like, 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 this is kind of causing execution issues, wasn't usually an execution problem.

• 57:40Shreyas Doshi?

  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, right? So we don't know what the strategy is. We craft some OKRs based on what makes sense. The OKRs 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 are not meeting regularly.

• 58:22Shreyas Doshi?

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

• 59:05Shreyas Doshi?

  Because if one of the teams doesn't hit their OKRs. Because they were helping rightly for the sake of the company, they were helping this other team. That team's manager is gonna get his or her wrist slapped 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 syncs you want between these people. It's not going to solve the culture problem. It's gonna be, the execution problem is gonna 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?

• 59:49Shreyas Doshi?

  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 syncs and fifty other things. Because they're not gonna 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.

• 1:00:09Lenny Rachitsky?

  Are there signs that tell you, okay, where like dates are slipping? People are surprised like of execution problems 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?

• 1:00:22Shreyas Doshi?

  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 gonna create execution issues, right?

• 1:01:06Shreyas Doshi?

  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 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, right? 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?

• 1:01:51Shreyas Doshi?

  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. That no, no, no, this is a Band-Aid we put, but the problem still exists. So it's probably not an execution issue.

• 1:02:14Lenny Rachitsky?

  I love that visual of a Band-Aid falling off. That's a, it's okay. So this is a good segue 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 ROI work you should be doing, which is how I've always thought about it, how I think most PMs think about prioritization. Your point is you should think about it from a minimizing opportunity cost perspective versus ROI perspective. And so I'm excited to hear your take on this and where this idea came from.

• 1:02:47Shreyas Doshi?

  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, like, these are all fairly high leverage roles.

• 1:03:32Shreyas Doshi?

  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,

• 1:04:16Shreyas Doshi?

  what we end up doing to get high ROI on our work is we end up trying to decrease the denominator. So when it's a ratio and you decrease the denominator, the value of the ratio grows, right? 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 like 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, right? And I don't have anything against quick wins. The problem is we just fill up our plate with quick wins. And while that may be fine in most cases, in most situations, in high leverage roles,

• 1:04:57Shreyas Doshi?

  you miss the upside and you miss the opportunity that you could have gained by focusing on other things, right? Let's take opportunity cost 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

• 1:05:38Shreyas Doshi?

  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 equally 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.

• 1:06:09Lenny Rachitsky?

  Is there an example that 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?

• 1:06:18Shreyas Doshi?

  Oh, I mean, I saw that all the time, the work I did 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.

• 1:06:59Shreyas Doshi?

  Now, it could be that one of those things could meaningfully change the trajectory of your business. And can, 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.

• 1:07:39Shreyas Doshi?

  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 chasing 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.

• 1:08:24Shreyas Doshi?

  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.

• 1:08:34Lenny Rachitsky?

  One more question along this line, just 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?

• 1:08:51Shreyas Doshi?

  Yeah, it's more the latter. I do not recommend trying to like quantify opportunity cost because it's a lost cause. Like 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, right?

• 1:09:32Shreyas Doshi?

  And I learned this from Google's classic seventy, twenty, ten, where during its fast growth years, Google had the seventy percent search and ads, twenty percent apps, which was like things like Gmail and whatnot, and ten percent 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.

• 1:10:16Shreyas Doshi?

  I would like us to target about sixty percent 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 sixty percent and again, these numbers are whatever they are, if you pick whatever is right for you. But sixty percent, I want to go towards incrementals. Thirty percent, I want to allocate towards big new initiatives. And because it's thirty percent, it can't be five big new initiatives. It's probably one or two, right? And then ten percent, 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.

• 1:11:00Shreyas Doshi?

  Right. So this kind of gives people the space to like say, okay, we do need, we do have this thirty percent. So there's no sense putting in more high ROI tasks in there or quick wins in there. And I think just the simple guidance like 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.

• 1:11:17Lenny Rachitsky?

  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 six big idea around high agency and the importance of PMs being high agency. And the reason that it stuck out to me is this I found to be really important in 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.

• 1:11:55Shreyas Doshi?

  Yeah, and I think Eric Weinstein coined this term high agency, which like once I discovered it kinda resonated a lot and kinda 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

• 1:12:40Shreyas Doshi?

  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've really exceeded expectations, exceeded perhaps like their own capabilities on paper, right? Like you see somebody's credentials on paper and like then you see their work and their impact.

• 1:13:22Shreyas Doshi?

  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 like 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

• 1:14:05Shreyas Doshi?

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

• 1:14:38Lenny Rachitsky?

  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. Shreyas, 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?

• 1:15:00Shreyas Doshi?

  Yeah, so follow me on Twitter, I'm just at Shreyas. If you don't have a Twitter account, follow me on LinkedIn, you can just find me there, Shreyas 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, et cetera, 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.

• 1:15:44Shreyas Doshi?

  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 are 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.

• 1:16:22Lenny Rachitsky?

  Amazing. What a beautiful way to end it, Shreyas. Thank you so much for this conversation.

• 1:16:27Shreyas Doshi?

  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.

• 1:16:34Lenny Rachitsky?

  10 Big Ideas by Shreyas Doshi coming up. I'm really excited about that too. Thank you again. Great. Bye. That was awesome. Thank you for listening. If you enjoyed the chat, don't forget to subscribe to the podcast. You can also learn more at lennyspodcast.com. I'll see you in the next episode.