You know, one of my personal challenges in my own kind of journey and growth as a leader was it was easy for me to judge other individuals or other teams saying like, oh, these people are only focused on optics, whereas I am focused on impact and execution, which are the right things to be focused on. And when you start with that sort of feeling, it doesn't create or make any room for true collaboration. ♪
Welcome to The Knowledge Project, a podcast about mastering the best of what other people have already figured out so you can apply their insights to your life. I'm your host, Shane Parrish.
If you're listening to this, you're missing it. If you'd like access to the podcast before public release, special episodes that don't appear anywhere else, hand edited transcripts, or you just want to support the show you love, you can join at fs.blog.com. Check out the show notes for a link.
Today, my guest is Shreyas Doshi. He's led and scaled products at companies like Stripe, Twitter, and Google. An early member of the product team at Stripe, he led some of the company's largest and fastest growing business lines, even establishing product manager as a function there. Today, he's an advisor. I wanted to talk to Shreyas because I often find when reading his work that we have similar ideas, but we approach them and come at them very differently.
In this episode, we discuss the three levels of product work and where conflict comes from, the difference between evaluating and measuring something, what he's learned working at Stripe that he still uses today, the benefits and drawbacks of a writing culture, what he's learned about decision-making that most people miss, how you can systematically grow your competence, the role of opportunity cost, the antithesis principle, the agency talent matrix, and so much more.
It's time to listen and learn.
The IKEA Business Network is now open for small businesses and entrepreneurs. Join for free today to get access to interior design services to help you make the most of your workspace, employee well-being benefits to help you and your people grow, and amazing discounts on travel, insurance, and IKEA purchases, deliveries, and more. Take your small business to the next level when you sign up for the IKEA Business Network for free today by searching IKEA Business Network.
I think when I was thinking about where to get started, I want to start with the three levels of product work. So the execution level, the impact level and the optics level. Can you expand on these levels and where conflict arises? Yeah, for sure. So this took me many years, almost two decades of working on products that mainly at high tech companies to really realize
Oftentimes, conflict between people and teams arises mainly because we're not talking at the same level. And we might have similar missions and similar goals and OKRs and whatnot. But if we are not aligned on the level at which we are talking, that can lead to a lot of confusion, a lot of distress among individuals and teams.
And so the three levels of product work that I discovered through my observations were the execution level, the impact level, and the optics level. Oftentimes, there would be product managers or other folks on my team who would be very nervous before presenting to an executive. Maybe it's a product strategy or something else.
And they'd be very nervous. And so I'd have a conversation with them about like, you know, hey, nervousness is normal in these situations, etc. But what's really going on? What is your real concern?
And so they'd often point to past examples where they would say, oh, you know, I was talking to the CEO in this last product review and I shared with them exact details of how we can, you know, make this these goals more ambitious or whatever the case might be. And that just did not land with the executive. And, you know, I shared all the details with them, but like I felt like they were confused and now they've asked for this other product review.
And so now I'm frustrated. Right. And in that example, my observation is that, again, it's the case of people talking and expecting different levels where somebody who's close to the ground, like a product manager or an engineer, you are fixated at the execution level, which is, you know, what is it that I can get done in a short amount of time with the resources and constraints I have?
So that's the execution level. But oftentimes in these situations, the executive, the CEO wants to start at the impact level. They are more concerned about, well, is this product going to resonate? Fine, we'll build the product, but how are we going to sell the product? Have we thought about compelling ways to do that? And how is this going to affect the company's brand? So they want to start with the level of the impact.
And they want to engage in a dialogue with you of how we can make the best possible impact. But then if you come into this kind of product review as the product manager and you kind of drown the group in all sorts of execution level detail, which you think are the right things to share, because these are challenges you're facing right now. If you lead with that, you are going to lose the audience.
And this is merely just one example of where executives are probably thinking at the impact level, product managers or engineers are thinking at the execution level. And I've also encountered team issues, inter-team issues. Famously, there are many organizations where two teams can't work together and they complain. And each team complains that we can't work well with this other team.
Even in those situations, I've often found that it's actually the leaders of the team that are fixating on different things. Maybe the leader of one team is very optics focused. So they are thinking about
What are the optics going to look like if we combine our forces together and work on this initiative? How can we make sure that my team gets the credit that it deserves for doing this work? And perhaps another team leader is more fixated on the impact level or the execution level.
They sweat and, you know, they kind of litigate and re-litigate a lot of details without really realizing that, oh, the conflict is present mainly because one is operating at the optics level and the other is operating at the execution or impact level. One thing that you said there that stuck out to me was they litigate the details. Are they litigating sort of like a different lens into the same problem or
And they keep rehashing their point of view because they think the other person doesn't see it, but they're coming at it from a completely different lens. How do you get out of that? How do you become productive in that sort of litigation or argument then? Look, what we end up doing when we feel like that the other party is not listening is that we just keep repeating our message and we do it louder each time, hoping it will stick and it doesn't.
And then we are frustrated that it doesn't. It's like, you know, I've told you this five times. We've had this meeting three different times. And I just don't understand why you don't get it, right? Like that's at least the feeling, even if it's not vocalized. The real solution out of this is take a step back and recognize what is going on. Recognize that, oh, I see this other team is
is really concerned about the optics of the situation. So let me explore that more, right? Like, you know, one of my challenge, my personal challenges in my own kind of, you know, journey and growth as a leader was, it was easy for me to judge other individuals or other teams saying like, oh, these people are only focused on optics, whereas I am focused on impact and execution, which are the right things to be focused on.
And when you start with that sort of feeling, it doesn't create or make any room for true collaboration. So instead, you know, later on in my career, when I had this vocabulary and this way of looking at things, when I saw these situations where perhaps somebody else, some other team leader that I'm trying to collaborate with is really focused on optics, I wanted to take a step back then and really look
explore their perspective a little more. And perhaps, you know, the reason they were focused on optics is because they've been burned before, that they helped various other teams with their initiatives in the past, and they did not get the credit that they felt they deserved. And so naturally now, they're going to be a little bit more wary about collaborating with my team on this initiative, and they want to make sure that the optics are set right.
So it's only through kind of taking a step back and truly taking the time to explore their concerns
Like, for instance, concretely, I noticed that, you know, in the past couple of meetings, you've talked a lot about making sure that executives are aware of the division of responsibilities between our teams. And certainly my team's perspective is that it is a very ambiguous project. So we can't really clarify all the strict division of responsibilities at this very moment.
But I wanted to ask you what your rationale is for this perspective, because I really want to figure out a way to make this work. And so just kind of having that conversation, engaging in the dialogue, trying to understand where they are coming from, I've found opens up opportunities for us to recognize, oh, I see. I see this is what is going on. You care about making sure that these responsibilities are clear for reason X, Y, Z.
So perhaps we can both achieve our objectives here of moving quickly while yet clarifying who owns what. And let's now brainstorm about that. One of the things that you said online that was interesting is that there's a difference between evaluating how something is going and measuring how it's going. Can you expand on that? Yeah, it's often the case, Shane, that...
You know, you hear in business meetings, right, that if you can't measure it, you cannot improve it. In certainly in most of the highly rational company cultures that I have seen, these kinds of statements are taken as truths. And over time, I realized used in the wrong context, they tend to cause a lot of damage that we don't even realize.
Because we feel like we're being smart when we say, oh, this thing must be measured before we can improve it. Really, the way I realized some of the flaws in this thinking of you cannot improve something that you don't measure is kind of looking at my personal life and sort of evaluating. So I'm a parent.
And so at one point, I asked myself, am I measuring how I'm doing as a parent, right? Or am I measuring how I'm doing as a spouse? And while, you know, I clearly improved in certain areas of parenting, I had not done any measurement there.
So then I started asking myself, well, if I've clearly improved in this area of parenting or this area of being a spouse, but I don't measure it. I don't track it on a daily basis. I don't have any metrics associated with it. And yet I can tell that I'm improving in these areas. So how am I doing that? How many of us are doing all sorts of activities and improving in those activities and
without explicitly measuring those upfront
or measuring those on an ongoing basis. Actually, the way I know that I'm improving is because I'm evaluating, right? And that's where I feel like there's a difference between the idea of evaluating how you're doing and measuring how you're doing. And then I started seeing at many cases, in many cases at work, it was quite similar. You know, if we start everything with
oh, we need to measure this thing first before we embark on this project or this initiative to improve said thing. There is certainly value in measurement, so don't get me wrong, right? Like, again, we should not think binary about this. But in some cases, the effort to measure something is so large that
That it sometimes dissuades us from performing the action that makes sense. The fundamental sort of observation here is that sometimes evaluating how something is going is enough. And sometimes if you try to measure a thing, you might think you might improve the measurement, right? But you might not actually be improving the underlying thing. So that's the other danger as well.
So anyway, those would be a couple of core observations that led to this insight. Okay. But you're a manager or a product manager or a leader within an organization, and you have scarce resources to allocate. The organization has scarce resources. You have scarce resources on your team. Often you need other people to buy into what you're doing with their, I guess, nod of approval, depending on where you are at some level.
And if you're in a culture that is very measurement oriented, saying that, you know, we're going to improve this, but not being able to quantify or demonstrate how it's improved is very tricky to get the buy-in. How do you go about that? Yeah, it is very tricky. And I would say this is why...
the solutions to some of these problems lie not with an individual or individual contributor within the company, but they lie with the company leadership, right? Like, so ultimately the company's leadership needs to have the judgment. And if they do not, things are just very hard. This is why a lot of the work
both the writing I do, the coaching I do, and so on, is focused on leaders and leadership. Without leadership understanding these ideas and these principles, it's just very hard. Now, all that said, what I've found interesting is that it is possible sometimes to pivot this kind of intense desire for, you know, showing, you know, numbers on a graph and
with other ways of showing impact. Because ultimately the measurement is not the goal, right? The impact is the goal. We hope that the measurement is just a proxy for the impact we made, right? And sometimes we forget that we can't differentiate between the proxy and the goal, right? And so we make the proxy the goal. So once you kind of understand that, that ultimately it's about demonstrating impact,
one of the core things we need to realize is this idea of leading indicators. So what I like to remind people in these kind of corporate situations is that ultimately we are after this impact, whatever that is, like customer satisfaction or higher retention or greater revenue or greater revenue per customer, whatever the case may be. That's the impact we're after.
Then I like to clarify, and perhaps using even examples, that features like this in the past have taken three months, six months, a year, a year plus, to show the full impact. And that is likely to be the case with this feature too.
So therefore, what I want to share with you today is some of the core leading indicators we have of how this feature is working. And then I'll go into the leading indicators. And now these leading indicators might be other metrics. So they might be things we have measured.
Which is like the conversion rate in sales calls, for instance, which is an early indicator of potential resonance. Or the number of customers who've actually purchased the product and listed this feature as one of the key reasons why.
So I'll talk to my sales teams and get some of those leading indicators to me from them. And again, these could be measurements. These could be numbers. But the numbers are so small that...
All we might be able to say this quarter is like, "Oh, we got five new customers who said that this feature was one of the key reasons why." And you can't really run an A/B test of any sort or some large-scale experiment with that. So, okay, five is good and we've done some measurement, but this is where I like to also add some qualitative criteria.
right which is uh and i did this a lot at stripe for instance when we were working on b2b products that you know in some cases they took a year or year plus to show direct revenue impact or volume impact is i would call out some very big customers that we were able to sign up and their qualitative feedback on this recently launched feature and i would present that in a in a document
Saying, okay, this is what we are hearing from this customer as a leading indicator. So there are ways, even in a highly quantitative environment, to pivot folks' attention towards what really matters, which is impact.
And then help them understand how that impact has multiple components, some of which may be measured components, while others are qualitative components. Because ultimately, at the end of the day, you know, regardless of, you know, what,
one might cynically think like, you know, your company leadership is primarily interested in impact, right? Now, sometimes they're fooled in thinking that the numbers are the only way to be confident about impact. But if you can make a compelling case of, you know, tell a story about how it is actually a combination of some of these leading indicators, and they may be qualitative or quantitative, they
then you'll be surprised how much buy-in you can get. It seems, maybe I'm wrong here, but it seems from the outside, the professional managers would sort of gravitate towards quantitative indicators, whereas founders would gravitate more towards the qualitative. What's your reaction to that? I think if we were talking about general patterns, that matches my understanding and my observations too.
But I'll add an interesting additional observation, which is what happens when the company starts to scale, right? So now you're going to have to rely on other signals. And one of the things that you might end up learning along the way is that, oh, yeah, so from this point onwards, you have to manage by the numbers.
Because you're not close to the customer anymore. You don't have as much strong empathy for customers as you used to. And at a certain scale, your instincts may actually be wrong. The instincts that actually worked for you early on may not work. The challenge though is sometimes some founders will kind of lose their way entirely.
And again, they make the mistake of treating the proxy as the goal. And they lose sight of the real goal, which is impact. So while I do want you to manage with numbers, because that's the only way you can scale, I also want you to not forget that the numbers will only tell a certain story. And so what you've got to still continue to do is expose yourself to
to some of the signals and these might often be qualitative signals in the market with regards to your competition, with regards to your customers. And so, you know, the founders that have been able to scale really well and their companies have been able to build incredible products over the long term, I have found they kind of strike this balance really well.
They do stay very close to their customers. They do stay very close to some anecdotes and don't just kind of manage by spreadsheet. You worked at Stripe and, you know, from the outside looking in, Stripe is one of the most interesting and considered to be one of the most well-run companies in the world. We've had the good fortune of having Patrick on the show today.
I'm curious. We're talking a lot about the lessons that you're offering. I'm curious as to what did you learn being inside that culture that you've taken away with you and how do you use it? Yeah, I just learned so much at Stripe. You know, I was there for over five years and
I joined as they were just thinking about what product management means at Stripe. And so, you know, this was a company of a few hundred people at the time and, you know, already building really had already built a very compelling product and sort of, you know, at least by Silicon Valley standards, was adding product management a little late.
Usually you'll have product management added at several dozen to 100 or so people. So Stripe was adding product management a little late and had done just fine without product managers. So one of the reasons I joined Stripe was because I saw this as what a wonderful opportunity to really understand if product management can create unique value
at a company that has already been very successful without product management. And so that was one of the motivators for me as somebody who started my career as an engineer but had been a product manager for over a decade by that time. And one of the first things I really learned when I joined Stripe is that when product and thinking about the product and thinking about the customer experience
is everybody's job, which it certainly was and has been at Stripe for a while. You know, kind of thinking about the product and fixating on what kind of product we're building and why we're building it and how it's going to resonate with our users. When it is everybody's job, you know, engineers and designers and even sales and marketing and other functions, right?
then you have at least the ingredients for creating magic. And too often what happens, and I've seen this at many, many companies in the Valley, some of the most successful and modern companies in the technology space, is that at some point, this idea of like, okay, are we building the right product? Are we building a product that our customers will really love?
and are we building a product that will win in the market? Those concerns get relegated
to one function or a couple of functions, while the other functions get more focused or somehow are asked to get more focused on just like stay in your lane, do your thing, you know, ship your code, right? And do it on time and do it at reasonable quality, but that's your job, right? And nothing else. And if it's something about the user experience, well, you know, you bring in the expert, the product manager or the designer, and they will tell you what to do.
In those environments, you just don't end up building really inspiring products. What I saw at Stripe were perhaps two things I'll flag. One was that really every function was treated as equal. Really, you treated every function equally.
And now they might perform different roles, but it wasn't like one function was better than the others or one function was higher than the others. So what that enabled is a much more focused and much more authentic conversation between functions of what is the right thing to do here.
Not once in my five plus years there did somebody play the card of like, "Well, so I am the product manager." So yeah, I realize all this debate and all of that, but since I have this title and this question is about the product, so therefore I'm going to make the call. So it wasn't really about pulling rank or title. It was about really discussing the idea. So that's one way that I think Stripe put this in practice.
And look, the other way of like the entire sort of fabric of the organization kind of pushing you to build the right product was that the founders kind of lived these values as well. Right. So, you know, Patrick and John, until a very, very long time as the company was scaling and to a point where you wouldn't expect the founder to do so, they were talking to customers.
They were talking to users. And not only that, in many cases, they would kind of, you know, have a meeting with the customer and send out notes, right? And another interesting thing I found is, you know, normally when a CEO of a company is talking to a customer, it is usually they're talking to the CEO of that customer, right?
But at Stripe, oftentimes you would get these notes from the founders saying, oh, yeah, so I was visiting this customer and I talked to their customer support team. I spent time with their customer support team to understand whatever it is, how they're using the Stripe dashboard. And so as you saw this as an employee, right?
you realize that this is what the company cares about. When the founders are actually living the values that are put up on the wall, that means that they're not just words on a wall. We can all say, yeah, sure, you need to be customer-centric and so on. But the actual process of doing so involves a lot of discipline, commitment, and consistency. One of the things you said there that I found fascinating is that
Everybody was seen as important and it was seen as everybody's job to look after the customer, which intuitively I really like because I always hated people saying that's not my job. That's not my responsibility. Or conversely, I hated people putting up that card and being like, I'm the product manager. This is my decision with no sort of like basis for making it that's grounded in sort of rationality.
I'm wondering who is the arbitrator of a tie in those situations? How does that work when you have maybe two people who are both looking out for the customer, but they're coming at it from very different perspectives and you have to pick one path and you can't have both? In the case where all functions are sort of equal and everybody's responsible for the customer, how do you make that decision? So in practice,
I'll observe a couple of things. Number one, this is where a writing culture helps intensely. So Stripe famously has a writing culture. And a lot of these discussions would start with a document. And they're asynchronous discussions. And the reason I think it's key is...
Because just having to write these things down forced a degree of clarity that is often missing when you are kind of having just these debates verbally. By forcing ourselves to kind of write down our thinking, it enables the reaching of consensus, right?
or a decision better than if we were trying to do it all just verbally in a meeting. Because again, oftentimes, you know, when we are doing it in a meeting, there's also like other factors that come in, right? Like it's not just the lack of clarity and the lack of comprehension, but also ego factors that become quite, you know, prominent and dominant in how then we decide, right? So I think that just like,
You know, that writing culture helped address a lot of this where, yeah, we might disagree, but now we understand the root of our disagreement better because you're trying to optimize for this metric and I'm thinking of this other metric. So let's have a conversation about that first, instead of, again, litigating the minutiae of whether there should be a three-step flow or a two-step flow.
So that is one kind of mitigating tactic to this. The second one is, you know, oftentimes, yeah, you kind of had to take this decision to somebody else, typically somebody higher up in the hierarchy to make the decision, which is like, look, we've had this
you know, what we call rigorous conversation and discussion. And it's all documented here in this Google Doc or what have you. And we can't seem to decide. I think one of the reasons that it fails is because it becomes judgment-based.
And as much as people like to say that they make judgment decisions, they don't actually like to make judgment decisions because they like to have a lot of rationale behind or numbers behind or authority behind why they make a decision. And when the judgment is subjective, in this case, you have a tiebreaker. Somebody has to be an arbitrator of that, whether it's the founder or somebody up the line. But what they're really doing is they're exercising judgment. And that's where you get a lot of leverage from when that judgment is correct.
it's really powerful. And when it's not correct, it can destroy a company. Absolutely. I like to observe that, you know, there's a difference between very good teams, teams that operate quite well and
and really great teams, the teams that are not only able to operate quite well on one project, but on multiple projects, and are able to kind of, you know, cross fall in it, you know, their goodness to other teams that they work with. Right. And my one of my observations about the core difference between a good team and a great team is the judgment of the leader of that team. What other observations do you have about the difference between a good and a great team?
The first one is really the best way to describe it is what is, is there a, is there clarity on how this team makes decisions? And I mean it certainly from a tactical kind of process perspective. But I mean it more from a, almost a philosophical perspective, right, which is that the
you know, what are we optimizing for? And if you look at all those sort of like, you know, the great companies out there, right? Like they have some way of deciding what makes sense, what product to build and how to build the product, how much attention to detail to give certain things and how much to build fast, right? And hopefully some of those are codified in the operating values or the operating principles of the company, right?
But does this team have clarity on that kind of philosophy for how they're making decisions is, I think, a really important factor. And then are they actually following through on it in their day to day? So that is one thing I like to call out. Second thing I like to call out is to what degree is the team willing to bend rules?
I'm not talking about breaking laws because you shouldn't do that. But to what degree are you willing to bend rules? And there are teams that want to do the right thing that will follow all the rules. And they do it for two reasons. One is there is usually a little bit, perhaps some insecurity, perhaps a lack of adequate courage on the part of the leaders of the team.
But the other is being able to defend when things go wrong, right? So, you know, following rules is very comfortable because if we follow all the rules and it doesn't work out, we can just point at the rules and say, look, we followed all the rules. We followed the process. We came to all the product reviews. We showed you all the mock-ups and all the intermediate artifacts as the rules said and
Right. And so therefore, now, if this product failed in the market or failed to win, don't blame me. Right. Like I followed the rules. Right. And this is how a lot of operators operate in organizations.
I call that the McDonald's problem because, you know, I used to work in tech as well. And people would do this all the time where it's like, I followed all the rules. I got the wrong outcome. And I would say, well, if all you do is follow the rules, you should be getting minimum wage because what we're paying you for is judgment. You need to know when to opt out.
when that doesn't make sense or where it's leading down the wrong path. And that drove people crazy. Yep. Yep. Yeah. It's, it's, it's so interesting that people don't see that the reason they're getting paid the big bucks is, and the reason they, the way they'll create alpha for their team or for their company is through that judgment, right? Because if, if everybody could just follow playbooks and,
then, you know, and they might be wonderful playbooks, but over time, even wonderful playbooks become the industry standard. So now if you want to outperform, you need something else. And that something else is always judgment. And so, yeah,
Yeah, absolutely. That kind of willingness to bend rules. And now the question is, well, how do I know which rules to bend? That's the next question I get when I write about these things. Again, it goes back to judgment. I have quite a few on the list of the attributes of good to great teams. But another one I'll share is
that is often not discussed is just, you know, high agency among the individual contributors of the team. Because I think like at some point, you know, a team, say it's like 10, 20, 30, 40 people, 50 people more, right?
it becomes really important not just for the leaders to be ambitious and have good judgment and so on, but for the individual contributors to be very high agency people where they feel that they have the ability and the desire to influence outcomes. And they are going to execute creatively.
to do that. And in some cases, they are going to bend rules.
And in many cases, you know, most teams have constraints, right? Whether they're staffing constraints or funding constraints or whatever else. And it's this ability of at least a few individuals on the team. You don't need the entire team to be extremely high agency. But the ability of at least a few individuals on the team to have and embody this high agency approach such that, oh, actually, yes, we do have this obstacle, but here's how we're going to creatively execute around that obstacle in order to make impact.
So those would be a few items I would share in terms of that difference between good and great teams. We're going to go back to writing in a second, but we just hit on the agency. So I want to...
go down the rabbit hole here, which is you came up with the agency talent matrix. Wondering if you can explain what that is and how you use it. Yeah. And so, you know, as I was thinking back a few years ago about like the people I've seen that have outsized outcomes consistently, both for themselves and for the teams and the companies they're part of, I realized that there were some patterns between those individuals.
That's when I came across this term high agency, which I believe Eric Weinstein coined the term. And, you know, essentially it's a high agency is about, it's basically about, you know, doing certain things, doing, taking on hard things without waiting for condition to be conditions to be perfect or otherwise blaming your circumstances.
I wanted to kind of marry this idea of high agency that I came across with the idea of your talent, right? The degree of talent you have or the degree of competence, whatever kind of term we use there.
And so then you can kind of start to imagine this, you know, two by two matrix of like, you know, low agency, high agency on one axis, along one axis, and then low talent and high talent along the other axis. Right. And so you get this kind of, you know, these kind of four quadrants, if you will, where if you have low talent and low agency, right.
right then you are going to be a cog in the wheel you're going to perform some undifferentiated work and maybe that's essential work but whatever work you do is not really going to substantially change or improve the trajectory of the team or even of your own outcomes right so that's kind of the low talent low agency quadrant then you have the high talent
but low agency person. Okay, so like these might be, you know, really brilliant people. Maybe they went to, you know, really amazing schools, they have great pedigree, etc, etc.
But, and we've all worked with such folks over time where, you know, they have tremendous potential, but somehow there is probably, you know, something that's kind of stopping them. And they're often kind of looking around them and complaining about,
"Well, but this is not right. But we don't have clarity on the cross-org goals and we don't have the resources we need. And we don't have the cross-org support we need and the cross-functional support, etc. etc." And look, pointing these things out by itself, I don't think is a bad thing. You won't need to confront the reality of your situation.
But what happens when you have low agency but high talent is you have the ability to point these things out, but you don't quite demonstrate the drive and the resilience, the confidence and sort of the creative execution to do something about it. You're waiting for conditions to be perfect. And you have this fantasy in your head that when conditions are perfect, I will be able to achieve the potential of myself or my goal of my team.
So that quadrant I call the frustrated geniuses. There is no situation that is ever going to be up to the standards of perfection that they're hoping for. Then you also have the high agency, but perhaps low talent group. And that group I call go-getters. So these are folks that are just like, they're very ambitious. They want to get things done. They are often very creative.
They're very excited. They want to take on new projects. They have a high degree of optimism, but perhaps they're early in their career, right? And so they don't yet have the talent and the full competence, right? So Go-Getters is an interesting group. And like one other observation that I made over the years is that, you know, given generally, this is more a guiding principle than a rule, but like
So given a choice between hiring a frustrated genius and hiring a go-getter, if it is a role that has a high degree of ambiguity, I would rather hire the go-getter than the frustrated genius. Because I know the go-getter will work hard to resolve the ambiguity versus complain about the ambiguity. And in many ways, product management, the role I have done for many, many years, is
is a role whose primary responsibility is to resolve ambiguities and act in the presence of ambiguities. So for PMs, it becomes really important to kind of have this high agency. And then lastly, the last quadrant in this matrix is, you know, the high agency and high talent.
quadrant. And these folks, I just call them game changers, right? Like they change the game for the company, for the team, for themselves. But the reality is that there are very few of them.
So if you come across a game changer early in their career, you better hold on to them. And you better provide them with the opportunities and the support that is necessary for them to achieve their potential. And last thing I'll say on this topic is sometimes go-getters over time become game changers.
Because with enough experience, now you can increase your competence. So you can go from the low, perhaps on the low talent side to the high talent side just by virtue of having that much more experience. And so again, in many cases, for certain roles, I would rather prefer a go-getter who's perhaps a little bit lacking on certain experience factors
because I've found that those experience factors can be rapidly made up for. I want to come back to the writing culture just for a second here, because I always think about writing as making the invisible visible. So you're taking your thinking, which
Which largely happens in your head and now you're forced to explain it to other people. Because you're forced to explain it, you have to walk through all the steps by which you arrived at your thinking. So you're actually forced to walk through your thinking step by step and lay out some sort of rationale for why you think the thing that you do. And the process...
of writing things down is thinking, right? It is a form of thinking. And it's often the process by which we come to realize we don't know what we're talking about. So the act of writing it is very helpful for the person writing it. But the act of consuming somebody else's writing is also very helpful for what we talked about when we first started, which was perspective taking,
Right? So you're showing me what the world looks like from your vantage point, what variables matter, why this matters to you and how you arrived at this conclusion, assuming you're doing that honestly. I'm curious as to in practice,
I've never worked in a writing culture with the exception of Furnham Street, but what is it like in practice being on the inside? Where is it helpful and where does it slow you down? Yeah, I think one of the areas where it's extremely helpful is when you have a writing culture, it becomes more of a permission-less environment. You know, in a, say, non-writing culture, right?
where perhaps the way big decisions are made or proposals are shared, it's usually in some meeting where perhaps we have a discussion
Or I walk you through a slide deck. Well, the observation is that all of a sudden, if that's the way that big proposals need to be made or even small proposals need to be made, now you need permission, right? You need permission to join the meeting. You need permission to present at the meeting. You need permission. You need to ask for permission to take a synchronous, meaningful slot of everybody's time to be able to share what you want to share.
And a true writing culture kind of removes a lot of those constraints, right? So if you spot something that you think needs to be improved in a writing culture, in a true writing culture, you can write about it and share the document and see what people have to say. See if it resonates.
And certainly, you know, at Stripe as a writing culture, I saw it often where there were people, you know, regardless of their role and their function within the organization, kind of wrote down something super insightful. And as they shared it, it kind of spread through various Slack channels saying like, oh, this person wrote this doc, you know, you should check it out.
And now all of a sudden people are going in the dark and posting comments. It's like, oh, this is actually an interesting point. Can you expand more on it? Or like, you know, I don't quite agree with this. What's your perspective? And all of this is happening in a fairly permissionless manner. So I think that is a very key aspect that people tend to ignore of kind of this writing culture. And it has, you know, done right has like really profound effects on the degree of transparency, transparency,
cross-organization clarity and really kind of innovative big thinking that you can engage in. You know, the problem is that not everybody is a good writer. Some people have also told themselves stories about, oh, I'm not a good writer. And so one of the challenges is that such a culture makes it hard for people who kind of think they're not a good writer to
to be able to influence, right? Because ultimately, you know, any form of communication in an organizational setting is a form of influence, right? So I would, you know, I managed, you know, and mentored a number of people who'd come to me and say, like, look, I wrote this document down, I shared it, it took me two days to write it, and nobody looked at it. You know, the executives don't care.
Or they're just like, cynically, they're giving us busy work, right? So one of the things I did, you know, in these situations is, and this was often situations where somebody on my team or in my org was kind of bringing me this problem of like, what do we do? It kind of became important for me to start sharing some principles of how you influence via writing.
Number one is oftentimes when this was happening, when they were describing this type of frustrating situation with a writing culture, I observed that in their documents had all the right ideas, but it was hard to find those ideas. It's like, here's 20 pages, but there's like three good ideas in here. Go find them. Yeah. Yes. And it was hard to understand the true value of those ideas in that noise.
And so when I observed that, I started trying to identify why is it the case? And then I realized after some time that the reason...
that some folks do this when they're writing is because they want to communicate everything they know about this topic. And of course, when we do that, the story we tell ourselves is, oh, I want to build a bulletproof case, right? So I'm going to provide all of this detail. And of course, what actually ends up in practice is regardless of how well you
you write this thing, the reader is lost, right? And so oftentimes people would come to me and say, like, look, I have this document, but I feel like I'm not using the right words. So can you kind of lightly edit it? And then I look at the document, I'm like, you know, I have to tell you, like, and this is not going to sound like happy news, but
I would rewrite this whole thing, right? Because, you know, here you are, you're saying like, well, maybe you can just use a few better words. But the problem is not the words. We need to create greater clarity. And that means we have to rethink the structure. We need to write with empathy for where the reader is likely coming from.
And that is much more work than changing a few words here and there. But once we kind of like start talking about it in terms of, no, no, no, the goal is not to communicate everything we know about this topic. The next step to step to take is then to ask, which is what is the most important thing I want to convey? Right. And start with that message in any kind of document and proposal in the work setting.
you know, share that message very early on in the document, whatever that might be. You know, our core insight is X. And based on this core insight X, our proposal is that we do A, B, and C. Actually, your proposal to do A, B, C might be informed by, you know, 10 other insights, PQ, RST, etc., right? But that can come later, right?
Or that can come in an appendix section for the more curious. But if X insight is actually the core insight, then that's really what executives need to know.
It's not a movie, right? Like lead with the best here. Don't build up for it because most people stop reading. You have, I think, about eight seconds to grab somebody's attention in an email or document at work. You got to use that time wisely. Absolutely. A movie is an experience.
A book is an experience that somebody is creating. A podcast is an experience. And so similarly, a document that you're writing is an experience you're creating for your target audience. So it helps to be very intentional about
About what do you want them to experience? And I'm not talking about fiction writing, right? I'm talking about like, just like business nonfiction writing about a certain product or a certain whatever. But it's really important to work backwards from, you know, do I want them to be excited? Do I want them to be slightly concerned? Do I want to kind of clarify that like we should be afraid about a certain, you know, competitor or whatever the case might be?
And then, you know, kind of keep that in the back of our minds, right? Because then as we kind of write, the words we choose, the structure we choose, the things we choose to emphasize, you know, change drastically based on kind of this working backwards view of what it is that we really want to evoke in the reader. I want to switch gears from writing, come back to decision making for a second.
What do you know about decision-making that most people miss? You know, there are certain truths or maxims that we learn or we discover about the world and how the world operates. And then we use those maxims for making many decisions. Sometimes we should use the antithesis of that truth or maxim
when it applies to us. So I call this the antithesis principle. One kind of truth that we might know about the way the world works is that most people learn better when the content or the teaching is entertaining. When it's entertaining, it's got great stories, amazing analogies. People just learn better.
And there are many people who proudly say, right, like, you know, and I come across such folks all the time as a teacher myself or as somebody who writes online and so on, is that, well, I only learn through engaging writing. As a smart person who wants to make a big impact on yourself and on the world, right, if you think really deeply about this kind of truth, let's just say,
which is most people learn better, learn the best when the content and the teaching is entertaining, is that if you want to help people learn something, make it very engaging and entertaining. So that's the obvious conclusion that almost any smart person will reach. But it turns out there is actually one more conclusion you should draw to be a better decision maker and to have better results for yourself.
which is it is actually not in your best interest to be the kind of person who only learns from entertaining content. In fact, to go even further than that, you should not even be the kind of person that needs any sort of entertainment as a prerequisite to learning. And so I would say that most smart people don't consider this second conclusion. And we make decisions for ourselves and we create identities for ourselves
around these kinds of areas because we see these truths in the world and we assume those truths must apply to us right and that's why it's the antithesis because you know actually what you should do if you want to optimize and maximize outcomes and your impact on the world is you should turn yourself into the kind of person that doesn't need any sort of entertainment to learn something
Because that way, while most people will discard a profound book that doesn't have an attractive title, you will actually take the time to read that book and to really learn from the book despite it having a terrible title. So that's just one example. Once I saw this in myself first,
I realized that this idea of the antithesis principle applies to all sorts of things. And I'll just share one more example and would love your thoughts afterwards. One of the things that if I post on Twitter that a great manager is really important for your career, I will get a gazillion likes.
Because it's something people love, right? Like, which is like a great manager, just follow great people, great leaders, and you will have an amazing career, etc, etc. Right? So, so that's kind of perhaps the truth you observe about the world. But now what are you to conclude from this? Right? How do you kind of like, on this observation? Well, the first conclusion you can draw, and this is the more
sort of more obvious conclusion is that you should try to be a highly competent manager yourself and you should try to be a really great manager of people so you can attract, you know, highly energetic, highly talented people and you can help them do really good work. But there is a non-obvious conclusion that the antithesis principle suggests, which is when it comes to yourself, you should turn yourself into a person who
who can do really good work even without having a great manager. Even if you have an okay or absentee manager, you should turn yourself into a person who can do really great work. Now, the second conclusion is the non-obvious conclusion that very few people draw, right? And in fact, most people will blame in some way, you know, the fact that their manager doesn't do one-on-ones with them as frequently as they expect.
and say, well, of course, this is why I'm not performing as well or whatever. And perhaps that is a reasonable statement if you're early career. But if you're 10 years into your career, 20 years into your career, and you are in a career which rewards you for your judgment and your agency and so on, it is actually in your interest to pay attention to the antithesis principle.
Because again, if you just rely on great managers around you, then you're kind of limited in terms of how much impact you can make. So yes, by all means, be a great manager yourself and try to be the best possible manager you can. But at the same time,
don't always expect that you can only do good work if you are working for a great manager. So again, this kind of applies to so many examples. And I think people make this fundamental mistake when they're kind of just making decisions for themselves for like what works for them and what kind of person they want to be. I think that's a powerful encapsulation of an idea that
Which boils down to you need to be able to operate regardless of the circumstance that you find yourself in. If you can only operate in ideal circumstances, you're only going to be average because circumstances are never going to be ideal and you need to find a way to operate no matter what the circumstances are. Yeah. And I think the challenge for many people is that the reason the antithesis principle is not valid
extremely intuitive, and certainly it wasn't for me early on in my life, is because it requires us to embrace inconsistency, right? Like we just like habitually look for consistency. So the thing we observe in the world, we want ourselves to act consistently with the thing we observe in the world. But the antithesis principle says that
that the very fact that you made an observation about this thing in the world, the way the world works, and in all of its imperfect ways, it indicates that, yeah, sure, by all means to have an impact and to be effective, you need to recognize the way the world works. But that doesn't automatically mean that you also embody that in yourself, right? And perhaps just to kind of drive the example home, the first time I really realized this
is when, you know, I was just kind of reading, we've all heard this kind of anecdote, and I don't know if it's true, but like, it's the, what is that? The idea that, you know, people form a strong impression of you within seven seconds of meeting you, right? And so what that suggests is that like, you know, if you want to be influential, if you want to, you know, make an impact, you should work towards creating a strong, positive impression.
In the first few moments of any interaction. And I think many people do that. But when I started thinking about it for myself, I realized that, but wait, if I fall prey to that same bias, I am going to unfairly judge other people who are otherwise great perhaps.
But perhaps they did not make a strong, great impression in the first seven seconds. So I need to actually follow for myself. I need to follow the antithesis of that when I am meeting somebody new. Right. And again, that kind of inconsistency happens.
is not natural to us as humans. And so it kind of like, we really need to be intentional about developing it. I want to ask you about how you think about opportunity costs as they relate to decision making. Yeah, most of us and most teams certainly are ROI machines. They are return on investment machines. And the way we evaluate things is,
evaluate work, whether to do a certain work or not, is this going to provide us with a positive ROI? And again, during my own career as a person who was responsible for deciding what should we build, when should we build it, what should we build first, for a long time I used ROI as a core value.
way of thinking about the work we do. So it sounds good, but the challenge is like, you know, the formula for ROI is like, you know, the value you got minus the, you know, the effort or the time or, you know, expense you put in to get the value divided by the effort time expense, right? Whatever the case might be. So it's a ratio, right? Now, whenever you have a ratio and you want to increase that ratio, so in this case, ROI,
you can increase the numerator or you can play a trick and decrease the denominator. So you can keep the numerator constant, but if you just decrease the denominator, you can increase the ratio. And so I saw that tendency play out very often in making decisions about what to work on next, what to prioritize, how to think about our priorities. Oftentimes, teams will gravitate towards things
where the denominator is small, right? So practically what that meant is this is low hanging fruit. This is a quick win.
right? Oh, it will only take one day to do it, right? And then I'd ask, what's the impact of it? Well, it doesn't have a very high impact, but again, because it's quick, let's do it, right? And so we get kind of really seduced by this kind of tendency to want to reduce the denominator. And what does that do? What that leads to is a lot of me-too products,
It leads to us kind of just meeting table stakes. It leads to kind of picking the safe things because the safe things are easy to quantify and they're safe because they're easy to quantify. And look, I have nothing against those kinds of improvements. I think those are important. Those incremental improvements are absolutely important. But I find that a lot of product teams, when they're making decisions about where to spend their time,
They are solely working on those kind of high ROI things and typically things which kind of just reduce the denominator. And they are afraid to pick up the ambiguous thing, which might have a very large return, but might require some effort. Right. And might involve just working through the ambiguity.
So that's when I realized that actually, you know, a better way when you're in a very high leverage role, a better way to think about these decisions is through the lens of opportunity cost.
Where opportunity cost is roughly the value you get out of the optimal option and the value you got out of the option you chose. So the delta between those two, the option you chose and the value you'd get out of the optimal option, that's what your opportunity cost is.
And when you look at things through an opportunity cost lens, what you really realize is that for certain things, you want to kind of minimize the opportunity cost, meaning you want to pick the thing that is as close to optimal as possible.
And so that's kind of how you minimize the opportunity cost. So that's why I like to say that, you know, in a high leverage role, your goal should not just be to increase ROI. You should also think about how you're going to minimize the opportunity cost.
And the last thing I'll say here is oftentimes people say, but well, you know, we can work on a number of different things because who knows what the optimal thing is, right? We can work on a bunch of different things. And as long as those are generally positive, we will be fine, right? And we can always backtrack if they're not. But the problem I found in practice is that it's easy to say in a meeting when we're trying to just like decide on something, they're like, yeah, yeah, of course, if it doesn't work out, we'll just backtrack.
But in practice, I saw us never doing it. And so I also looked into why. And what I realized is that
you know, it's kind of like the IKEA effect takes hold, right? Where we put in a bunch of work behind this. And so now we think it's more valuable than it truly is, right? And now we are going to just like, you know, stick to it despite the world telling us or giving us evidence to the contrary. So that's the cognitive bias there. But there's also more than just cognitive bias. There's a practical issue, which is,
You know, our code, so I'm talking about software products for the most part, but it applies to many other products and initiatives as well. But our code is not as malleable as we think, right? We just think, oh, we're going to write this code, ship it. And then if it doesn't work, we're going to undo it. We're going to change it. We're going to learn, et cetera. And all of that is good. But our code is not as malleable as we think. And so it takes us much longer than...
to kind of, you know, try to find that kind of optimal thing. We are making changes to the code. And at some point, our code just refuses to cooperate. And so we left, we get left with this kind of highly suboptimal product. One of the things that you've given a lot of thought to that I do want to ask you about today is how do we systematically grow our competence?
You know, one of the core things in kind of systematically growing our competence is the idea of decomposition. And, you know, anytime we say, okay, we want to get better at decision making or, you know, in the product world, a version of that for product decisions is product sense, right?
I want to get better at my product sense, which I define as the ability to usually make the correct decision about a product or a product feature, whether it's macro or micro, even in the face of very high ambiguity. And so when somebody is confronted with something like that, and that being a core part of their competence,
It is very confusing because like what step do I take here? So that's where decomposition comes in very handy because you can look at almost any area of competence and you can decompose it into its constituent elements. All right. And so so let's take in this case again, let's take product sense.
Well, product sense, which is again the ability to make the correct product decision. This is why, by the way, some people are really great at consistently building very good products. This is why some companies are very good at building products that resonate with their users is because they really embody that product sense in the work they do. So, well, it turns out product sense has three components. The first is cognitive empathy.
which is do I understand how you think as a user, how customers think, how they approach situations, what will resonate for them or not, right? That is cognitive empathy.
Second is domain knowledge, right? Do I understand enough about this domain, about the technology, about the market, about the competition, et cetera, et cetera, such that I can make a decision that will differentiate us such that, you know, I do understand regulation and the limitations of what we can get done, et cetera, right? So that's kind of domain knowledge. And then the third piece is creativity.
And creativity is about taking these two inputs, which is cognitive empathy and domain knowledge, and turning it into a concrete proposal for what we are going to build. So you can have the first two, but if you don't have the creativity on your team, then you can take all those inputs, but you won't be able to convert those inputs into a compelling product proposal and a compelling UX proposal.
and a compelling go-to-market approach, and a marketing approach, and so on, that will actually then resonate and lead to product success. So these are the three components of product sense. So now if I want to increase my competence, grow my competence systematically, it becomes much clearer how I do that, which is, okay, in order to grow my product sense, I need to grow my cognitive empathy, I need to grow my domain knowledge, and I need to grow my creativity.
Now, there are details of how you might do that. But the point is, now you have, you know, much more clarity on kind of this systematically growing your competence. One other tactic I'll share on this topic of systematic competence is you have to understand a lot of people think that, you know,
At some point in their career, they reach a stage where they start making the assumption that the only way that they'll grow their competence is through projects they do at work, which is, hey, I'm clearly doing all this work and I'm learning all these new things. Right. And that's growing my competence. And absolutely it is, no doubt whatsoever. But the challenge is that.
What I ask people to do instead of just being focused on learning from projects at work is, you know, look, you have 168 hours in a week, like, you know, take some number of hours and call it your career time. And I don't care if it's 30 hours, 40 hours, 50 hours, 60 hours, 70, 80, 90, whatever you do, you pick something.
some number of hours in a week, which is your career time. And your career time certainly involves all the time you spend on your work, on your projects at work, right? But let it not be 100%, right? I want you to carve out 5%, 10%, 20% of your career time. And I want you to allocate that time on learning outside of your work projects, right?
And this is something I personally did, you know, like since the very early days of my career. And I found that what happens is that kind of even if it's 5%, like say 5% of 50 hours, right? So in a week, so that's two and a half hours a week where I'm explicitly not learning just from, you know, doing projects at work. And what that does is that compounds like crazy over time.
And the interesting part is some people say, well, but I can't do it because I'm so busy at my work. I already don't have enough time to do all the things I need to do. And now you're saying, take two and a half hours less or take three hours less. But what they miss is that those two and a half hours or three hours a week, if you invest consistently...
will make you much more effective and efficient at the remainder of your project time. So you'll naturally just be able to do things much faster and much better in the time that you're spending on your projects. And in fact, will take you less time now to have the same degree of impact.
So, you know, of course, the last piece here is this requires, you know, a mindset towards growth. This requires some degree of ambition and this requires taking responsibility for one's own competence. And so those are prerequisites, right? Without those mindset changes, none of what I said will actually be put in action or resonate with somebody. Because if you are going to say, well, it's the organization's job to grow my competence, then sorry, it's not going to happen.
Shreyas, this has been a fascinating conversation. We always end with the same question, which is what is success for you? Oh, I love that question. Success, I define as the optionality I have with my time. And it took me a really long time to really understand this well.
Because I was always very ambitious as an individual. And so I wanted to be very successful. But when I achieved certain goals that I thought, you know, work towards my success, I was still left a little unsatisfied. And so I kept looking for this kind of what is success for me. And I finally cracked it in my very late 30s.
which is success for me is time optionality, but particularly it's about, am I able to spend the time I want to spend on the top three things in my stack rank of my life priorities?
And so I have about a few things that are buckets of my life priorities. So one is career, another is family, third is interests, fourth might be friends, fifth might be community, et cetera. So I kind of like to think about these buckets in terms of a stack rank. So at this point in my life, what are the top three things in my stack rank? And that stack rank changes.
And then I like to evaluate, you know, am I able to spend the time I want to be spending on the top three things in my stack rank? And if I am, then I'm successful. And so by that metric, I wasn't really successful in my 20s or mid 30s because I was not able to spend all the time I wanted to spend on the top three things in my stack rank. But luckily now I am. So I feel like I'm kind of successful.
It's a great definition of success. And I thank you for spending your time with us today. Thanks Shane for having me. It was really wonderful to chat and long time listeners. So really, really happy and honored to have this conversation with you. Thanks for listening and learning with us. For a complete list of episodes, show notes, transcripts, and more, go to fs.blog slash podcast, or just Google The Knowledge Project.
Until next time.