- you should be spending some time on internal optics because it creates energy, it can 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. -. there's no one out there today who shares more wisdom more consistently on the art of product management than shreyas doshi. Shreyas 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 shreyas is that his insights are often framed in really memorable, in 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. 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. This episode is brought to you by coda's an all-in-one doc that combines the best of 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 from many guests on this podcast, including shreyas, gokul, and shishir, the ceo of coda. 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 pinging 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/lenny to sign up and get a thousand dollars credit on your first statement. That's coda.io/lenny to sign up and get a thousand dollars in credit on your account.

This episode is brought to you by productboard. Product leaders trust productboard to help their teams build products at matter. From startups to industry titans, over 6,000 companies rely on productboard to get the right products to market faster, including companies like zoom, volkswagen, uipath, and vanguard. Productboard 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.

Visit productboard.com to learn more. Shreyas, the man, the myth, a 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 what we decided to do is instead of a regular interview where we talk about a lot of stuff, instead we're gonna 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 gonna call it the five big ideas from shreyas 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 kind of 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'd your parents do for work? What did you wanna be when you grew up? -. So i was born in mumbai, bombay, 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. 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 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. What i wanted to be when i grew up, i changed that a lot 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'l maybe teach french after i graduate from college. Maybe i'l go to france, learn the language a little more. And maybe i'l teach french. That lasted for a few years. 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.

-. And 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 or well 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 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. And 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 'cause i was fairly junior and i was an engineer, but i was like, "okay, i'l just go to the customer meetings.". And i really enjoyed that. I really enjoyed understanding what our customers were trying to do and 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. 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 figured out what needed to build, to be built, and i would just build it myself. And 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 'cause 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 that support, it would've 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. 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. I wonder how often that happens of pms moving into pm because they aren't gonna 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. 'cause 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, "well, try out engineering because, again, in many companies, fortunately these days, you can do a lot more than just 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 so you mentioned that you worked at loudcloud. I had no idea that was marc andreessen's second company, right? -. Yes, i joined that team. I was interviewing with them for again, this was a time when like there were very scarce 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. - 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? -. 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. And i think i was most struck 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 of a very high caliber team, people who were really great at their job and brought a 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 has kind of stuck with you? I know you share a lot of this on twitter, but if you just think about like something i 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 'cause 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 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 'cause i was working on the identity team at yahoo. - real quick on yahoo- - yeah, go ahead. -. 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? - yes. That's the story of every acquisition where 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 makes sense over time that like everybody who uses youtube should have a google account. So they went through a multi-year migration of accounts at google, and they had similar backlash. The interesting part though is nobody remembers that now. 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 i 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 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 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. - is there an example of that at google that some of you worked on that was, like, holy shit, this is gonna be big, or let's think bigger about this?

-. Yeah, as with anything, 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 gonna generate more than a hundred million dollars in revenue, it's not worth talking about it. Because the ads business was growing so fast and was so large that we would regularly not pursue opportunities that were just, quote, "a hundred million dollars". So why do that's because google had access to billion dollar opportunities for it as 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, 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 hundred million dollars 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 hundred million dollar opportunity or a billion dollar opportunity. 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 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 'cause 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, 'cause if you think about it, there's still no product like twitter 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 kinda 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, sound judgment, low ego and small teams, you just get magic. 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 and kind of my growth and thinking as a leader. And i can go on with the founders 'cause 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 at 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, 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. 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. 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 that or a story of that happening that you think about? -. 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. 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 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? Like a simple question. But then at that point, i realized,. Yeah, we never really talked about that 'cause we were so engrossed in all the other stuff. And we talked about it as a proxy 'cause 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, i really find this really important and this is a really important question 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 gonna talk about stripe too, right? -. Yes, stripe, i worked a lot with patrick and 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 talking about the product in terms that, again, obvious stuff, but talking about product that customers really understand. And then sometimes, emphasizing things that we as product people might not think are really important because maybe we didn't spend much time on building it. And we wanna 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 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 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.

- 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 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 years ago at this point. And i see it come up occasionally in your tweets and amongst people chatting your super follower threads.

I also like that there's something you can actually implement and act on pretty quickly and see impact. And so curious to kind of hear your thoughts on this idea of pre-mortems. Just unpack this idea for folks. -. Yeah, we are all familiar with a postmortem or as they call it in the military, i think after action reviews. So every company i 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. 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? 'cause like why can't we extract some of these insights before they go wrong? And it was around that time that i discovered the idea of a pre-mortem. I learned about it from a 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 gonna 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? 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 can 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're concerned about, but that they were just hesitant to bring up because nobody likes to be negative in modern organizations. 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 factor in why a pre-mortem works. And what i've found is at stripe, i did this regularly with launches that my team was involved in. Sometimes some teams or some people were like just surprised or skeptical like, is it really gonna work? 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, 30 minutes for an hour just talking about terrible scenarios of things that could go wrong, but everybody's feeling a little lighter 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 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 doc that we create. And a tiger is a threat that will actually kill us just like a tiger would. So these are 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 sure 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 seeing reality as it is. And so an elephant could be like, well, we are assuming that just because we launched this and do a bunch of pr that we will get users, but are we sure we are gonna get users?

That's kind of like the elephant in the room that nobody's talking about that 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 okay for people to bring those things up, which i think is perhaps the best part about a pre-mortem is that shared vocabulary. -. Such a simple idea that is clearly going to benefit you and your team. And it's interesting that people 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. -. As i started doing pre-mortems, they got more and more popular at stripe. Other teams started doing them and then afterwards, i helped some startups kind also do pre-mortems. And at some point, i decided i should just 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. - absolutely. - basically, that's an entire kind of 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. And so if it's a really large launch, sometimes i will separate it into two groups. One is everything related to kind 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 pre-mortem for the go-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.

And then over there, pr will be there. Over there, we'l 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'l share the prompt. And then i'l 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 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 people basically are voting. And then as the pre-mortem leader, it's my responsibility to take all of that output that the team has generated in this document and then prioritize 'cause, again, the point is not to solve every problem. 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 gonna deal with it only to find nobody was thinking about it. 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. -. Having started doing this, have you noticed a less need for postmortems, basically projects failing less and having less problems? Like what kind of impact have you seen executing on this idea? - yeah, absolutely. I've seen us identify certain issues that just wouldn't have come up. And likely, you can't really run a simulation and see what the count of actually look like in real life. But those likely would have resulted in a problematic situation afterwards. A great example is sometimes you'l see a company announce something, and they have massive backlash. And then a reasonable observer might say, well, how did this company miss this? 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'l say, "sorry, we didn't think about these issues. Give us some more time and we'l kind of come back.

And we'l perhaps relaunch the feature, but in a better way," to the casual observer, 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 gonna 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 because all it is one meeting, followed by some work that the leader needs to do to prioritize, followed by some mitigating actions, which you would've had to take anyway. So that's why i'm a huge fan of pre-mortems. It's one of those very low downside, but very high upside things that i've experienced. - 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'l link it in the notes of this episode. I wanna move to our second big idea, which is about something you've called lno framework, which is all around prioritizing your finite time as a pm and as a team. And so i'l just kind of turn that over to you to share what that's all about. -. Yes. And so i'm gonna 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. I would work 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. I was also a little bit of a perfectionist so i was like, "no, i need to do this well.". And yeah, constantly, i would come home and talk to my wife and kind of basically just complained to her about how i'm not able to make progress or as much progress as i want. That was accompanied with like 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 a 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, they, 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 that 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. And for the l tasks, let my inner perfectionist shine because i'm gonna get so much more in return. 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. I'm gonna 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. It sounds silly, but i used to try to make my expense reports really good. - wow. -. And sometimes like that made no sense, but i was like "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 activity of filing a bug report. And so many companies have these bug templates, et cetera, et cetera. 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 old task where you don't fill out 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.

And the last example i'l 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. After i understood this, previously, i would just send all notes, like i try 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 just standard stuff. I just need to like quickly list out people. All 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 gonna send the notes out the moment the meeting is over. I'm just gonna hit send because i've already taken the action items. I'm not gonna 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 wanna perfect those notes before you send them out. You want to get the language right. You wanna 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'd said this.". So that's 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 sprig. If you've been a member of my community for a while, you know my user fan and investor in 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, opendoor, and dropbox use sprigs in product surveys to target specific users, start collecting insights, and identify issues and opportunities related to activation, onboarding, engagement, and more. Talk about a platform that pays for itself. But i'm perhaps most excited about sprigs newest launch, which extends the power of the platform pre-launch and makes it possible 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 appealing. 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 you. 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 kind of 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 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're not doing them or because they're not doing them as well as they know they should. So the 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.". And sometimes we console ourselves by saying, "yeah,. That's because we have all these things going on this month, but trust me next month, we are 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're l tasks, we know the impact they'l 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 will have anything interesting to say. That's the deep fear why many people procrastinate on strategy because deep down, 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.". 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 love to collaborate with to make it happen. And perhaps, i don't know if we'l get along. I don't know if i can have that tough conversation. And so again, it's an l task, but i'l try to apply bandaids instead of like just tackling it head on.

And so yeah, this is tough stuff. And what i've 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, that couple of days leading up to it, i do all these placebo productivity tasks. Basically, i intentionally do n tasks and o tasks. Just i fill up my day with lno 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 tasks 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 coworking space or some other space.

And i find that like the 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 wanna do, it 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's so wise. Yeah, pay attention to your fears 'cause 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 to unpack this idea of these three levels of product work. It'l share what they are, impact, execution, and optics. When i saw this for the first time, i always come back to these three things 'cause 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 explains a lot of what you see on product teams and organizations in general. And so i'l perhaps start with an example that most product people, product leaders, and founders are used to seeing, and something i've seen dozens of times in my career is that there's 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 gonna 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 you've thought about it's not like you did not think about that issue, but there is a good reason why. 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 gonna 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 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 a very rational argument about why you can't do this at launch? -. Never happened to me, never. -. And so it's kind of like, why doesn't he or she see that? And the reason is that you are thinking at different levels. 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, the 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 are 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 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 what kind of people an organization will promote. Does it promote people who default operate at the impact level? Does it promote people 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, 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. 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'l make the observation that you should be spending some time on internal optics because it creates energy, it can 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 where optics sometimes becomes the goal. 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 gonna 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, 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 gotta focus on this optics activity. 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 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 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 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'l give you an example. Like for early stage teams, of course, they need to be thinking about the eventual impact, right? 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 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.

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 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. So let's create a better communication channel with them. Let's create better status updates for them or whatnot. So again, the point is not so much like, oh, 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 the 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 that 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'l make the observation that 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. When you 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 are 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.

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. Like it's a classic whack-a-mole. And as i noticed that, and i'l share a concrete example of where this might happen, where a seemingly execution problem surfaces. So, say, two teams are misaligned. Hey 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 are charged with fixing this execution problem so we can move faster. So you do a dozen meetings 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 review process. So we are gonna create this process, and we are gonna review priorities on a regular basis across these two teams.

And then we are gonna also ask 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'l 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 was 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 'cause we don't know what the strategy is. 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's a strategy, a clear correct strategy should help inform. But, actually, 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, how you gonna work on this feature? I depend on this. Can you swap two engineers from this team? All of this stuff that pms are very familiar with that you're talking about all the small stuff, but like nobody recognizes that like, oh, can we fix that?

So as i started seeing this, it 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. 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 okrs 'cause 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 slap at the next performance review. 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. The execution problem is gonna manifest in different ways a month down the road. So that's like an example of a culture problem, or it could be an interpersonal problem. And this is actually quite common. It's simply that these two people cannot get along. The two team managers do not get along. And they just constantly might be creating friction. And so as a leader, it is important for you to spot that. 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 50 other things 'cause they're not gonna work anywhere. 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, or dates are slipping, people are surprised like of execution problems that you have? 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. 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'l 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? 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. 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 bandaid and the bandaid falls. So like there are many organizations that are constantly just solving the same problem over and over again. Like, oh, we can never get along. We can never like get these two teams to work together, or like this team is always slow.

And so you put the bandaid, but the bandaid doesn't work. And organizational memories tend to be surprisingly short. So we forget three months ago, we put this bandaid and it's no longer working. We just approach it as, oh, let's create a new solution. So voila, there's a new meeting. And so that's where that honesty is important and memory is important that no, this is a bandaid we put, but the problem still exists so it's probably not an execution issue. - i love that visual of a bandaid falling off. We've all seen that. This is a good segue to our fifth and final big idea, maybe the most mind-bending of all your ideas that i wanted 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 an roi perspective. 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 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. And in a high leverage role, there will be hundreds of things that you can do that will provide a positive roi.

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, 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 is 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. And just for the sake of simplicity, let's just call it time taken. 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 trying to decrease the denominator. So, when it's a ratio and you decrease the denominator, the value of the ratio grows. 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.

So you start like working on the low-hanging fruit. You start prioritizing the quick wins. And the quick wins are very popular. 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 plate 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. Let's take opportunity cost. How do you calculate opportunity cost? Opportunity cost is simply the value of the optimal option minus the value of the chosen option. So the difference between what could have been the optimal option to pick and the option you did pick is the opportunity cost. So you need to minimize the opportunity cost, meaning you need to be working on the optimal things. 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? 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 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 you should try to minimize opportunity cost 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 in the work i did at pretty much every company. And again, i've been guilty of this myself where i think that, typically, the type of situation where i have seen this as an example is you are trying to prioritize the next quarter. 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 you could do that perhaps deep down, you know you should pursue them, but you don't end up picking them because again you're satisfying yourself by observing, oh, each of these is positive roi. Each of these five things that we can do that are very well defined as 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. But doing that requires more work to figure that out to flesh it out. But we convince ourselves that positive roi is great. 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 chasing that? When i started working on stripe connect, which is a 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 i 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 i had the instinct that this need is gonna grow 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. - just one more question along this line 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 the latter. I do not recommend trying to quantify opportunity costs 'cause it's a lost cause.

Instead, what teams need is just 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/20/10 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.

So i have found that approach very useful during planning where what i will say is, like, "look, yeah, we need to spend.". And 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. So what i'l 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 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 wanna go towards incrementals; 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'l share with the team. And then i will ask the teams to create their plans and proposals based on this sort of guidance. So this kind of gives people the space to 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 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. - i really like that rule of thumb, what an excellent nugget to include along with this big idea. I'm realizing we've got been going for an hour and a half now. And i don't wanna suck up all your time. So there's this idea that i think it might be a really good one to end on.

It'l be a bonus 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 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 trait 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 kind of this concept in my head for many years was 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.

And so high agency people will 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. 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 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. 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 like high agency was a big contributor, which is the pms in this first category were 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. 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 like 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 they 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 power of empowerment, basically taking responsibility, feeling high agency resiliency. Shreyas, this has been incredibly illuminating. I suspect this is gonna 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 wanna reach out or learn more? And then how can listeners be useful to you? -. Yeah, so follow me on twitter, i'm just @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 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. 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 to help me in my mission. - amazing. What a beautiful way to end it, shreyas. 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. - 10 big ideas by shreyas doshi coming up. I'm really excited about that, too. Thank you again. - great, bye. -. thank you so much for listening. If you found this valuable, you can subscribe to the show on apple podcasts, spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com.