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

Lenny (00:00:03):
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.

(00:00:48):
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.

(00:01:29):
This episode is brought to you by Coda. Coda is an all in one doc that combines the best 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, 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.

(00:02:23):
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/lenny to sign up and get a thousand dollars credit on your first statement. That's C-O-D-A.io/lenny to sign up and get $1 in credit on your account.

(00:02:49):
This episode is brought to you by Productboard. Product leaders trust Productboard to help their teams build products that 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 left too with an easy to view roadmap that automatically updates so everyone knows what you're building and why. Make data-driven product decisions that result in higher revenue and user adoption and empower your product teams to create delightful customer experiences. Visit productboard.com to learn more.

(00:03:42):
Shreyas, the man, the myth, the legend, thank you so much for joining me and for having this conversation.

Shreyas Doshi (00:03:48):
It's great to be here, Lenny.

Lenny (00:03:49):
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?

Shreyas Doshi (00:04:14):
Sounds great.

Lenny (00:04:15):
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, where were you born, where'd you grow up, what'd your parents do for work, what did you want to be when you grew up?

Shreyas Doshi (00:04:36):
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. And when he was short on staff, I used to be packaging the spices into the little box or creating some marketing material for him, not the creative part, but the grunt work. So I grew up in that environment where the lines between what was my dad's business and our personal lives were very blurred.

(00:05:32):
My mother just growing up as a homemaker, and so, my dad was largely 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 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, surprisingly good at it, and I was very passionate about it.

(00:06:10):
So for a while, I was thinking, "Oh, I'll 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 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.

Lenny (00:06:50):
How's your French these days?

Shreyas Doshi (00:06:51):
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.

Lenny (00:07:04):
So you said you studied computer engineering, that's what you moved to the US for, how did you move from that to product?

Shreyas Doshi (00:07:11):
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 going to drop out of the PhD program. And once I dropped out, this was like 2001, 2002 so the climate was very different, there were basically no jobs for tech people. Certainly there were no jobs for people who required a visa, which I did. So it was very difficult, but I ended up working as an engineer at a couple of startups and that started my career in tech. I was an engineer for about four or five years. And when I moved here to the San Francisco Bay Area, I got a little taste of product management.

(00:08:00):
So, I was part of this team that used to be Loudcloud, and they were acquired by a larger company EDS at that 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 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, helping them out. I also enjoyed thinking about creative ways to solve their needs and whatnot. So, that was my taste of product management.

(00:08:40):
For about a year, I was doing the product job without having the title and I was also the engineer. So I was in this great state where I'd figure out what needed to be built and I would just build it myself. So, that's how I started. And at some point during that one year, I realized that while I was a good engineer, I was perhaps a top 20% engineer. I realized that I would never be a great engineer, that I would never be a top 10% engineer because I saw those engineers, the fortune of working with them, and I just could tell that I couldn't be that. And I increasingly got interested in this product thing, so I said, "Okay, let's try out this product thing." And so, that's really what started my product career. And I think what I have to be really thankful and grateful for there is the people who gave me a chance to do the product work and there were many people involved. And so, I think without their support, it would've been much harder for me to become a product manager.

Lenny (00:09:34):
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 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, I wonder how often that happens of PMs moving into PM because they aren't going to make it as an engineer.

Shreyas Doshi (00:09:57):
I think it might be a common occurrence because engineering is a really great job, particularly on empowered teams, as an engineer, you can do a lot. You don't have to just 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, "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, "Tryout 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."

Lenny (00:10:44):
It's such a bonus to have that background as a PM. I wanted to go back, so you mentioned that you worked at Loudcloud. I had no idea. That was Marc Andreessen's second company, right?

Shreyas Doshi (00:10:53):
Yes. I joined that team. Again, this was a time when there were very scared jobs in the valley and I was interviewing with them for nine months or something like that, and they had just been acquired by EDS. So they split into two companies. One got acquired by EDS and the other became Opsware, which was the product company. And so, I joined the Loudcloud part of that organization.

Lenny (00:11:17):
Got it. Is there something that you took away from that company? Was Marc Andreessen still working there? And I think Ben Horowitz also.

Shreyas Doshi (00:11:24):
Yeah, they were still there, they were working on the Opsware side. Again, because even though I was hired as an engineer, the non-engineer task I was given was to manage a relationship with Opsware because the way that split worked is EDS would use Opswares data center automation technology, and my team was responsible for deploying and supporting that technology for EDS. And so, I was given this role of managing the vendor relationship and I have no idea. I'm in my early 20s, I have no idea how to manage vendor relationships, but I ended up doing that.

(00:11:59):
And as part of that, I got an opportunity to work with many folks over at Opsware, including folks on the leadership team there. And that was my first experience of what a really highly talented and energetic team looks like, both on the Opsware side, like I said, I worked with a number of people there, but also on the former Loudcloud side who were my team members. And that magic, a very high caliber team, people who 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.

Lenny (00:12:32):
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 stuck with you? You share a lot of this on Twitter, but if you just think about somebody took away from each of these companies or even the founders that ran these companies, what might those be?

Shreyas Doshi (00:12:53):
Yeah, let's do this rapid fire style because you know me, I could 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 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 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 first hand because I was working on the identity team at Yahoo. Google taught me the.

Lenny (00:13:33):
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, people on Flickr didn't want to log in with Yahoo, is that right?

Shreyas Doshi (00:13:42):
Yes. That's the story of every acquisition that are some raving fans of the service that are perhaps not entirely happy about their beloved service being acquired by a large company. 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 everybody who uses YouTube should have a Google account. So they went through a multi-year migration of accounts, 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.

Lenny (00:14:36):
Great advice. Okay. Sorry I cut you off. Google.

Shreyas Doshi (00:14:38):
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 really big. And I only actually realized that when I left Google and I started working with the other teams and these were all capable teams and I was struck by how many teams just limited the potential of what they could achieve. And I think Google helped people think big by default. And so, I think the six years I spent at Google really helped me understand that really well and just make it a normal part of how I operated. So that was really useful for me.

Lenny (00:15:18):
Is there an example at Google that some of you worked on that was like, "Holy shit. This was going to be big or let's think bigger about this"?

Shreyas Doshi (00:15:25):
Well, 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 unwritten rule of thumb that, hey, if it's not going to generate more than $100 million 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 $100 million. So why do that? 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 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.

(00:16:22):
And in order to do that, it had to sometimes just let go of these seemingly smaller opportunities. So that tendency to think about, well, yes, there is $10 million business here, but can we make it $100 million business? Or there is a $1 million business here, can we make it a $10 million business? What does it take to make it bigger is a habit, I think, that got 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 $100 million opportunity or $1 billion 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.

(00:17:21):
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, because Twitter had both. 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, despite now being a long time since the product was launched. And that core product differentiation combined with network effects has what enabled Twitter to 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.

(00:18:13):
And then at Stripe, I think the main thing I took away was that when you combine high energy sound judgment, low ego and small teams, you just get magic. And so, 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 my growth and thinking as a leader. And I can go on with the founders, because I know you had asked that question.

Lenny (00:18:45):
Let's do it.

Shreyas Doshi (00:18:46):
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 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 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.

Lenny (00:19:38):
Is there an example of that or a story of that happening that you think about?

Shreyas Doshi (00:19:42):
I forget the details and they're not that important anyway. But there was a time when we were discussing a potential acquisition and I was on the fence on that acquisition, it would be something that my team would acquire, Jack was in the room. And I remember we went through as is common in many 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? 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. And we talked about it as a proxy because we were talking about metrics and impact and integration and those sorts of things.

(00:20:40):
So I still remember that. I still remember him asking a simple question. 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.

Lenny (00:20:52):
That's a question that a lot of PMs would hear and be like, "Oh my God. 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. I think you were going to talk about Stripe too, right?

Shreyas Doshi (00:21:08):
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, 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, 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 truly innovative, etc., etc. And John would often make, again, these observations about, well, if we just talked about the product in this manner, that will likely resonate a lot more with customers.

(00:22:00):
And that got me thinking a lot about how I need to reframe my approach to basically separate the effort involved in 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 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 talking about values, I saw both of them just live the values that they wanted the company to replicate, especially as the company was scaling. 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.

Lenny (00:23:08):
It's just hearing you describe all these companies and all these founders that you've worked with, it's pretty incredible to set of experiences that you've had and 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 done in different ways. And so, it's a good segue to shifting to talk about the five big ideas. The first is around this concept of pre-mortems, this is something that stuck with me when you tweeted it. I think it was a couple years ago at this point and I see it come up occasionally in your tweets and amongst people chatting your super follower threads. And so, I also like that there's something you can actually implement and act on pretty quickly and see impact. And so, curious to hear your thoughts on this idea of pre-mortem just unpack this idea for folks.

Shreyas Doshi (00:23:58):
We're all familiar with a post-mortem or as they call it in the military, I think, after action reviews. So every company I've worked at, we've had some form of post-mortem when a launch had problems or an initiative did not go as planned or we suffered an unacceptable system downtime. Somebody would say, "Oh, we need to post-mortem that." And over the years, I really saw the effectiveness of a post-mortem. Some really great insights came out of a post-mortem about what went wrong and what we could have done better. And as I saw the effectiveness of a post-mortem, that's what made me wonder, why do we need to wait until after things go wrong? Because 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 an Harvard business review article written by Gary Cline.

(00:24:50):
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 projects' 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 post-mortem. You might still do a post-mortem to learn, but odds are very high that it is not going to be a bad post-mortem. 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.

(00:25:47):
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 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, big factor in why a pre-mortem works.

(00:26:40):
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 just surprised or skeptical like, how is it really going to work? And then we go through the pre-mortem meeting and there's a whole process that we can talk about. But as we complete the meeting, I ask everybody, so how did that go? And just everybody is smiling, even though we've spent say 30 minutes or an hour, just talking about terrible scenarios of things that could go wrong, but everybody's feeling a little lighter because its great catharsis for them. So that becomes really important.

(00:27:14):
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.

(00:27:51):
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 in the room that nobody is 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 that. And so, an elephant could be like, well, we are assuming that just because we launch this and do a bunch of PR that we'll get users, but are we sure we're going to get users? That's the elephant in the room that nobody is talking about that, again, this gives you that psychological safety to bring it up.

(00:28:28):
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.

Lenny (00:28:45):
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 this, that kind of stuff?

Shreyas Doshi (00:29:02):
And so, as I started doing pre-mortem, they got more and more popular at Stripe, other teams started doing them, and then afterwards I helped some startups 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, basically that's an entire 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 the engineering side of things. 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.

(00:30:07):
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 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.

(00:30:35):
For a smaller launch, I just like to do one meeting where everybody is present. And like I said, start with the prompt of, imagine this has failed. So as the 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 quarter doc where people start entering their own 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 share.

(00:31:11):
And the one other innovation I added as I did this often was also, after people shared, I ask people to pick the tiger that they find more scary, but that somebody else mentioned, so not their own tiger, but some other tiger that somebody else mentioned that they found more scary. So, that ends up being 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. Because 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 going to deal with it only to find nobody was thinking about it. So then I like to create a pre-mortem action plan and then share that with the team and keep myself as the leader accountable for actually making progress on it.

Lenny (00:32:04):
Having started doing this, have you noticed a less need for post-mortems, basically projects failing less than having less problems? What impact have you seen executing on this idea?

Shreyas Doshi (00:32:13):
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 that actually looked like in real life. But those likely would have resulted in a problematic situation afterwards. 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?" 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. Give us some more time and we'll come back, and we'll perhaps relaunch the feature, but in a better way."

(00:33:00):
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 going to cause. In fact, it is obvious to 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 pre-mortem is a very inexpensive way to see these things because all it is is one meeting followed by some work that the leader needs to do to prioritize, followed by some mitigating actions, which you would've 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.

Lenny (00:33:54):
I'm excited to see those template, I haven't seen yet. I don't know that you put one together, so that's awesome. And we'll link it in the notes of this episode. I want to move to our second big idea, which is about something you've called 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 that over to you to share what that's all about.

Shreyas Doshi (00:34:15):
Yes. And so, I'm going to share a short 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 really high performance environment. I was working on some important products and launches and I just had too much to do. And I looked back at that time and it was perhaps the most stressful time of my career, where I would long hours, etc. But even at the end of the day, I'd feel highly dissatisfied because my to-do list was endless and I wasn't able to make a dent on it, and I was also a little bit of a perfectionist, so I was like, "No, no, no, I need to do this well."

(00:35:02):
It was just constantly I would come home and talk to my wife and basically just complained to her about how I'm not able to make progress or as much progress as I want, then that was accompanied with 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 block post. Unfortunately, I can't even find that block post somewhere, but it had some ideas that I took and then created this LNO framework on myself, which is essentially that 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.

(00:35:56):
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 task, 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.1 X, those are neutral tasks. And then there are overhead tasks where, again, in terms of impact, you get back a lot less than you actually put in. And it turns out that 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 discovered some of these ideas.

(00:36:47):
And what I realized is that among the things in my to-do list that 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 going to 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 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. Classic example of an O task is say an expense report. Sounds silly, but I used to try to make my expense report really good.

(00:37:47):
And sometimes that made no sense like, "No, no, no. I need to do that." And again, this is the silliest example, but there are many examples. And something I realized is that the same type of activity can actually be either an L task or an N task or an O task. So what's an example? So say a classic PM task activity of filing a bug report. And so, many companies have these bug templates, etc., etc. 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 and you don't add 15 screenshots with annotations, instead, you just have one screenshot and you hit submit on the bug report.

(00:38:43):
So that shift. Usually for the same type of activity, we provide the same type of engagement. The last example I'll use to illustrate this is taking notes. It turns out even taking notes, taking notes synthesizing them, and then sharing them can actually be an L task, an N task or an O task, depending on what type of notes they are. So, after I understood this, previously, I would just send all notes. I tried to make them really good, which took a lot of time. But then I realized, well, this is a meeting where, yes, I need to send notes, but again, it's like, it's just standard stuff, I just need to quickly list out. People need to really know is the three action items that came out of the meetings who owns them, that's it.

(00:39:23):
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. 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, you want to get the language right, you want to be very clear on what the decision is, so there's no room for misinterpretation, so you don't backtrack afterwards or people say, "Well, but I thought we'd said this." That's a case where it's an L task. And 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.

Lenny (00:40:18):
Yeah. And that last piece is a really good segue to the next big idea around optics and the important optics.

(00:40:25):
This episode is brought to you by Sprigg. If you've been a member of my community for a while, you know my user fan and investor in Sprigg. Sprigg 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 Spriggs in product surveys to target specific users, start collecting insights and identify issues and opportunities related to activation, onboarding, engagement [inaudible 00:40:54]. Talk about a platform that pays for itself. But I'm perhaps most excited about Sprigg's newest launch, which extends the power of the platform pre-launch and makes it possible to test mockups and prototypes with your own users in minutes.

(00:41:06):
The testing interface is super slick and doesn't require any of the typical plugins that make testing with your own users an appealing. And with unlimited seats, you're able to invite anyone from your company to view and use insights generated by Sprigg. If you want to get started, head over to sprigg.com/lenny and mention that I sent.

(00:41:26):
But before we get to that, I wanted to have one follow-up question. What are some classic examples of high leverage tasks that PM should try to do more often and think about? What's in that bucket, generally? Even though you pointed out a lot of times they could be in any of the buckets, depending on how you execute them. Are there things that are just like, you should probably spend a lot of your time doing X, Y, Z?

Shreyas Doshi (00:41:43):
Yeah. So, 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 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. That's because we have all these things going on this month, but trust me, next month, we're going to have ample time and I'm going to just spend a whole week working on strategy." Well, the next month rolls around and it's the same thing, you've got other issues.

(00:42:38):
The reason we procrastinate on these tasks are, one, because we know that they're 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. 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, 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.

(00:43:46):
And perhaps, I don't know if we'll get along. I don't know if I can have that tough conversation. And so again, it's an L task, but I'll try to apply bandaids instead of just tackling it head on. So, 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. I fill up my day with N and O tasks.

(00:44:26):
And I keep reminding myself, "Yeah, you're just doing neutral and overhead tasks." Because then that just 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 appointed day I did my couple of days of placebo productivity tasks, and on that appointed day, when I'm slated to do an L task, I will actually go out and work from somewhere else, whether it's a coffee shop or a co-working space or some other space. And I find that change of place just forces a focus and a shift in mindset that helps me bang out that L task very quickly and do it really well.

Lenny (00:45:16):
That are some great advice. There's so many layers of advice in that answer. Your point about the high leverage tasks being the task that you know you 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 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.

Shreyas Doshi (00:45:40):
So wise. Yeah, pay attention to your fears because they're telling you something.

Lenny (00:45:44):
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. We can all share what they are impact, execution and optics. And when I saw this for the first time, I always come back to these three things, because it's so simple and so accurate. And so, I'm excited for you to unpack all this.

Shreyas Doshi (00:46:12):
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 on product teams and organizations in general. And so, 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 that there's a product review, say, where you as a PM are presenting to the CEO. And as you're presenting 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 in this case?" And you've thought about it, it's like you did not think about that issue, but that is a good reason why. 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.

(00:47:16):
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, "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. Again, good reasons. And needless to say the rest of the product review doesn't go as well. And after the product review, you wonder what happened. Maybe you ask your manager what happened and particularly you're wondering why couldn't the CEO see a very rational argument about why you can't do this at launch.

Lenny (00:47:57):
Never happened to me. Never happened.

Shreyas Doshi (00:47:58):
And so, it's 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 CEOs are the ones, or founders are the ones that are thinking about, what is the impact to our brand? And so the CEO is thinking at the impact level, you're thinking at the execution level, there is that mismatch.

(00:48:46):
We litigate the minutiae of whatever issue we are discussing, but we never really recognize that it's because we are 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. I was myself guilty of this as well earlier on in my career, time and again, I noticed that we can, again, keep litigating the specific issue without understanding that, "Oh no, there's actually just 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 very wide ranging impacts on just overall how an organization functions.

Lenny (00:49:59):
What's an example of optics? And when optics matters, when you might not be thinking about the importance of that? Just impacting that one a little bit.

Shreyas Doshi (00:50:06):
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. So 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 for feedback. Those are all really great things and they will enable greater impact and better execution for you.

(00:50:57):
The challenge with optics is that in certain organizations that balance gets thrown off, where optics sometimes becomes the goal where somehow implicitly the organization or its culture has indicated to it's people that as long as you do the optics well, you are going to be fine, you are going to be appreciated here, you're going to be rewarded here as long as you do the optics fine.

(00:51:22):
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 got to focus on this optics activity." So then, that becomes the goal and that can be really harmful.

Lenny (00:52:09):
So there's these three levels of product work. Do you have advice for, should I just default to one of these normally based on just 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?

Shreyas Doshi (00:52:23):
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 pointing fingers. It's like, 'Oh, you tend to be fixated on all these execution details and 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 can, as a team, decide what is most important given your context. I'll give you an example. For early stage teams, of course, they need to be thinking about the eventual impact, but what they should actually, I think, most early stage teams should actually optimize for execution. Assuming that they have come up with a reasonable hypothesis about what's going to win, their main emphasis 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.

(00:53:20):
So that's an example of a situation where let's be explicit, 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 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," and 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.

Lenny (00:54:21):
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 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 how you discovered that and what that means and maybe how to address those problems.

Shreyas Doshi (00:54:49):
And so, I realized this somewhat late in my career as a leader, most execution problems that I encounter in a high performing environment where everybody has the right intentions are actually not execution problems, they are either strategy problems or interpersonal problems or cultural problems. And so, just to illustrate it, I'll make the observation that 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 mentoring or coaching or people on my team, PMs or PM leaders were extremely busy and usually overwhelmed.

(00:55:36):
I noticed two things, that 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, it's a classic guacamole. And as I noticed that, and I'll share a concrete example of where this might happen, where an execution, a seemingly execution problem surfaces, so say two teams are misaligned. They need to work together where 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.

(00:56:32):
So as a leader or say, you are 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 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 going to do to solve this execution problem. We are going to create a new review process." And so, we are going to create this process and we are going to review priorities on a regular basis across these two teams. And then we are going to also as the managers of these individual teams to do regular one-on-ones so they can stay in sync. So this type of scenario is extremely common, again, especially in high growth organizations that want to accomplish a lot.

(00:57:19):
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 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 that is more often the cases, the reason we are misaligned is because 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.

(00:58:09):
This is all stuff that 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, are you going to work on this feature? I depend on this. Or can you swap two engineers from this team?" All of this stuff that PMs are very familiar with. You're talking about all the small stuff, but nobody recognizes that like, "Can we fix that?" 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?

(00:58:49):
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, because they were helping rightly for the sake of the company, they were helping this other team that team's manager is going to get his or her wrist lap at the next performance review.

(00:59:17):
So, that is a culture problem. Now, 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 going to 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 things and 50 other things, because they're not going to work anyway. So that's just one concrete example of team misalignment, which is often viewed as an execution problem, but is not an execution problem.

Lenny (01:00:10):
Are there signs that tell you where dates are slipping, people are surprised? 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?

Shreyas Doshi (01:00:23):
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 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. That's an execution problem. Another such example of what is really an execution problem is you have a skills' gap. You have say engineers who are not particularly skilled in a certain technology or a certain type of scale that happen to be working in that area, well that is going to create execution issues or you have a PM who is more of a zero to one person, but now you made them responsible for this scale mature initiative, so that's a skill gap and that can cause execution problems.

(01:01:18):
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 sure far way of identifying those is when you put on a bandaid and the bandaid falls. So, many organizations that are constantly just solving the same problem over and over again like, "Oh, we can never get along. We can never get these two teams to work together.

(01:01:49):
This team is always slow." And so you put the bandaid, but the bandaid doesn't work. So an 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, no, no, this is a bandaid we put, but the problem still exists. So it's probably not an execution issue. I

Lenny (01:02:15):
Love that visual of a bandaid falling off. Okay. So, this it's 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 an ROI perspective. And so, I'm excited to hear your take on this and where this idea came from.

Shreyas Doshi (01:02:47):
Yeah. I think I learned this by just observing Patrick at Stripe, particularly over the last couple of years that I was there. And then I 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 product management is good example of a high leverage role, founders by definition are in a high leverage role, engineering leaders, design leaders, designers, these are all fairly high leverage roles. And in a high leverage role, there will be hundreds of things that you can do that will provide a positive ROI. 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.

(01:03:48):
So, the problem is you should not be doing most of these things. And the reason this ROI mindset is suboptimal and perhaps even harmful in high leverage roles, the formula for ROIs 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. 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.

(01:04:36):
So you start working on the low hanging fruit. You start prioritizing the quick wins. And the quick wins are very popular. 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 costs now like, how do you calculate opportunity costs? 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.

(01:05:27):
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've never picked if we just had it 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 the basis of this statement that you should try to minimize opportunity costs and focus on those things rather than simply chasing positive ROI.

Lenny (01:06:09):
Is there an example that comes to mind when you did this or maybe did it the wrong way that helped inspire this idea? Or is this just more of a broad lesson that you've learned over time?

Shreyas Doshi (01:06:18):
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. 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. 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.

(01:07:11):
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 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.

(01:07:50):
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 it 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 over time of being able to 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 of shifting the mindset from just positive ROI to minimizing opportunity cost.

Lenny (01:08:35):
One more question along this line, just tactically, every PM ends up with a spreadsheet of their ideas and ROI and cost and benefit and all that stuff. Do you recommend folks create 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?

Shreyas Doshi (01:08:51):
Yeah, it's more the latter. I do not recommend trying to quantify opportunity costs because it's a lost cost. Instead, what teams need is just sometimes the freedom and sometimes just permission to explore and attack these things that minimize opportunity costs. 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 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 things like Gmail and whatnot, and 10% on other big bets.

(01:09:45):
So, I have found that approach very useful during planning. 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'll share as a guidance with the team is given our situation and given our strategy and given what's going on in the market, I would like us to target about 60% of our time on incrementals. And by that, I mean incremental features that improve users' lives on a day-to-day basis. So these are actually high ROI things that we do, and again, these numbers are whatever they are, pick whatever is right for you, but 60% I want to go towards incrementals. 30% I want to allocate towards big new initiatives.

(01:10:43):
And because it's 30%, it can't be five big new initiatives, it's probably one or two. And then 10% I'd like us to allocate towards stability and infrastructure. So this is the guidance I'll share with the team. And then I will ask the teams to create their plans and proposals based on this guidance. So, this gives people the space to say, "Okay, 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 the simple guidance enables the team to just do the right thing. And I often get surprised with all the awesome stuff they come back with.

Lenny (01:11:18):
I really like that rule of thumb, what an excellent nugget to include along with this big idea. I'm realizing we're going for an hour and a half now, and I don't want to suck up all your time. So there's this idea that I think it might be a really good one to end on. It'll be a bonus sixth big idea around high agency and the importance of 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 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 dive into this trade of high agency and how important that is for PMs.

Shreyas Doshi (01:11:55):
I think Eric Weinstein coined this term high agency, which once I discovered it resonated a lot and 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. 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 in 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. There's no dirt of problems to solve as a product manager.

(01:12:55):
And I noticed consistently over the years that as I started thinking about 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 their own capabilities on paper. You see somebody's credentials on paper and then you see their work and their impact. And there's a big difference between what you might assume on paper and the impact they're achieving. And also, the reverse of that, which is sometimes you have PMs who just have tremendous potential. They look great on paper and you know when you're working with them or you're managing them that they're not achieving that potential, they're nowhere close to achieving that potential. And as I look at both of those situations, it became clear to me that high agency was a big contributor, which is the PMs in this first category were despite all the disadvantages and other things, they just took strong ownership.

(01:13:56):
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 a creative execution is another aspect of high agency and they did that with a high degree of resilience, which is a third aspect of high agency. And so, as I realized that it became very clear as to why this was happening. And then it's one of those things that 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, again, it gave vocabulary to people for what they already understood and they had seen it, but did not have the words for.

Lenny (01:14:38):
I think that's a really good way to wrap this up, just leaving people at 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?

Shreyas Doshi (01:15:00):
Yeah. So follow me on Twitter and 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, etc. 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.

(01:15:36):
And in terms of other things I'm working on, I am going to be launching a course on product sense and product management later this year, so be on the lookout for that, if that's of interest. And then lastly, I think the best help I can ask for from listeners is just if any of these ideas resonated with you, share them with others. And of course, if there are questions, feel free to ask. But I think my mission here is to really help perhaps bring greater clarity on what is going on around us when we 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.

Lenny (01:16:22):
Amazing. What a beautiful way to end it. Shreyas, thank you so much for this conversation.

Shreyas Doshi (01:16:27):
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.

Lenny (01:16:35):
10 big ideas by Shreyas Doshi coming up. I'm really excited about that, too. Thank you again.

Shreyas Doshi (01:16:39):
Great. Bye.

Lenny (01:16:41):
That was awesome. Thank you for listening. If you enjoy 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.