The art of product management | Shreyas Doshi (Stripe, Twitter, Google, Yahoo)

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 there's no one out there today who shares more wisdom more consistently on the art of product management than triass doshi treyas 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 treos 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 trias 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 trials made the time for our chat and i cannot wait for you to hear it this episode is brought to you by coda code is an all-in-one doc that combines the best with documents spreadsheets and apps in one place i actually use coda every single day it's my home base for organizing my newsletter writing it's where i plan my content calendar capture

my research and write the first drafts of each and every post it's also where i curate my private knowledge repository for paid newsletter subscribers and it's also how i manage the workflow for this very podcast over the years i've seen code 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 coded dock gallery including resources for many guests on this podcast including shreyas gokul and shashir 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 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 dot io slash lenny to sign up and get a thousand dollar credit on your first statement that's c o d a dot io slash to sign up and get a thousand dollars in credit on your account this episode is brought to you by product board product leaders trust

product board to help their teams build products that matter from startups to industry titans over 6 000 companies rely on product board to get the right products to market faster including companies like zoom volkswagen uipath and vanguard product board can help you create a scalable transparent and standardized process so your pms understand what their customers really need and then prioritize the right features to build next stakeholders feel the love too with an easy to view roadmap that automatically updates so everyone knows what you're building and why make data driven product decisions that

result in higher revenue and user adoption and empower your product teams to create delightful customer experiences visit productboard.com to learn more treos the man the myth the legend thank you so much for joining me and for having this conversation it's great to be here lenny so we strategized about how to make this podcast as concretely useful and actionable for as many people as possible and so we decided to do 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 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 you start there like 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 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 uh

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 i used to 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 you know 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'll be like maybe teach french after i 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 uh you know 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 all

while backtracking so i completed my undergrad in india came here to the united states to pursue a phd in computer science about one month in i realized that phd in academia wasn't for me so i decided that i was going to drop out of the phd program and once i dropped out this was like 2001 2002 so the climate was very different there were basically no jobs for tech people certainly there were no jobs for people who required a visa which i did so it was very difficult but i ended up

working as an engineer at a couple of startups and that started my career in tech i was an engineer for about four or five years and when i moved here to the san francisco bay area i got a little taste of product management so i was part of this team that used to be loud cloud 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 over the

time would kind of send me to customer meetings if we had an internal product so these were internal customers and i thought it was a little surprising because i was friendly 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 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 i was in for a year for about a year i was kind of doing the product job without having the title and i was also the

engineer so i was in this great state where i'd figure out what needed to build to be built and i would just build it myself and so 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 percent engineer i realized that i would never be a great engineer that i would never be a top 10 percent engineer because i saw those engineers at the fortune of working with them and i just could tell that i couldn't be that and i increasingly got interested in

this product thing so i said okay let's try out this product thing and so that's really what uh started my product career and i think what i have to be really thankful and grateful for there is the people who gave me a chance to do the product work and there were many people involved and so i think without their support it would have been much harder for me to become a product manager i didn't know that you moved from engineering to product and your journey is very similar to mine where i was also an engineer and i once i got to airbnb i was like okay i am not

good and i will not last as an engineer at a company like this and i should think about what other options exist and it worked out great and so that's i wonder how often that happens of pm's moving into pm because they aren't going to make it as an engineer yeah i think it might be a common occurrence because um you know engineering is a really great job and like particularly on empowered teams as an engineer you can do a lot you can 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 the part about building software because sometimes people will ask me like hey i'm doing this technical degree whether it's computer science or something else but i want i want my first job to be product management and i often respond with well try out engineering because in again in many companies fortunately these days you can do a lot more than just you know the core engineering job and so you get exposure to many different things and once you do

that you can decide what path to pick it's such a bonus to have that background as a pm i wanted to go back to some you mentioned that you worked at loud cloud i had no idea that was mark 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 loud cloud part of that organization got it is there something that you took away from that company like was mark andreessen still working there and i think ben horowitz also yeah they were still there they were working on the opsware side it turned out again because even though i was hired as an engineer the first task i was given the non-engineer task i was given was to manage 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 20s i have no idea how to manage vendor relationships but i ended up doing that and as part of that i got an opportunity to work with many folks over at opsware including folks on the leadership team there and 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 lauter outside who were my team members and that magic of you know 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're you worked at a bunch of really important well-run successful companies stripe twitter google yahoo what's one thing you took away from each of these companies that you've worked at that has kind of stuck with

you and you share a lot of this on twitter but if you just think about like someone i took away from each of these companies or even the founders that ran these companies what what what might those be yeah let's do this rapid fire style because you know me i could like spend an hour just talking about this topic but just starting with yahoo i think i learned the importance of building multiple services under a single account i think that was you know the one yahoo id was such a powerful thing it wasn't easy to pull off back in the

day and yahoo was perhaps the first company that kind of like pulled it off really well and and so that idea of bundling under a single account which then google really did extremely well later on was was something that i got to experience very firsthand because i was working on the identity team at yahoo real real quick on yeah because it makes me think about it i remember they tried to do that with flickr and they had a bunch of trouble with that right people on flickr didn't want to log in with yahoo is that right yes that's the story of every

acquisition 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 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 this they had similar backlash the interesting part though is nobody remembers that now right like people happily use youtube so uh these this is one of those things where sometimes it's painful in the short term even though it might actually be the right answer over the long term great advice okay sorry cut you off google yes google i think the main thing i learned was the power of thinking really big and i know it sounds very sounds like a platitude but like really

big and i only actually realized that when i left google and i started working with other teams and these were all capable teams and i was struck by how many teams kind of just limited the potential of what they could achieve and i think google [Music] helped people sort of think big by default and so i think my the six years i spent at google really kind of helped me understand that really well and just make it a normal part of how i operated

so that was really useful for me is there an example that i googled that some you worked on that was like holy this was gonna be big or let's think bigger about this yeah well as with anything right like there's pluses and minuses so i worked on the ads team at google for a number of years and there was this kind of unwritten kind of rule of thumb that hey if it's not going to generate more than 100 million dollars in revenue it's not worth talking about it right because the ads business was growing so fast and was so large that

like we would regularly not pursue opportunities that were just quote a hundred million dollars so why do that right that's because google had access to billion dollar opportunities for its ass business so they were very clear on pursuing the big opportunities and in some cases these opportunities were not obvious so we kind of had to create those opportunities if you think about some of the innovations google brought over the years in monetization including things like video ads and whatnot right like those were not

obvious opportunities but google decided that it wanted to pursue those big opportunities and in order to do that it had to sometimes just let go of these seemingly smaller opportunities so that tendency to kind of think about well yes there is a 10 million dollar business here but like can we make it a 100 million dollar business or there is a one million dollar business here can we make it a 10 million dollar business what does it take to make it bigger is a habit i think that got kind of ingrained for me at google now of course there's the other side of

it which is i think google missed out on some trends simply because of this filter or this high bar where sometimes it's not clear if something is a 100 million dollar opportunity or a billion uh dollar opportunity and so so that is a downside of this what i mainly took away is for instance even at stripe when i joined i was just thinking a lot bigger about the business i was responsible for stripe connect and that helped us make different decisions

about what to prioritize and at what pace to go after it so that was google um moving on to twitter i think in twitter the main thing that struck me with all the challenges they had infrastructure challenges and also some challenges around leadership and culture is just a stickiness that comes with combining network effects with core product differentiation right so because twitter had both like we talk about network effects all the time and i don't have much more interesting

things to add beyond what's already added but this combination of code product differentiation because if think about it there's still no product like twitter right despite it now being a long time since the product was launched uh and that core product differentiation combined with network effects has what enabled twitter to kind of you know 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 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 um that when you combine high energy sound judgment low ego and small teams you just get magic and so i i just you know 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 because i know you had asked that question so 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 i particularly if i were to pick one thing i really appreciated larry's strategic insight and particularly his ability to simulate the future to make better decisions twitter i just overlapped very briefly

with jack's comeback as ceo back 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 you know he 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 that or a story of that that happening that you

think yeah i think you know i forget the details and they're not that important anyway but like there was a time when we were discussing a potential acquisition and i was on the fence on that acquisition it would be something that my team would acquire jack was in the room and i remember we went through as is common in many corporate settings we went through you know all the pros and cons and all the intellectual arguments and the strategic arguments and the metrics arguments and all of that and jack was just listening through all of that and then i remember very

distinctly he asked me one question which was something to the effect of how does this make our users love twitter more right like a simple question but then at that point i realized yeah we never really talked about that because we were so engrossed in all the other stuff right and we talked about it as a proxy because we're talking about metrics and impact and integration and those 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 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 try 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 and as a lesson of how to approach this kind of stuff so i love that and oh yeah i think you were going to talk about stripe too right yes stripe i worked a lot with patrick and john john

was my manager for a while and from john i learned a lot about marketing john is a master marketer among many other things that he's absolutely great at he's just a great marketer and i just learned a lot about how to think about talking about the product in terms that you know again obvious stuff but talking about product in terms that customers really understand and then sometimes emphasizing things that we as product people might not think are really important because maybe we didn't spend much time on building it

and we want to talk about things that we spent a lot of time that are sort of truly innovative etc etc and john would often make these again these kind of observations about well if we just talked about the product in this manner that will likely resonate a lot more with customers and you know 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 that doesn't have to be the same features that you talk about so

so that's something i learned a lot uh working with john from patrick i think you know 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 i'm curious to kind of hear your thoughts on this idea of pre-mortems just unpack this idea for folks yeah we're all familiar with a postmortem or as they call it in the military i think after action reviews right so every company i worked at we've had some form of postmortem when a launch had problems or an initiative did not go as planned or we suffered an unacceptable system downtime

somebody would say oh we need to postmortem that and over the years i really saw the effectiveness of a postmortem right some really great insights came out of a postmodern about what went wrong and what we could have done better and as i saw the effectiveness of a postmodern that's what made me wonder why do we need to wait until after things go wrong because like why can't we extract these some of these insights before they go wrong so 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 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-modern is that if you do a pre-mortem right you will not have to do an ugly postmodern you might still do a postmodern 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 right like the initial prompt is the genius which is the prompt starts with imagine this project that we are working on has failed six months from now or this launch we are doing has miserably failed let's just all imagine that now let's work backwards from there and ask ourselves what went wrong what could have contributed to this utter failure and that's how a pre-mortem meeting will

start the the leader will start with this prompt and then the way the meeting goes is you ask your team members to share what could have caused this utter failure and the magic of this type of approach where you kind of like work backwards from a failed outcome a hypothetical failed outcome is that it just somehow enables two things one is much greater psychological safety for team members to talk about things they're concerned about but that they were just hesitant

to bring up because nobody likes to be negative in modern organizations right everybody wants to be optimistic and positive so a premortem setting gives everybody the license to actually think about what can go wrong so that psychological safety is a big big factor in why a premortem works and what i've found is in you know at stripe i did this regularly with launches that my team was involved in sometimes you know some teams or some people were like just surprised or skeptical like how is it really going to work

and then we go through the pre-mortar meeting and there's a whole process that we can talk about but like as we you know complete the meeting i ask everybody so how did that go and just everybody's smiling even though we've spent say you know 30 minutes or an hour just talking about terrible scenarios of things that could go wrong but everybody's feeling a little lighter right because it's great catharsis for them so that becomes really important and the last kind of thing i found with premortems now that

i've done them with you know various other companies as well that i advise and whatnot is the shared vocabulary and the shared vocabulary that you get about being able to talk about things that will fail so i have a specific approach which is i asked the team to talk about three things each member on the team should bring up three things one is a tiger so you can bring up tigers in the shared dock that we create and a tiger is a threat that will actually kill us just like a tiger would so these are like actual problematic things that could be really harmful to

the product of the project so that's a tiger the other is paper tiger so this is a seeming threat that others might be worried about but you're not worried about so that's the paper tiger and then the last one and i think this one was also used at airbnb in other ways is elephant and the elephant is the elephant in the room that nobody's talking about so it might not be a tiger it won't kill us but you're still worried that we are not kind of like seeing reality as it is 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 right like that's kind of like the elephant in the room that nobody's talking about that like again this gives you that psychological safety to bring it up and then what i noticed as i ran 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 so and it's interesting that people don't don't often do this or haven't even thought about doing this and so just to get a little bit deeper how would you 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 of also do premortems and at some point i decided i should just like write down my template for pre

modems so i worked with the folks at coda to create a coder doc which you can find and we can put in the show notes if possible yeah basically that's an entire kind of template for how to run free modems using this method that i talked about including tigers paper tigers elephants all of that the main thing about a premortem is to include people from every function that is going to be involved in say if you're doing a launch and so if it's a really large launch sometimes i will separate it into two groups one is everything related to kind of like the

engineering side of things where you can kind of bring in usually the engineering team is fairly large so you can bring in every engineer so that's really important every engineer needs to be in the meeting and so it might be a meeting of 10 15 20 whatever engineers and maybe a pm maybe a design counterpart and so on that's just focused on the product engineering side of things like what could go wrong and then again for a large launch i like doing a separate pre-mortem for the go-to-market side and so that will involve sales teams

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'll talk about more of the go-to-market risks so that's what i like to do for a very large launch for a smaller launch i just like to do one meeting where everybody is present and like i said start with the prompt of imagine this has failed so as the 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 koda dock where people start entering their own kind of tigers and paper tigers and elephants in a way that nobody else sees and so people do that and then we go around the room and kind of share and the one other innovation i added as i did this often was i also after people shared i asked people to pick the tiger that they find more scary but 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 a sort of uh you know people basically are voting and then as the pre-mortem leader it's my responsibility to take all of that like output that the team has generated in this document and then prioritize because again the point is not to solve every problem right the point is to identify threats that we are not talking about openly or that we might just be missing or we might be assuming that somebody else is going to deal with it only to find

nobody was thinking about it 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 uh less need for postmortems basically projects failing less than 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 know you can't really run a simulation and see what the counterfactual look like in real life but those likely would have resulted in

a problematic situation afterwards like you know a great example is sometimes you'll see a company announce something and they have massive backlash and then you know a reasonable observer might say well how did this company miss this right because what happens is they have the backlash then the company realizes oh we have this backlash then they start doing damage control they sometimes might even backtrack and undo whatever they did they'll say sorry we didn't think about these issues like give us some more time and we'll kind of

come back and we'll perhaps relaunch the feature but in a better way right uh to the the casual observer like it may seem like that it should have been obvious and sometimes it's not but oftentimes i agree it should be obvious to these teams what issues these things are going to cause in fact it is obvious to team members some team members but the problem is that they perhaps haven't created that psychological safety and that vocabulary to be able to talk about it in an objective way and to decide with intent are we going

to solve for this or not so i do see a lot of those scenarios in our industry which end up just actually wasting a lot of time whereas a pre-modern is like a very sort of inexpensive way to see these things because all it is is one meeting followed by some work that the leader needs to do to prioritize followed by some mitigating actions which you would have had to take anyway so that's why i'm a huge fan of premortems is 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 don't know that you put one together so that's awesome and yeah we'll link it in the in the notes of this episode i want to move to our second big idea which is about something you've called the lno framework which is all around prioritizing your finite time as a as a pm and as a team and so i'll just kind of turn it over to you to share what that's all about yes and so i'm going to share a short kind of personal anecdote related to the lno framework which is that when i just joined google as a relatively new pm this is back in 2008

for the first three years i was overwhelmed and stressed and that was because one i was a new pm in this like really high performance environment i was working on some important products and launches and i just had too much to do and i looked back at that time and it was perhaps the most stressful time of my career i would you know work 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 you know i was also a little bit of a perfectionist so i was like no no i need to do this well and yeah i was just constantly i would come home and talk to my wife and kind of basically just complain to her about how i'm not able to make progress or as much progress as i want you know when that was accompanied with like you know not being able to sleep very well because i was concerned about how much output i was producing and what not 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 and i can't 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 lab high leverage role all your tasks are not created equal there are actually three type of tasks that you end up doing in such a role so there are l tasks which are leverage tasks and the l tasks

are such that when you put in a certain amount of effort you get 10x or 100x in return in terms of impact so those are l task leverage tasks then there are neutral tasks so that's n and those are tasks where you 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 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 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 going to get so much more in return right it makes sense for me to spend that time on that prd for instance related to an important feature that will meaningfully impact our revenue right i'm going to spend more time on that than i ordinarily would so now where does that more time come from because it cannot come from just working more hours well it comes from spending less time on end tasks and all

tasks and so there are some tasks that you do a classic example of an o task is say an expense report right like it sounds silly but i used to try to make my expense reports really good wow and and sometimes like you know that made no sense right like but i was like no no i need to do that and again this is the silliest example but there are many examples and something i realized is that the same type of activity can actually be either an l task or an end task or an o task so what's an example so say like a classic pm activity of

filing a bug report right and so many companies have these bug templates etc etc right like that you use to file a bug report well it turns out that filing a bug report depending on the situation depending on what type of bug it is can actually be an l task high leverage task and over there you want to file a very detailed explicit bug report and in other cases might actually be an o task where you don't fill 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 so that shift where usually for the same type of activity we we provide the same type of engagement one 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 end task or an o task depending on what type of notes they are so if it's like you know after i understood this previously i would just send all notes like i 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 uh you know again it's like 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 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 items right i'm not going to try to make my notes look great so that others can appreciate austras always

sends great notes on the other hand if it was a product review with the ceo about a very contentious topic that you have gone back and forth multiple times and now you made a decision about something you want to perfect those notes before you send them out right like you want to get the language right you want to be very clear on what the decision is so there's no room for misinterpretation so you don't backtrack afterwards or people say well but i thought we said this or so that's in 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 the 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 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-spray 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

sprig's 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 sprig'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 the testing interface is super slick and doesn't require any of the typical plugins that make testing with your own users unappealing and with unlimited

scenes you're able to invite anyone from your company to view and use insights generated by spring 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 other things that are just like you should probably spend a

lot of your time doing xyz yeah so it turns out that the l tasks pm's 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 are not doing them as well as they know they should so the classic classic example of this is the case where a pm will say i know i need to work on getting our strategy right but i don't have time because i'm busy firefighting

i'm busy you know 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 yeah that's because we have all these things going on this month but trust me next month we're gonna have ample time and i'm gonna just spend a whole week working on strategy well the next month rolls around and it's the same thing you've got other issues the reason we procrastinate on these tasks are one because we know that they're real tasks we know the impact they'll have

and we're a little scared that's one the second is they require dedicated attention and again we are afraid about whether we'll have anything interesting to say right like that's the that's the deep fear why many people procrastinate on strategy because deep down they just they don't know if they can formulate a good strategy so so time becomes a convenient excuse for us where we say well it's not me it's just i don't have time to work on it so and by the way everything i say here like

i have been that person so i have been that person who's procrastinated on an l task whether it's the strategy or whether it's writing the prd for this really difficult feature or it is working on aligning two teams where you know that alignment would create a lot of impact but it's hard it's an l task but i don't do it because i don't want to deal with this other person this manager i'll have to collaborate with

to make it happen and perhaps you know i don't know if we'll get along i don't know if i can have that tough conversation right and so again it's an l task but i'll try to apply band-aids instead of like just tackling it head-on and so so yeah this is tough stuff right like and what i found useful there is two things two tactics make a huge difference in helping us target l tasks better one is the idea of placebo productivity so what i do is before i have to tackle an l task the couple of days leading up to it

i do all these placebo productivity tasks basically i intentionally do end tasks and oh tasks right just i fill up my day with nno tasks and i keep reminding myself yeah you're just doing neutral and overhead tasks because then that kind of just like tricks me into thinking okay if i've been doing this placebo productivity task for the last two days now it's the right time for me to do this l task so that's one tactic the other is change of location nothing for me at least fights my procrastination for l tasks better than changing the place from which i'm

working so if i normally work from this desk the day the appointed day i did my couple of days of placebo productivity tasks and on that appointed day when i'm slated to do an l task i will actually go out and work from somewhere else whether it's a coffee shop or a co-working space or some other space and i find that like 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 in that answer

it your point about the the leverage high leverage tasks being the tasks that you know you kind of should do but don't want to do makes me think of a quote that i always come back to that the cave you fear contains the treasure that you seek and i often find that to be true and it's kind of this reminder to just wherever the compass is pointing where it's most difficult it's probably where the biggest opportunity lies and so that's a really good reminder of all that that's so wise yeah pay attention to your fears because they're telling you something

speaking of fears our third big idea is around the three levels of product work basically the three things that a pm should be focused on and how often when you're not aligned on what is most important to you and your team it often leads to conflict and so i'm excited for you to unpack this idea of these three levels of product work and i'll share what they are impact execution and optics and i whenever when i saw this for the first time i always come back to this these three things because it's so simple and

so accurate and so i'm excited for you to unpack all this yeah the this this idea that there are three levels of product work impact execution and optics once you understand it it explains a lot of what you see in on product teams and organizations in general and so i'll perhaps start with a an example that most product people product leaders and founders are used to seeing which is and something i've seen dozens of times in my career 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 going to be some compromises that you're taking so you know the ceo perhaps asks about okay well why is our customer service response time going to be so high in this case uh and so and you've thought about it right like it's not like you did not think about that issue but there is a good reason why right like you talk to the vp of customer support and they don't have the funding this quarter to support your product fully which will then result in a poor customer service

experience for this kind of new product that you're launching but then you've agreed you've used your skills of influence to agree that okay next quarter they're going to allocate a lot more people to your product so that you know the customer service experience will get better next quarter and so the ceo asks like why like why is the customer service experience going to be poor here or they make a remark like that and then you reply with all these good reasons like quote again good reasons and you know needless to say the rest of the product review doesn't go as well and

you know like after the product review you wonder what happened maybe you ask your manager like you know what happened and particularly you're wondering like why couldn't the ceo see your very rational argument about why you can't do this at lunch right like never happens to me yeah and so it's kind of like why doesn't like why doesn't he or she see that right and the reason is that you are thinking at different levels right like so you as a pm perhaps are fixated as you are dealing with this launch or this

project you are fixated on the execution level which is what does it take to get something done and how can i do it how can i hit the next milestone those are all the things we are tend to think about when we are thinking at the execution level the ceo on the other hand is approaching it from the impact level and particularly perhaps in this case what is the impact to the customer experience and often like ceos are the ones the founders are the ones that are thinking about what is the impact to our brand right and

and so the ceo is thinking at the impact level you're thinking at the execution level there is that mismatch we litigate the minutiae of whatever issue we are discussing but we never really recognize that it's because we are kind of default thinking at different levels and so this realization helped me better understand why there were conflicts between you know two very smart and well-intentioned people or groups within a company

and and time and again i noticed that and i was myself guilty of this as well earlier on in my career like time and again i noticed that we can again keep litigating the the specific issue without understanding that oh no there's actually a 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 so that observation helped explain a lot of things including

you know what kind of people an organization will promote right like does it promote people who default operate at the impact level does it promote people who more who default operate at the execution level or at the optics level right so it has like very wide ranging impacts on just like overall how how an organization functions what's an example of of optics and when optics matters when you might not be thinking about the importance of that just unpacking that one a little bit yes so optics is about creating awareness

of the impact and the execution that you're doing or your team is doing that is the most compact definition i can come up with for optics and optics is a good thing right so like i'm not saying don't think about optics whatsoever i think it's actually important to think about optics and now i'm talking about just internal optics external optics is an entirely different thing and that's like marketing pr and that's definitely highly important but even when we talk about simply we limit scope to internal

optics i'll make the observation that you should be spending some time on internal optics because it creates energy it creates awareness it creates excitement it creates opportunities for feedback those are all really great things and they will enable greater impact and better execution for you the challenge is the challenge with optics is that in certain organizations that balance gets thrown off right where optics sometimes becomes the golf right where somehow implicitly the organization or

its culture has indicated to its people that as long as you do the optics well you are going to be fine you are going to be appreciated here you're going to be rewarded here as long as you do the optics fine and 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

right do you appreciate a launch do you appreciate results do you appreciate an i don't know an awesome status update that somebody sent so a status update doesn't on its own accomplish anything i mean they are important but a status update is an optics activity now it is a necessary optics activity but if you start appreciating the necessary optics activities constantly the signal you are sending to people is oh you got to focus on this optics activity right so then the 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 is that the more important takeaway yes i think that's the more important takeaway is again it's about now we have a vocabulary that we can talk about in an objective manner without kind of pointing fingers it's like oh you tend to be you know fixated on all these execution details and like

that's not the right thing that's the type of feedback sometimes that gets shared so so now you have vocabulary to talk about this and once you have that you sort of can as a team decide what is most important given your context i'll give you an example like for early stage teams yeah of course they need to be thinking about the eventual impact right but what they should actually i think most early stage teams should actually optimize for execution right assuming that they have come up with a reasonable hypothesis about what's

going to win their main emphasis net needs to be on execution because you will not see impact readily on a one week horizon or a one month horizon or perhaps even on a quarterly horizon so that's an example of a situation where let's be explicit right like we need to get great at execution we have a set of core insights that were informed by our desire to make an impact but now that we are like responsible for converting these insights into a product let's be

largely operating at the execution level as an example say there is a platform team and that platform team has had some issues lately with availability that has disrupted some other teams within the company and their products perhaps that platform team should have a conversation that you know what yes we need to focus on impact obviously to kind of you know avoid this negative impact but also let's let's pay some more attention to optics because we haven't been communicating with teams as much teams that rely on us right so let's let's create a better

communication channel with them let's create better status updates for them or what what not so again the point is not so much like oh you should just this is the right level and all other levels are wrong it's about being sensitive to what's right in this situation so you talked about execution and how maybe for early stage startups that might be default the most important type of work to be focused on and that's actually a really good lead way to our fourth big idea which is kind of a provocative tweet that you put out a while ago that you said their 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 and maybe how to address those problems yeah and so i realized this somewhat late in my career as a leader that yeah most execution problems that i encounter in a high performing environment where everybody has the right intentions are actually not execution problems they are either strategy problems or interpersonal problems or cultural

problems and so just to illustrate it i'll make the observation that you know many leaders are extremely busy in such environments whether it's a fast growth startup or a fast growth larger company they're extremely busy they're usually overwhelmed like i said earlier i was one of those people and you when you take a deeper look at what they're engaged in and i got a chance to look at it you know with my peers that i was kind of mentoring or coaching or people on my team you know pms or pm leaders who were like extremely busy

and usually overwhelmed i noticed two things they that like what made them busy is two things one is that somehow the organization had imposed very high optics requirements so they had to do a lot of optics-related work show up at certain status meetings and blah blah blah so we talked about that so let's leave that aside but the other reason they're so overwhelmed is that they're constantly solving execution problems so they solve the most important ones the new ones come up and they solve those and then there are two new ones to solve and on and on right like it's a classic vacuum hole

and as i noticed that and i'll share a concrete example of where this might happen right where an execution a seemingly execution problem surfaces so say two teams are misaligned right there's lack of they need to work together but they're misaligned everybody knows it and that is affecting our execution that misalignment is affecting our execution it's affecting our ability to hit rokrs 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 beatings to figure out what's going on you try to diagnose the issue how to better align and then you talk to you know 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 so we're going to create this process and we're going to review priorities on a regular basis across these two teams and and then we're going to also as the managers of these individual teams to do

regular one-on-ones so they can stay in sync right like and and like so this type of scenario is extremely common again especially in high growth organizations that want to accomplish a lot you'll come up with this solution after many meetings and a lot of work a lot of conversation and so as i 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 it 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 cases the reason we are misaligned is because we don't know what the strategy is right so so we don't know what the strategy is we craft some okrs based on what makes sense the okrs are not very well aligned we don't have a sense of priorities and we also don't have a sense of what we do when reality changes this is all

stuff that a strategy a clear correct strategy should help inform but actually like this lack of strategy is what's causing this misalignment it's not because they'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 can you swap to engineers from this team like 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 this like can we fix that right so as as i started seeing this

like you know 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 right in a culture like that it becomes really hard to allow two teams to work better together because if one of the teams doesn't hit their okrs because they were helping rightly for

the sake of the company they were helping this other team that team's manager is gonna get his or her wrist lap at the next performance review right so that is a culture problem now yeah you can set up the meeting and you can request all the sinks you want between these people it's not going to solve the culture problem the execution problem is going to manifest in different ways right a month down the road so that's like an example of a culture problem or it could be an interpersonal problem right and this is actually quite common it's simply that these two people cannot

get along the two team managers do not get along right and they just constantly might be creating friction right and so as a leader it is important for you to spot that right and then coach them through their differences coach one or both of them through that so that they can better work together when you solve that you won't need that monthly review meeting and all these things and 50 other things because they're not going to work anyway so that's just one concrete example of like team misalignment which is often

viewed as an execution problem isn't but is not an execution problem are there signs that tell you okay we're like our dates are slipping people are surprised like of execution problems you have like are there signs that maybe it's one of these other factors or is your experience like it's almost always one of these other things so there are some problems that are truly execution problems so an example of that is say you have infrastructure issues right like your infrastructure is just like old and it cannot can no longer

sustain all the usage that you're getting that will cause execution problems where you'll move slower or you will have outages or high latencies or whatever the case is yeah that's an execution problem another such example of what is really an execution problem is you have a skills gap you know you have say engineers who are not particularly skilled in a certain technology or a certain type of scale that happen to be working in that area well that is going to create execution issues

right or you have a pm who is more of a zero to one person but now you made them responsible for this like scale mature initiative so that's a skill gap and that can cause execution problems right so there are very concrete instances where there is a real execution problem it's just that in high performing organizations that are growing really fast we we ignore the other factors that might be at play right and so now what tells me if something isn't seemingly an execution problem but not actually an

execution problem a surefire way of identifying those is when you put on a band-aid and the band-aid falls so like the many organizations that are constantly just solving the same problem over and over again right like oh we can never get along like we can never like get these two teams to work together right like or like this team is always slow right and so you put the band-aid but the band-aid doesn't work and organizational memories tend to be surprisingly short so we forget uh you know oh three months ago we put this band-aid and it's no longer

working we just approached it as oh let's create a new solution so voila there's a new meeting right and so that's where that honesty is important and memory is important that no no this is a band-aid we put but the problem still exists so it's probably not an execution issue i love that visual of a band-aid falling off that's we've all seen that it's like it's like way 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 roi perspective and so i'm excited to hear your take on this and where this idea came from yeah i think i 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 in this tweet which is when you are in a high leverage role

you should stop doing work that simply that simply provides a positive return on investment roi and you should start focusing on work that minimizes opportunity cost and what drives that is the observation that in a high leverage role so like product management is a good example of a high leverage role you know 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 right and what is positive roi it's simply that the value created is greater than the value of your time right that essentially will ensure positive roi right more than zero so the problem is you should not be doing most of these things and the reason this kind of roi mindset is sub-optimal and perhaps even harmful in high leverage roles is you know the the formula for roi is value created minus cost of your time divided by the cost of your time so the cost of your time is in the denominator

right and just for the sake of simplicity let's just call it time time taken right so when the time taken to do something is in the denominator and whether it's at an individual level or at a team level what we end up doing to get high roi on our work is we end up trying to decrease the denominator so you know when it's a ratio and you increase decrease the denominator the the value of the ratio grows right and so so how do you decrease the denominator in this case

where time is the denominator is you start working on things that take less time right so so you start like working on the low hanging fruit you start prioritizing the quick wins right and the quick wins are very popular right like any team meeting or sprint meeting oh that's a quick one yeah let's do it right and i don't have anything against quick wins the problem is we just fill up our plate with quick wins and while that may be fine in most cases in most situations in high leverage roles

you miss the upside and you miss the opportunity that you could have gained by focusing on other things right like let's take opportunity cost now what is the like how do you calculate opportunity cost opportunity cost is simply the value of the optimal option minus the value of the chosen option right so the difference between what could have been the optimal option to pick and the option you did pick is the opportunity cost right so you need to minimize the opportunity cost meaning you need to be working on the optimal things right so when we reprogram ourselves to

think in terms of opportunity cost we are no longer thinking oh is this a good use of my time right instead you are thinking is this the best use of my time and it's a subtle but profound shift in our thinking because when we think about opportunity cost we will pick certain things that we would have never picked if we just had the roi mindset and again this applies equally at the level of individuals of the work we decide to do as individuals on a day-to-day basis and the work we do with our teams the things we prioritize so that's sort of the basis of this

statement that like you should try to minimize opportunity cost and focus on those things rather than simply chasing positive roi is there an example that that comes to mind of when you did this or maybe did it the wrong way that kind of helped inspire this idea or is this just kind of more of a broad lesson that you've learned over time oh i mean i i saw that all the time in [Music] the work i did at pretty much every company and again i've been guilty of this myself where i think typically

you know the the type of situation where i have seen this as an example is you are trying to prioritize the next quarter right there are five sure things you can do that will have a 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 it's you're you're satisfying yourself by

observing oh each of these is positive roi right each of these five things that we can do that are very well defined is positive roi and so you don't touch those two things now it could be that one or those things could meaningfully change the trajectory of your business right and cannot but doing that requires more work to figure that out to flesh it out but we convince ourselves that positive roi is great right and so we make ourselves busy and

this is what i have seen myself do i've seen other teams do and certainly like when i sit down with pms often or even founders i find that there is this gravitation towards these types of tasks which are simply providing positive roi so it shows up most often in our planning essentially and again i'm not against things that are quick wins or things that provide positive roi but i always want to check what are some big opportunities that we are not paying attention to by default and under what scenarios can we start

chasing that when i started working on stripe connect which is a major major product for stripe and a large business for stripe there was a time when i noticed when i just started working on it i noticed the team was working on a lot of positive roi things and i came in and kind of like just simply instigated that like hey how about we work on this this big scary project because i was hearing from customers that there is some need and that at the instinct that this need is going to grow in over time of being able to sort of you know manage marketplace

payments in a more flexible way you know 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 benefit and all that stuff do you recommend folks create kind of a

a column for uh opportunity cost or or is this more of a broad thought process you go through when you're looking through your list of ideas yeah it's more of the latter right i do not recommend trying to like quantify opportunity costs because it's a lost cause instead what teams need is just the sometimes the freedom and sometimes just permission to explore and attack these things that minimize opportunity cost

and so as leaders that's the best thing we can do is to give the teams that freedom or the permission to pursue these things and the way it manifests is and the way i've kind of tried to do it is when we are planning i often give guidance to the team around what percentage of our time we want to spend on what type of activity right and i learned this from google's classic 70 2010 where during its fast growth years google had the 70 search

and ads uh you know 20 apps which was like things like gmail and whatnot and 10 on uh kind of other big bets right so i have found that approach very useful during planning where what i will say is like look yeah we need to spend and it again depends on the context but when the team is starting to plan the next quarter or the next half or the next year my role as a leader is hopefully i've already clarified the strategy so they have that as an input but the other thing that i see in my role as a leader

is to clarify the rough allocation right so what i'll share as a guidance with the team is given our situation and given our strategy and given what's going on in the market i would like us to target about 60 of our time incrementals and by that i mean incremental features that improve users lives on a day-to-day basis so these are like actually high roi things that we do so 60 and again these numbers are whatever they are if you pick whatever is right

for you but 60 i want to go towards 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 right so so this is the guidance i'll share with the team and then i will ask the team to and teams to create their plans and proposals based on this rough guidance right so this kind of gives people the

the space to like say okay we we do need we do have this 30 percent so there's no sense putting in more high roi tasks in there or quick wins in there and 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 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 big

idea around high agency and the importance of pm's being high agency and the reason that it stuck out to me is this i found to be really important in my career and i think it lets a lot of the success that i saw along the way is just always feeling like i have agency and feeling ownership of what i was doing and where i was going and so i'm curious to hear your take on this and to kind of dive into this trade of high agency and how important that is for pm's 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 right and so high agency people will and we've seen 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 you know not enough resources challenges with legacy infrastructure staffing issues customer problems and on and on right like there's no dearth of problems to solve as a product manager and i noticed consistently over the years that it wasn't the you know as i started thinking about sort of like

what differentiates the pms who've had just a large impact and even more important than just impact to the company or to the team pms who've surprised me in a positive way pms who really exceeded expectations exceeded uh perhaps like their own you know capabilities on paper right like you you see somebody somebody's credentials on paper and like then you see their work and their impact and there's like a big difference between what you might assume on paper and the and the the the impact they're achieving uh

so that and also the 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 uh potential they're nowhere close to achieving that potential and as i look at both of those situations it became clear to me that like high agency was a big contributor which is the pms in this first category were like despite all the disadvantages and other things

they just took strong ownership so ownership is one component ownership mindset is one component of high agency they took strong ownership and then they creatively executed through the 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 so as i realized that i 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 kind of like you start seeing it in people much more clearly and so that's when i when i wrote about the 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 at that point of just the the power of empowerment basically taking responsibility feeling high agency resiliency

treos this has been incredibly illuminating i suspect this is going to be helpful to a lot of product managers and even non-product managers and so just two last questions where can folks find you online if they want to reach out or learn more and then how can listeners be useful to you yeah so follow me on twitter i'm just at shreyas if you don't have a twitter account follow me on linkedin you can just find me there shreyasdoshi 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 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're working in teams and working on projects and products and so i really like it when people share the ideas whether it's on twitter or publicly or even with others privately so that is perhaps the best thing you can do to help me in my mission

amazing what a beautiful way to end it trails 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 shreyastoshi coming up i'm really excited about that too thank you again great bye [Music] thank you so much for listening if you found this valuable you can subscribe to the show on apple podcast spotify or your favorite podcast app also please consider giving us a rating