#80: Becoming an IC again is how products leaders will stay relevant in the AI era | Gokul Rajaram

All right, we're live. Gokul, thank you so much for joining us.

Thanks, thank you. Great to be here and excited for this conversation. I've been looking forward to it.

Me too. I, I listened to your roundtable in the Supra community a while back and was just like, couldn't stop paying attention. Like, I was taking a bunch of notes and I told Mark, like, we got to try to get Gokul to come on the podcast one day, and here we are. So I'm, I'm really excited about it. And, you know, one of the things that got us particularly excited about this conversation is there is currently a very undeniable trend in the product management world where a lot of people who are coming out of the ZERP era, the last 10 or so years, working their way into management roles like GPMs, directors, VPs, chief product officers, where the scope was kind of like overseeing more people, are now finding themselves really excited to go into individual contributor roles, IC roles, especially where there's an expectation to roll their sleeves up and get all up in the latest AI technology and the craft. And you wrote a post about why you think this is a great time to go into the IC role. Why do you— what do you think is special about this moment and why did you write that?

Yeah, I think it's actually like most things. Everything is sparked for me. Most things are sparked by a conversation. I always think one conversation with somebody is a data point, one point, but then two or three, you can start connecting the dots. And so when multiple people in my orbit, people I had worked with before, asked me for references, they were leading teams before, leading, they were managers of managers before, and now they're interviewing for an IC role at an AI company. I was like, what's going on here? And talking to them and pondering over it, I think it is actually a very good thing and sensible thing for almost everyone to consider becoming an IC in the age of AI, as I call it, even temporarily, because the leverage equation has changed fundamentally. I think AI tools like we've seen, whether it's coding tools, whether it's writing, whether it's synthesizing analysis, all have made individual contributors much more productive. I mean, maybe 10x may be too strong, but multiples more productive. So, a single IC— I mean, you, you earlier, we were managers managing a team of, say, 10 people. They were managing, or they were managing another 10 people. Maybe you could manage 100, 200 people, but you could become an IC that does the work of 10 people if you build a set of agents that are productive and that are trained. And so, I think the leverage equation. So I think the gap between a high-performing IC and a manager has narrowed in terms of output. So on one side, you can get significant leverage as an IC and get the work done of a team by just managing a team of agents. Second, I feel if you've never worked in an AI environment before, you are basically not going to be accepted as credible if you want to work in an AI-native company, which most of us will be one way or the other working in an AI-native company 10 years from now. So if you look, if your career is only 2 years more to go, it doesn't matter. Do what you need to do. But if you want to work for 10 to 20 years, it's silly to not think about the long term and have your next role be something that really gives you the skills to succeed. And if you already manage people, that's not going anywhere. What you need to do is get closer to the work and credibility comes many times, obviously a lot of credibility is from strategy, but increasingly I think in the age of AI, because of this leverage, everything is going to be flattened. So you're probably going to be managing more and more ICs or agents instead of managers. So ICs value frontline managers who've done the work before. So if you're a manager who can roll up your sleeves and deliver results directly, or you've shown that you can done the work, you will be able to connect with your team better and even understand how to manage them better, as all of us know. So I feel on one side you are getting more leverage from these agents and understanding the work, and you can be much more productive compared to what you were as an IC before. But second, from a credibility point of view, if you ever want to be a manager again, if you want to be a manager in an AI-native company, AI-native companies CEOs are coming to me and saying the hardest role to hire today is head of product. Why? Because they are not able to— they cannot just go and pick an assembly line fashion, a product leader who worked at a Google or a Facebook or whatever the case is, because those people, they grew up in an era where they didn't use AI. I mean, I grew up in an era where AI was more machine learning, predictive AI, not generative AI. I should say AI, I mean generative AI actually. Obviously there's classification AI and predictive AI.

And what do you tell those founders? Like, do you find yourself starting to repeat any heuristics or patterns that might be good to follow when it comes to finding that person?

Yes, promote from within. Promote from within. Many times I think founders try to get ahead of product too early. First, let me make this statement. They try to get ahead of product too early instead of just getting— I'm like, why do you need to have product? You only have 2 PMs. You want them to manage 2 PMs? Get a senior PM who's basically worked for 2 or 3 years in an AI-native company. Get them to come and do the work as an individual contributor first of all. And then slowly you have now 3 PMs and then see which of those you can maybe promote to be a manager. But again, do you really need that? You need manager. Why can't you manage them? So I always push them. Well, I've never managed PMs. It's okay. PMs, the best PMs are actually self-managed. They should create more leverage for you and you learn how to do it. I always feel as a founder, you also need to know how to manage different functions yourself first so that you know who to hire. Many times you hire people without knowing what you want. I think CFO, VP of sales, all of these roles, If you've never managed AEs before, you start focusing on the wrong things. So I've had a founder who's fired, unfortunately, CFO, CMO, CRO, CPO. I think there was one more, 5, because he hired wrong. Then he fired them. Then he had to do their job for 6 months. And that's how he learned who he should hire. And then he hired the right person. So I don't think you can, you can, yeah.

I'm curious if when you talk to those founders about, hey, like maybe hire that senior PM, Are there any new competencies that you're telling them to focus on when hiring them, or maybe any existing ones that you think are way more important today than maybe they were, let's say, 3 years ago?

Yeah, I think judgment is always— good news is judgment, which is always a huge part of the product manager's role, which is any one of us given a product probably within half an hour could come up with a number, like maybe 100 ideas how to make the product better. The judgment is which of those ideas actually moves the company forward, moves the product forward, solves the customer's pain better than everything else. So how do you sequence them? And then how do you influence the rest of the org to then be aligned that this is the right thing to do? So judgment and influence are things that you can't easily outsource to machines. That said, execution is where you start seeing AI really change, where I think Fundamentally, you want to go from— I think Google went from— Microsoft had this waterfall model back in the '80s when program managers was, I could say, invented at Microsoft. Google in the 2000s made the product manager role a much more agile document with a PRD, which was constantly iterated along with the engineering team. But now the document itself has moved and shifted where instead of a long document of any kind, you have a very short context-setting document. Plus a prototype. So you want somebody who understands how to execute with engineers using these AI tools and someone who can, if need be, take on some of the roles, take a design system that the company already has and create a new prototype or take and basically show what is to be built, not through words, but through pictures in a very fast way and prototype. So I think you want to show execution. Execution is basically basically what is changing. And the roles, I think, of analyst— I always feel there are, there were 4 roles which are not engineering: analyst, designer, product manager. There's one more, actually, and front-end engineer. You could say backend engineering is slightly different. Those 4, I think, will eventually converge into 2. So I think you need a PM who can take on at least 1 or 2 of these other roles.

And why do you say 2?

Two, because I do think front-end engineer, I think into one just seems a hard thing for a team, for one person to do 4 different roles. I think 2 people doing 4 roles seems more manageable and feasible. Maybe it becomes one as the tools become better. I always find that I always underestimate technological progress. So it might be that in 5 years it could be one, but I feel even 2, because designers, you do need somebody who has an eye for design. So I think As a product manager, you need to think about your superpower. There are different, as you know, there are different archetypes of product managers depending on where they come from. There are marketing product managers, analyst product managers, engineer product managers, et cetera. And so depending on where you came from, you actually maybe already have the skill set needed to become one of those other, or designer product manager. So if you're a designer who became a PM, guess what? Now you can be both a designer and a PM together. If you're an analyst who became a PM, guess what? You can now be an analyst and a PM.

If you're a front-end engineer, that design, there's nothing stopping the front, that designer from also being the front-end engineer.

That's it. Those three. Exactly. So those three, I think, and you then have for multiple pods, maybe one dedicated designer, you don't normally dedicate designer per pod who's setting the design systems, making sure everything works together and you do a design review and make sure, but you can then run without having a dedicated design resource. Per pod or dedicated front engine per pod or dedicated analyst per pod. So I think that's how you're going to see, you're going to see more sharing of these crucial resources across multiple pods. But then the PM is the pinch hitter who's basically coming in and doing a bunch of different roles. The worry I have, of course, is that the more— the other reason maybe that maybe it should not be one is one of the roles of the PM is to constantly be the voice of the customer, as you know. So the more time you're spending on execution, The number one thing that your stakeholders ask you as a PM and expect of you is that you know customers. You know, you have the most— obviously you want everyone else, but you need to be talking to customers, understand their pain points better than anyone else in the company. And so if you spend too much time on the execution piece, and this is the fine art, I think PMs— I was not a very quantitative PM, even though I came from an engineering background, because the tools weren't there in the early 2000s when I started. I spent a lot of my time talking to customers. I feel now PMs of today are so good at analysis that they have lost the fine art. Many people lamented they've lost the fine art of talking to customers. They just get a lot of data points and then analyze reviews and think reviews are basically just getting to reviews. This is what people just went on the App Store tells me what to build versus going and interviewing and really getting them to tell stories about what their experiences were. Really extracting stuff. I think that is a lost art. And I worry that the more people spend time on execution, they're going to lose the art of actually talking to customers and extracting what really matters, what the pain point is without leading them on all of those things that PM should do.

What's your— I think like another word that I hear of like in the LinkedIn sphere or like in product circles is like, okay, yeah, taste is going to be very important. I think that's just another word for judgment, in my opinion. The other one is kind of related to what you were just saying about being close to the customer is maybe product people owning a little bit more of that go-to-market, that business side of things. And I'm curious, like, what are your thoughts there? Do you think that's realistic? I know I look at your career and I feel like, you know, you started in product, you were a founder, but then you've kind of picked up more business responsibilities along the way. So how do you think about that go-to-market motion and now with AI?

I think product people should not necessarily— I don't know if they should own go-to-market in their entirety, but any product manager who wants to advance in their career, they have to think about customer outcomes. I think about 10 years ago, I got this— I basically, when I joined Square to lead PDE, one of the things I realized is that we were celebrating launches. And so I think many product teams and engineering teams celebrate launch as a metric. We launched something, hurrah! But we basically made a statement, strong statement that we are not going to celebrate launch anymore. Launch is not success. And so I think what that means is you have to have customer outcomes that you define clearly and that basically constitute success. So I think as soon as you start thinking about outcomes, there is a business element to it because the customer outcomes that you come up with and customer outcomes are not necessarily business outcomes. There is a slight but crucial delineation. Customer outcomes are behavior changes of a customer. But no business outcome happens without customers changing behavior. Customer change behavior from being not a customer to being a customer, or from being a churned customer to being a resuscitated customer, being a sporadic customer, being a loyal customer. Those are all— or using a certain thing, not using a certain thing, or vice versa. All of these are changes that hopefully you can then tie back to a business metric. So I think the number one goal of a product a good product leader or product manager is to figure out what are the right customer outcomes that map cleanly to business outcomes. And then to figure out what are the things we can build that can move those— what are the different choices we have to move a certain customer outcome? And then obviously prioritize between those. What is the highest? We use ICE or RICE or whatever the case is to figure out what's the thing I can move that can move the customer outcome. As soon as I'm thinking about that, if you can do that well, The company is so happy. Why? Because every feature, everything you launch is not just launched in a vacuum. It is launched because, and that X is some customer outcome. And why is that important? Because the customer outcomes moves the business outcomes. I tell my CEO, see, many CEOs, they don't know how to engage with their product teams properly. I say the only question you need to ask is why. You need to ask your product teams, why are you shipping this feature? If they cannot tell you what customer outcome or what this thing is going to change, if they don't have a clear hypothesis, you need to shut it down. You need to stop them from shipping. Because don't think of— I think especially in the AI era, a lot of teams think of shipping fast with high velocity as some marker of success. I think it's just to say it's the opposite. If you ship too many things, it's basically you don't have enough time to even create a hypothesis. You're drowning your customers in slop, in lots of features. And the best products cut features instead of adding features. Like I said, we all can brainstorm 100 features, but look at the best products we use. Like this product, it has minimal features. You should be— one of the things about great products is that you, they should be usable without needing a manual. I always admired about Square, the point of sale, before I ever joined it, that the product point of sale is something a barista has to be trained in. For several days before Square. Even today, if you go to a thing, you can see people training. I was at the SF airport the other day and someone was training. Here's what you do, here's how you take. That means that the product is not good enough for someone to use. Square, you just download the thing in from the App Store and start using it. And I was— Facebook Cafe, about 10 years, 12 years ago, had Square Point of Sale. And I was talking to the baristas there. They were like, man, we were at prior cafes. We would always have to go through a multi-day training on the point of sale. This one, no one trained me. I just started using it. So the one of the asset tests for your product is, can your customer accomplish their goal without someone having to train them through it? Anyway, all that— I entered a tangent— all that goes to say that customer outcomes are the number one thing that the product team needs to own. And if you're launching a feature without a clear sense of customer outcome, the CEO needs to have the guts to step up and shut it down. It doesn't matter if the engineering is clamoring for it, a product team. What is the outcome? Articulate it, put it on that, and that should be the number one thing you put on your document. Like I said, there's a short document. What is this outcome that you're hoping to accomplish? Customer outcome. I don't care about revenue, et cetera. What is the customer behavior change? Like I say, if a feature has shipped and no customer behavior has changed, did the feature really ship? It's like the tree in a forest. I don't think so. I think it's a useless feature and we should cut it out. If you can't articulate what customer behavior changed.

I feel like—

DoorDash was the best at it. DoorDash was the best at it. It was excellent because they always, even today, I've never heard of a— in fact, you could argue that a feature launch is a really bad thing because it kind of assumes a feature is launching. But every feature, as we know, is an experiment to prove a hypothesis around a customer behavior. And so if that's the case, like you do, experiment should always be run on a subset of the population, on a control group. And so here's the experiment you're running. So I think that's the mindset orientation that needs to be there. These are experimenters, these are hypotheses we have, and we have the— then you should ask, what's— why is this hypothesis there? Why do you think this experiment— why is this hypothesis— what data do you have this hypothesis is even valid before you start doing the work? So there's some probably data based on Customer interviews based on what we've seen, behaviors, et cetera. But at least you have— you're putting it on paper. Then you run the experiment. You're not subjecting the entirety of your customer base to this experiment, subjecting 5 to 10%, whatever statistically significant population is. And then you see the behavior change. If it's meaningful, then you roll it out over a period of days. But if it's not meaningful, then you still have— then you need to go back and try to understand Okay, what is the root cause? And you, you are obligated as a product person or product team to understand why did this— we had these assumptions that this running this experiment will satisfy this hypothesis or prove this hypothesis. Why, why does this not happen? And you need to get to that root cause. You can't be lazy and say, I'm going to abandon this line of thinking and move on. So you need to spend time. That's how you build trust with your stakeholders, following it through, understanding, look, we had this assumption. Oh, this is not true. You need to get to the root cause. The Japanese, you're asking 5 whys or something like that. You can't just, I'm going to throw this experiment away and move on to the next experiment. You've got to follow it through a few times and iterate. Sometimes iteration leads to the best insights.

Yeah, we're actually putting together a guide right now on DoorDash's PM interview process. And what was really interesting to me coming from the Meta world is in a Product Sense interview, the PM candidate's ability in a DoorDash setting to really get to the root causes and to unpack the problems that they want to solve and to really pinpoint the root causes and come up with a very specific solution or a set of solutions for a very clear root cause. Seems to be something that is very valued in the DoorDash interview process. And then I was ordering some DoorDash last night and I was just like thinking about that conversation I had recently for the guide. And we ordered some dinner and there's like a, there's such clear behavioral triggers in the, in the product. Like I ordered dinner and then I have like 10 minutes to add some ice cream from a place that I really love ordering ice cream from. And it forces a question of like, do we have ice cream in the fridge? No, we actually don't have ice cream in the fridge. Sounds like this is pretty easy to add, right? So like I can just hit a button and bam, like that delivery's gonna come and it's gonna also come with ice cream. And so it's like I can see that maniacal focus on like behavioral change come through in the product. And I kind of wish more products made me, you know, emotionally driven to do things that I want to do, right?

That's right. I think, yeah, some products do it really well. I think, and it needs intention. You can't just get it without intending to. And you need to have the culture where the customer— I think the customer has to be put first because like you said, if customer behaviors change, everything else, business model, monetization, all of those things will take care of themselves. But you have to be able to change customer behavior. One of the biggest dangers that companies have, I think especially SaaS or business B2B companies, is they think of revenue booked as a primary metric. And I think it is a very good metric, but it's a lagging indicator. Leading indicator has to be usage of the product. Because we all know Salesforce instances and other old school software companies where people don't use the product and they've booked revenue or customers have booked revenue, but no one's using the product. Half of— there's some stat for some of the, one of the large companies that half of the licenses are just unused at those companies. They just buy it because they think it should be. So even there, if founders don't understand how people are using the product and are using it on a whatever the metric, it should, could be daily, could be weekly. And that should be a trigger. If they're not using it, it's probably going to be a churned customer. And so you can't just use revenue as the indicator of success in B2B SaaS products.

Yeah. I, by the way, I love the point that you made that a good product should be able to be used without a manual or instructions. And I feel like this lesson is like very important in today's age when like almost like building is getting commoditized. Everyone's like, cool, like, you know, this thing that used to take 3 months, now I can do it in a sprint. And then I think that's eventually going to lead to like all these like Frankenstein products that people are are quickly reacting to, you know, big customer features. And now the, like, the prioritization question is getting easier because it's taking less time. So I think like, that's like gonna be, I have a feeling that's gonna be a lesson that people are gonna have, painful lesson that people are gonna have to relearn. So I'm glad you mentioned that. I'm curious to like, so like that kind of, I love the hypothesis validating, almost like playbook to follow here to make sure that you're actually, you know, creating customer outcomes. But I'm curious like, for a company that maybe doesn't have the statistical power, you know, like DoorDash or Uber, like, How do you recommend founders going zero to one to really like test those customer outcomes when, you know, you just maybe have like two pilots or three pilots and, you know, not quite, you know, evidence?

One of the great things about AI is that it allows you to— I think most AI software companies, one of the beautiful things about software today is that unlike earlier days, earlier eras when software was a tool used by humans, AI actually does the work of humans. We've discussed this just now. I mean, does the work of designers. Junior designers, mostly junior humans, young humans with not much experience, but they're slowly ramping up. So I think what I'm looking for, for example, when I'm looking at investing in companies, is have you driven economic value to your customers? And what that means is have you basically replaced or basically caused them to not hire a certain type of human being after they've started using it, or some other kind of economic value? That's obviously a cost-driven argument. The other one is revenue-driven environment, or revenue-driven argument, which is have you somehow increased the revenue of these companies? So for example, there's a company I met which was doing sales coaching and a very young company. And they found that essentially, say, and then what you can do is you can do A/B testing on your customer's behavior because it's mostly, in most cases, it's B2B. Obviously there's B2C, but even B2C, but B2B, you basically can very clearly say, you can take a cohort of sales agents. You can put your sales coaching, you can apply your sales coaching to them. And then you can see whether those agents are much more productive compared to the broader pool based on your sales coaching, for example. So I think you need to— you can structure an experiment within your customers if you're selling to enterprises where you're using it, or you can— either case, I think you have to figure out ultimately, is your product driving value? And when you structure your product as an experiment within the customer, You can then see pre-post. Because if you can't get your customer to articulate the value that you've delivered to them, I think you're going to not be a successful product. Because again, value delivery comes before revenue and monetization. I always, again, I tell founders, if you can show— if the customer can parrot back exactly what you've told me as a potential investor, if I can talk to them and they say the same thing, I know that they're going to ultimately pay, expand, renew, be an advocate, etc. If they are not able to articulate value, none of those things is going to happen. Even if they are paying today, they'll probably churn. The pilot is not going to go through, they're not going to expand, etc. So your number one job as a founder is to figure out how your customer is getting value and is able to clearly articulate the value they're getting. Sometimes it could be, it could be a different kind of value. I got my resume photo, like a photo app could be like, I got my photo ready for LinkedIn better. I took a quick selfie and I, it helped me get my photo ready cleanly and I now feel proud putting my headshot up. But it took, I have to go to photo studio and spend $400. I can do it for like $10. So that's a clear economic time saving and cost saving there.

It's— that's why I think like it's so— why I'm so excited about like outcome-based pricing because it's beautiful because it aligns the incentives of the customer with incentives of the company. But I'm surprised we didn't see it more often. Like I don't know, like I know some new companies are doing it, but like I feel like we're kind of in this prime age where, you know, There's like, we're in a transitionary—

it's like we're in a transition period, right, from like, like seat-based pricing or something like that into more of an outcome-based pricing model. And we're all still sorting it out to some degree, right? There's usage-based pricing, which I— if usage is associated with outcome, it's a proxy maybe for it. But I, I agree with you, Mark, I don't see the outcome-based pricing as often as I probably want.

Yeah, I think it's exactly the right— the seat-based, usage-based, and outcome-based. And The more you can clearly get attribution. So it all depends on how much attribution you can get. The more you can attribute the outcome to your, to your product, easier it is to go to outcome-based. I mean, there is a reason that Google never went to cost per conversion. Why? The only thing they can control is a click they can drive to you. But what if your website is really poorly designed? What if all of those things are bad? It's up to you to take the qualified click. And then convert it to a customer. And so I feel like even though you ideally want to go to outcome-based, you have to understand, is everything under your control? If it is not under your control, if the outcome is not— if it's determined by someone else, someone else using it, then you can't— you should basically stop. The outcome should be what you can deliver. It could be a lead, it could be a click, it could be something that's marketing, selling, whatever it is you can deliver. I think therefore customer support Automated customer support is a place where I think we are seeing it because there is much more control because it's going on autopilot mode for the most part.

So the dollar per resolve ticket is something I think is starting to emerge as kind of like a baseline for paying for an outcome.

Right, exactly. Finn, Sierra, et cetera, all of them are going to outcome.

While I think Intercom is doing that.

Yeah, exactly. Or something like Cursor, they are not going to write the code and be responsible. It's not like they're not going to charge Here's an engineer salary or something like that. Here's an engineer. Yeah, I think once I've been— but Devin, that model is more, you know, cognition, factory AI. I think that's more suitable. But Cursor is more of an ID used by engineers while you have an autonomous engineer. So they are using different modalities, so they are pricing in different ways. You're like you said, almost everything starts as seed-based. You get more confidence in the product working. You better understand the context, you better understand what are the things you can control, and you start moving towards outcome-based. So you are going to see, but I think ultimately a product has to, and a founder has to be aware of what they control and what they cannot go to outcome-based if they don't control the outcome.

So this is super interesting, and not to bring us back because I really enjoy this tangent, but I'm thinking about all these things that are important in a product leader, you know, like the focus on outcomes, The customer empathy, the curiosity of talking to customers, even pricing, like understanding pricing and understanding how to align incentive structures between the company and the customer. So kind of going back to our earlier point around maybe if you look back, Gokul, on some of the most successful relationships between some of these CEOs and founders that you've coached and advised and invested in, and these product leaders that they've hired, are there any like signals to you like how do you know that there's like sparks, that there's like magic there? Like what, what it, I'm guessing one product leader is not gonna be the right hire for like a, a different CEO. Like there's like some chemistry that has to happen. Do you think it's like the philosophical alignment on the importance of the kind of things we're talking about here? Like if, if they're on the same page about that, then that's like a really good predictor of, of that.

I actually think, yeah, it's a, I think again, the, the chief product officer role or head of product role is maybe the hardest role decision for many CEOs to make because, um, to hire, because the product is something they've— most product-oriented CEOs have held near and dear to their heart. They are de facto the chief product officer. So I've seen almost every situation I've seen a CPO hired, they have unfortunately left the company within the first 3 months. It's, uh, it's, uh, because they don't know— I think they, they think they need a CPO. What they need is somebody who's maybe one level junior to still not fully take over the reins of the product from them, but to essentially report to them and take over the execution and still be a thought partner. So increasingly I say, don't hire a CPO, find somebody who you can groom and coach who can over the next 2 years become a CPO. Find someone who can be a manager of PMs. And therefore it all comes on again back to the first principle. Do you have already someone in your product team who's already a manager or director. And I can't tell you how many times this has happened, where at least 3 or 4 times I've seen the CPO has left, and then they're like, you know what, I already had this great product director who now thought that they were in line to be the CPO in a year or two, but I suddenly brought over someone on top of them. Now they are thinking of leaving. So now they're going back to them and saying, hey, actually, now there's a path, you know, I realized the error of my ways. I think you're amazing. Let's work with you and let's make you a— let's basically see if there's a path for you to become CPO in the next year. I always feel, I think in the case of— there's a saying that a good engineer— a bad engineer basically costs you one bad engineer. Bad PM costs you basically 10 bad engineers' work, basically, because their leverage is so high, both for good and bad. And so I think— and a bad head of product who's not a good fit with you and your way of thinking, now you want to run product. How you want products to be run, it basically could cost you the company or cost you every single individual.

It's like a bone that's stuck in the throat of the company. It's impossible to breathe when there's that kind of blockage.

These are somewhat one-way door decisions. I mean, exec decisions are one-way door decisions. They cost a tremendous amount of pain to reverse. And so the same is true for board members. So these are all decisions that you need to almost make. I almost say, can you add them as an advisor to start with? Get them as advisor to your company. Work with them for a few months. Work with them for a few months. See how they think around different, different— get them to engage with your team. Get them to engage with other execs as an advisor and then bring them on. I think these are so hard to suss out in a somewhat artificial, time-constrained interview process that I even— this is true for investor entrepreneur also. As an entrepreneur, you want to bring an investor on your board, a founder, or vice versa. This is a relationship that could last a decade. You're going to make that decision after 2 weeks of pitching someone? That is a tough thing. It's like marrying someone, right? I mean, it's a— it's as long a decision, you know, it's like a multi-decade relationship in some cases.

So what's the short— what's the shortest that you've been— you've worked with a company as like an advisor, friend, or something, been kind of in its sphere before joining a board? Because you're on a bunch of these boards. Like, what's the shortest you've found that that could take?

Probably 6 months, I think. Yeah, 6 months, I think. Coinbase, it was 2019, late 2019, and I joined the board in mid-2020. So 6 or 7 months. At Pinterest, I had known Ben Silberman for 15 years before I joined the board. And at Trade Desk, I had known Jeff Green for 10+ years before I joined the board. So those are decades. With Coinbase, I knew of the company well, but I had not known Brian and Emily and team. I knew some of the board members well, but yeah, it was about 6 to 9 months, basically. Yeah, the same is true for boards. I think I always tell founders, never, ever, ever invite someone to join the board upfront. Always work with them for a few months, a few quarters as an advisor. See if they can add value. See how to get together with— have them attend a couple of board meetings as an advisor. That's what I did. I attended a couple of Coinbase board meetings. Just as an advisor, informal advisor, that too, just to see if it's both sides is a good fit or not, and then join.

If you're enjoying this conversation, please check out the links in the show notes to support the podcast. Mark and I do this out of love, but to keep it going, we also need your support. Thanks. And now back to the episode.

Yeah, I think where my head is going also, kind of back in the beginning, is, you know, you clearly are someone who has really good judgment, has made really good decisions of not only where you work, like, you know, you were early at Google, you were early at Facebook, you're in some great boards, you've invested in some amazing companies. So you clearly have figured something out. And I'm curious now, maybe like if you put yourself in the shoes of like that product leader, right? Like maybe that who's like in this like crossroads of like, hey, should I continue climbing the ladder to CPO or maybe should I go back to that AI native company that's really cool? Like, I'm curious One, like, how would you, like, how would you think about what company to join and how do you think about that? And then two, like, like, in what, like, assuming you go into, like, the back to IC, like, what mindset would you have going into that role? Is it, hey, I'm trying to learn as much as possible, I'm trying to, like, do my tour of duty for a couple of years and then get back into the management track? Like, yeah, like, can you walk me through, like, how would you make that decision?

Yeah, um, first of all, I think let's talk about the company choice. I feel the number one thing you should look for is clarity of mission. In other words, does the company have a mission that resonates with you personally? It's basically around alignment with your own— what you enjoy doing on a day-to-day basis. You have to look beyond the sexiness of working at this company to say, on a day-to-day basis, are you going to build— do you believe in what this company is building? First and foremost, forget all the day-to-day. Do you believe in what this company is building? Do you feel this pain? And As a product person, I hope that you've gone out and talked to potential customers of this company, and— or you are a customer yourself and understand what the company is doing. And so you understand the product viscerally. If you've never written code before and you want to go join Cursor as a PM, that might not be a good fit. You're just like seeing from the outset of the company, you don't viscerally understand what the pain is. So is it aligned with what you believe in? Do you believe in what the company is doing? If you don't believe it, you won't give it your all. So that's first. Is the mission clear to you? Do you understand and believe in what they're doing? Second, how do you— yeah, go ahead.

One quick question there. Like, I feel like some companies actually have a genuine mission, some others don't. Like, they're just like, I think that's what we're supposed to say. But I'm like, you know, like, you know, we're helping X thrive, right? And I'm like, how are you doing that? Right? Like, I don't like—

maybe not even mission. Maybe, maybe the better way to say it is, do you believe in the pain that the product is solving? Do you believe that this pain is real? This pain is visceral. This pain is something that you yourself will be excited in going and being part of over the next X years. And you feel like you'd be excited. I think one interesting tell is if a company is building a product, say, for accountants, and you actually have never sat with accountants— accountants can be quite— they're a unique kind of person. Or HVACs, for example, right? HVAC companies. If you join a company and your job is to talk to HVAC companies every day, Will you be able to do that on a— so you owe it to yourself to go and spend some time with HVAC companies beforehand and see, would you like to do this on a daily basis for the next X years? Or even be an IT consultant. I always say, go and be an IT consultant to an HVAC company before you start a company servicing those companies. So either case, not necessarily— you're right, highfaluting words like mission are hard to understand pragmatically, but it's simply, is the product something you believe in? Is the product something that you care about? Is the product customer of this product someone you care about and you feel like you can be in that audience for 4 years, 5 years, 6 years? Second, I think you have to— I think maybe the best way to say this is trajectory over status. I think you can't look at the company or your own role as it exists today. Is this company on a good trajectory? I think one of the worst career decisions I ever saw made was 20 years ago when a friend of mine chose VP of Product at Yahoo over Product Manager role at Google. And it seems crazy in retrospect, but in 2001, Yahoo was king of— I mean, they were a $100 billion+ company. Google was extremely young, not clear. They had excellent technology and they offered one of us a PM role. They were just one of the first PMs, or VP of Product. And they chose VP of Product at Yahoo. It was a very rational decision. But they were not looking at trajectory of the company. And so I think you've got to look at trajectory of anything, of your career. Once the company is on a good trajectory, I think, is it growing fast? Is there momentum? I think you have to behave like a venture capitalist almost in some ways, because you are ultimately investing your career into this company and it's an irreversible decision. So what is the trajectory of each company? When a company has plateaued in its trajectory, you're basically going to see the pie flat or shrinking and everyone fighting over things. If the company is growing, the pie always expands. And I can't tell you how many of, how many of like just good people just have, just by being at a fast-growing company, you just get promoted, you get more responsibility, you get more impact, you work on more interesting things because people are not fighting over a fixed or diminishing pie. No one has time to fight. Everyone's busy doing stuff. And so you want a company that's expanding, that's growing and not flat or shrinking, broadly speaking. And that expansion can be on many dimensions. Top line revenue is probably one dimension. Customer growth, customer count is another dimension. Just, you know, cash could be another one, which is hard to quantify. You know, even how many of your customers and revenue are probably the right ones. But in general, you want the trajectory to be strong and growing, I think, over a flat company. I think now again, it depends on where in your career you are. Are you harvesting? I call it the sowing stage of your career and the harvesting stage. If you're in your harvesting stage, which is I think the last 5 to 10 years of your career, you might just say, look, I don't give a crap about all this, I just want to make the most money possible. And there are people who say that. I know.

No, no, let's, let's, let's, let's get more specific because I think like it's helpful to have almost like a persona as we think about decision. So let's imagine, uh, someone who's experienced some success in their career, they're not ready to retire. Let's say that they've got at least another 15, 20 years of productive work ahead of them. They like working, they— but maybe they haven't had like that massive home run, right? And, and they're looking at these companies, then they really want this next one ideally to be a big win. Okay, so maybe that's like one of the lenses that we, we could kind of put on as we we evaluate this?

And I think the big win is a good— there are many ways to quantify a big win. There's a financial big win, but there's also career big win and a network big win and a skills big win. There are many, many different ways. And I think the first— the latter three are actually much more important than the first one. The first one will happen if you're at a good company. That's a reality. It might not happen in a massive way. Sometimes it'll happen if you're at a good company. It is going to go public. I've been lucky to be part of four different IPOs. And I was like a pretty junior IC when I joined Google. It was a very solid win. And the reality is if you're at a good company, which is growing fast, you're going to have a good win, but you're going to have a great win in terms of network, in terms of— so what are the other things to think about in terms of trajectory? One is talent density. I think if you click on a company like Ramp, Ramp actually at its core is somewhat doing something boring, which is like corporate credit cards, but they have incredible talent density. So I think if you look at— there were a lot of studies, maybe it was on your thing, Ben, I saw somewhere, like, I think the number of entrepreneurs coming out of Ramp is extremely high compared to one out of every X PMs is becoming a founder. So that's a good signal of talent. Palantir is another one. Talent density. You want to be around people where there are people going to go off and do great things after this company. And so I think that's a great signal because Guess what? One of the primary reasons I'm at Facebook is because I worked with many of my colleagues at Google, went on to Facebook, including Sheryl Sandberg, who then pulled me on to— who advocated for me to join Facebook. And basically I joined Facebook. And so it was because of Google that I ended up joining Facebook. And because of Google that I ended up joining Square, because one of my colleagues at Google, Ajit, he told Jack Dorsey that Gokul is one of the best product people he's worked with. and then they reached out to me to recruit me over to Square. So when you work at a talent density, talent dense place, you basically have— and you do a good job there, you have advocates then who are going to go out into the world and work at other great companies, and they're going to pull you. And every role from there on, you're going to be going— I always think of roles as vertical, horizontal, or diagonal. You're going to go into diagonals. The vertical is when you're going in the same, in the same, in the same path, like you're a product manager, you become a group product manager. That's vertical. Horizontal is when you go into a different. You're going from PM to becoming a designer engineer. Diagonal is the best, where you're growing but you're doing multiple domains and you're rising up. So moving from being a product leader at Facebook to being a head of product design and engineering is an interesting diagonal role. Moving from being a product design engineering leader to being a GM is another interesting diagonal role. You're like running multiple functions. And ultimately in your career, you do want to— there's a great book by Ram Charan that is— I forgot what it's called. It's about career progression, you first start as an IC, then you become a manager of ICs in your function. But then the goal is to become a multifunction, multidisciplinary manager. You manage multiple functions and then ultimately you manage P&L as a GM or CEO of a company. How do CEOs— I mean, CEOs are not— I mean, Sundar was a PM, was a good friend as an IC PM, and then he basically took that path and now he's the CEO of a large company. Where was I though?

Oh yeah, so because we were talking about, we were talking about mission alignment being the first thing, the second thing being trajectory over status, and then we were just unpacking, double-clicking into trajectory.

Yeah, and density is the third thing. I think, uh, I interviewed with a company called D.E. Shaw, one of the first companies I interviewed with very, very long ago.

And, um, you're a hedge fund, right?

Or hedge fund, hedge fund. Yeah, out of my graduate program in computer science. Uh, the reason I interviewed with them is they had published an article in Dr. Dobbs' journal which was an old-school hacking thing, which I used to read, saying hackers wanted. And they didn't even put their name there. They said hackers wanted. If you think you're really good at what you do, here's the email address to send your resume to.

Good marketing.

Yeah, who could resist that? So I said, I think I'm good. So I sent it, and then I went in, and it was the toughest interview I'd ever been in. And I thought I had failed that interview. I thought, there's no way. And then when I got a job offer, there's nothing I could do but to accept, because it was such an interview. And the same thing happened with Google. I thought, there's no way I'm passing it. Every stage I thought I failed the interview. Every stage, the phone interview, I was like, this is it, there's no way. Wow, you come in. Wow. And then I failed. I talked to Marissa and Susan and so on. I thought I'd failed the interview. They gave me an offer. So I think when your interview process is so strong that you feel like you failed and that every person you meet is basically the smartest person you've ever met, that's the kind of company you want to join where you are not the smartest person in the room because Truly, that's the talent density. You look where you know that they're going to hire amazing people. Everyone who's passed this interview and gone on, you want to work with those people. And then founder, I think I cannot stress deeply enough. I was very lucky to have an interview with Larry Page towards the end, and it was just mind-blowing. And so, and I've somehow been lucky to meet with the founder of every company I worked at before I have taken the job. So I think you get a chance to understand what their vision of the world is and their grit is. I always feel one interesting thing to look for in founders is how dissatisfied they are. They are kind of somewhat always unhappy with the state of the world. And sometimes you don't realize this till later, but they just never— they never tell you the company is doing well. They're like, here are the things that are wrong with the company. And reading their interviews, et cetera, you kind of never hear that much chest pounding. Maybe you hear an earnings call, but at least when you hear interviews, you're like, here are the things we can do better. You want someone like that. I think even as an investor, I truly always look at founders who, as soon as you say, as a founder becomes complacent, not even complacent, they're happy with the way things are, that's, I think, the beginning of the end. You have to have founders. I mean, if you still look at interviews with Mark, with Zuckerberg, you basically see this guy still is like, thinks that he's the underdog, right? Even though Facebook is, say, one of the top 10 most valuable companies. And that's his superpower. That's his secret.

He also looks like he's having so much fun. Like, I don't think I've seen anyone look like they have that much fun in my life as much as he's having. And, you know, he would do those like weekly Q&As even, you know, after you left when I was there and still talk to the company for like a whole hour every week. And, you know, it's kind of hard to fake energy and excitement, I think, that consistently. And I agree with you, he's probably dissatisfied, but also I 'Cause I was, as you were talking, I was like, there also has to be though something that's like exciting about that founder. They can't just be this like grumpy, like everything's broken all the time, right?

They're showing you a vision which is so clear where you're like, I'm going to follow this founder. I'm going to walk through a bed of coals to follow this person. And so when they talk to you, when you say, what are you building? They're not just, when I talked to Tony Xu, which was many years ago, he said, we are going to reinvent local commerce. I'm like, you're just a food delivery company. Who else is, what is the order? No way. And turns out that he was right. I mean, over a period of years, systematically, Exactly. It's again a 10, 15, 20, 30, 50-year vision. And so that's the thing. That's why founder CEOs are so awesome, I feel, because they can think— they're truly the folks who can think extremely long term, while any executive, however good they are, it is just hard for them because they're beholden to shareholders and board and so on. They are beholden to take more short-term decisions. I always used to feel when we used to do product reviews with Larry and Sergey, that they were the biggest risk takers and all of us were much less risk takers than them. They would just say these strong things and we would be like, but that would put the company at risk. And the biggest thing that Google did, which I thought was— Google actually promised more cash and guarantees than they had on their balance sheet to AOL when they made the first guarantee to AOL. And of course, the reason they did that was AOL was a bigger property than Google back then. So advertisers wanted to advertise on AOL instead of Google. So instead of, say, AOL, instead of building your own ad platform, why don't we build the ad platform for you? So advertisers come to Google, and then Google AdWords runs on AOL, but we will guarantee you more money than you would ever make. So basically, by guaranteeing that money, more than the amount of cash that Google had, they basically ultimately made the advertisers come to them, which of course was the beginning of AdWords. They were able to build all that auction. So I think that's the company betting move, essentially betting that more cash you're guaranteeing. It's almost like you could argue OpenAI is doing some of that stuff. They're essentially spending more money than they have, or in theory could even have, in over the next decade. They've already made that many deals.

Yeah, it sounds like courage, almost like courage is like another big one there as well. Like, you have to be brave.

Who's making bold bets? You want to follow it swinging for the fences. Yes, some of those bets might go wrong, but you know that They want to build a meaningful and massive company. That's a great way to frame it. Courage.

Ben, keep us honest. I know we have a second question, but I actually do want to go back.

I think we're actually talking about mission trajectory. I think those four things. Yeah.

So we have, well, Ben, we have the second part of the question around like, and how, which mindset he would go into.

But before we do that, I do want to go back into one thing.

That I think is actually really important is the trajectory over status. So I actually have a really hard time with that one right now, especially with tools like, let's call it like the prototyping tools or a lot of these AI tools, right? They're like going from zero to like 9 figures in record times. And I'm looking at that as like, wow, that's an incredible trajectory. At the same time, I talk to people and they're like, oh, like one month I'm using this tool, the next month I'm using this tool. So it's like, It's like, can you trust that trajectory? Like, is that— or does that matter? Is that like a question worth asking, right? Like, is the trajectory—

is Lovable, Lovable one of the companies you have in mind as we're kind of talking through this? Or like, one of them? Yeah, yeah.

I think, I think it would be— I personally think it's a great company to work at. Why? Because I always say, what's the worst thing that could happen? I think you're basically going to learn a bunch of great skills. In one or two years, it's going to be clear if the trajectory is durable or not. Hopefully it is for their sake. If it's not, guess what? You worked at Lovable. Building a product that's used by millions of people, a true AI-native product, you improved it dramatically. And in 2 years, guess what? You can probably go to any other company, and by that time, maybe some of the durability stuff will be clear. At that point, you've learned a bunch of great skills, you've worked with a bunch of great people. So I think actually it's a great thing to work at Allowable or Cursr if you care about that mission. If you feel like— if you— if I would actually— absolutely, if I were in that role, I would absolutely take a company because it is a well-known company. The reality is what matters. Working at a well-known company, I can't tell you how much power there is to work at a well-known company. If you worked at a company like— I heard the name of ERP yesterday, which is apparently bigger than NetSuite. It's owned by a large PE firm. I'd never heard of it. It's like doing hundreds of millions of dollars in revenue, you know, maybe a billion dollars in revenue, but I had never heard of it. And if someone told me they were a PM there, I would have— and if I see a stack of resumes, like many times that's what happens, right? You see a PM who worked at Lovable and you see a PM who did some AI stuff at this PRP company, which was like a PE-owned thing, I would just take the PM from Lovable because it's more likely you've heard of them. And I can't tell you how much it's bias, but the reality is human. Now you could argue that AI is going to not have the bias, but there is a hiring manager on the other side. When you see a PM working in Lovable, you know that they have basically, you know, they have worked at an engaging product used by millions of people and they worked with a great founder. They've probably been close to, you know, they've been close to company building and done all of these things. You can't really put a price on that.

Talent density is probably too— yeah, okay, just one quick follow-up on that and then we can go to the second part, which is reading between the lines. I haven't heard you in anything I think we've talked about so far, Gokul, talk about how one of top 3 things you care about, either as an employee joining a company or as an investor looking at an investment, being a moat. Like, it sounds like— and I'm not saying you don't care about that, but like, where would you place something like that in this discussion? Like, how important is it to you that there's some kind of moat?

I think moats are built over time. And they— I think moats are built over time. So early-stage companies won't have moats. You can have theoretical— everyone can articulate some moat or the other. But the reality is the best moat is if you're building excellent products and keeping your product keeps getting deeper and deeper over time. So you're owning critical workflows. Ultimately, the best moat is a brand, right? If you think about, I think many of these companies, you could argue that Bing at some point did claim that they were very close to Google in terms of quality, but Google became such a verb that we just went to Google despite not even despite there being other alternatives. And I think the same is true. I think great founders and great companies build moats over time. These moats are not obvious. It is not obvious, Google, that building Chrome would even be a possibility. We all say it is a moat, but for the first 7 years there was no Chrome and we had to compete without it. So I think as a company goes more successful, great founders do build an array of things around the core jewel to build the moat. But so I don't think it's something you can plan over time. It just comes if you have good people, good talent. That's what Sundar's top accomplishment was. He built Chrome. That's incredible. But that was a project that came out of— if Google didn't have the talent density, they would not have been able to build a browser from ground up. So I don't think that moat is something you should consider even as a— because great companies build their own moats over time.

It's almost like the score takes care of itself if all the other factors that you mentioned are true. And eventually you'll build a moat.

Yeah. Being able to ship fast, good people, they will figure out moats over time.

Yeah. You need something that's worth defending in order to have a moat.

Great statement. Yes, exactly. Exactly right.

Exactly. Okay. So, so yeah, let's, let's, let's start. Let's wrap. Let's wrap with, so, okay. So. Gokul is this candidate that we're talking about. You're determined to go into this, call it super IC kind of role in a very hot company that's checked all the boxes for you and, and like, love the founder, love the mission, want to talk to customers all day in the space. I think it's gonna be a very talent-dense place for me to grow. Mark, was the question kind of like, how do you approach coming into the role and crushing it?

Yeah. Like what, what is your mindset? Yeah. Like, like what, what mindset do you have in? Are you thinking, hey, like I'm just trying to learn as much as possible. Do you have like a kind of goal in mind of like, here, like, what is the thing that you're prioritizing? Is it like, yeah, like learning? Is it like making it back to that management role? Like, yeah, how would you start that role and with what mindset?

I think if you have experience at companies, I mean, versus a fresh grad, hopefully the one thing you come up with is never be afraid of taking on work that other— I think success comes by taking on stuff that others are afraid to take on. And so I, I remember before I joined Google, I was at a hardware company. I was a product manager at a hardware company, 1.5 years. It was the hardest product manager I've ever done because hardware companies have this thing called bill of materials or BOM, as you might know, which is like COGS. And it's not just like software, it is literally, you have to source all these cards. It was an optical amplifier company. It was an extremely hard technical product. But also we had Cisco as a customer and Cisco forced me to basically, and I was an early peer in my career. It's crazy. They forced me to give a price for them because they guaranteed a certain volume. And they said, oh, what's your price out 2 or 3 years out? And we had projected our BOM would go down and it would be gross margin positive. We gave them a price. They said, we want the price today for that. So basically they forced me to give a price without any clear volume indication, which would be very gross margin negative for the next 2 or 3 years. And so I felt really— I just really stuck in my psyche for a while. It just stayed with me. And so when I got the offer from Google and I was going there, the day, first day, I told myself, whenever anything tough comes up in this world, in Google, I didn't know what was expected of me. Whatever comes up, remember the toughest time you had as this thing. Nothing is going to be tougher than that. Just raise your hand. Always be enthusiastic and energetic. I cannot tell you how much enthusiasm, energy, and willing to do stuff take stuff off your manager's plate that basically they don't want on it. I think number one thing for success is figuring out what does your manager— how to give leverage to your manager. I think many people don't understand this, how to take stuff off their plate and be the kind of person you're constantly keeping them in the loop, but just getting stuff done. Being the kind of person that gets stuff done at good meritocratic companies goes a long way. So figuring out what your superpower is and making sure you're putting yourself in a place where you're getting stuff done on that dimension and having a very strong— I think the more naysayer you are, if you're always questioning things, I think you get known as a person who's impeding progress. So you've got to use that carefully and thoughtfully. But once things are decided, a decision— and I always feel like there are two-way door decisions and one-way door decisions. With two-way door iterations, the most important thing is figure out how to quickly set up a framework with a hypothesis and experiment, run it quickly, get the data, and then figure out if it's worth— instead of trying to argue for 6 weeks about whether to make iteration or not. With one-way, clearly there's only a few one-way door decisions, and so those are— you have to take time arguing. So really, it's not worth too much time arguing. Let's just like run the experiment fast, articulate the goal of the experiment to prove something, run it fast, get the data and see what— so really focus on speed. I think AdSense, which is a product I was known for, which is a product I built at Google, that thing launched in 3 months from zero, 3 or 4, 3 and a half months, which was the fastest ever for a Google product. And so that really— I just focus on cutting through crap and just launching it. I think Sergey suddenly came in and reduced our— we were going to launch in September. He said, I want you to launch in June. So he cut it from 6 months to 3 months. At that point, we were like, okay, what do we cut? So I became really adept at just cutting stuff to launch. I didn't even argue. I think we argued a little bit, but he said, no, this is what it is. Okay. It was actually a great thing because it forced us to launch something and get it out there. So being known for speed, being known for moving fast, being known for having good judgment and getting stuff done, taking a high-level directive, figuring it out. And I think many of these chaotic early places don't have much process. I remember writing a PRD for the first time, which was a really bad PRD. Very, very bad in 2003 because I'd come from this hardware place. My PRD was very much in the technical details. It was really bad because it actually even like talked about database schema and so on, which is kind of insane. But Jonathan, who was a VP of product, sent it out to the whole company at Google, all of Google, saying this is how PRD should be written. I was like, holy crap. I still am always— and because Google had never had PRDs before, had never had PRDs before. So I think being known as someone who just gets stuff done, because getting something out there, not being too precious about stuff, moving fast, getting stuff done, and having enthusiasm and energy, they override everything else. The first 3 months of your career at any company is going to be how you're going to be remembered. That if you do a good job in your first 3 to 6 months, you can— I shouldn't say you can coast, but you can carry it. It'll give you a lot of great stuff. The first 3 to 6 months go badly, it is— you've dug yourself into a hole which is very hard to dig yourself out of.

Is there something you see people think they should be doing in the first 3 to 6 months that you think is terrible advice, or something that you think is something that, like, people you've managed have come in thinking they— like, this is an expectation in the beginning? For example, like, the first 30 days, like, just learn, right? Like, do you believe that's bullshit, or do you think it's actually a good idea to take some time before you start to, like, I think the more you're a leader, the more you should learn.

That said, I think it is still very important in the first 30 to 60 days to have a win. I think if you're just in this mode, if you're not showing a win, people are constantly judging or like have expectation that you are getting something done. I think after 60 days, if you not have something, it could be— that's why I think being an IC is good, because you can actually jump in and get a feature launched, check in a piece of code, get a design done, something that you can point back and say, I did this, write a PRD. Something, change a process. If hopefully you can do something more than changing a process. So I do think you're right. It's important to learn, but it is equally important the first 60 days to do something that the organization can remember that, yes, this person is not just someone who's just sitting around attending a ton of meetings and speaking. That's fine for the first 3, 4 weeks, but then the half-life on that patient's organization patience goes down.

Yeah, there was a saying, just one last thought, Mark, and then feel free to land us. But Gokul, as you were just talking, there's a saying that came to mind, which was, I forget where I heard this, but basically opportunity shines where responsibility has been abdicated. I think it was something along those lines. And so to your point, like when there's, you hear these conversations happening and you just be like, I'll take it. Like I'll grab this.

Run towards a vacuum where there's no, exactly. Run towards a vacuum. AdSense, actually they tried to hire PMs, but I didn't want to manage anyone or even have, I basically said, I'll be the billing PM. I'll be the frontend PM, I'll be the PM for like 6 different targeting PM, etc. So slowly there were more people brought in and I managed the team. But for the longest time, because I was like, it'll take time to hire somebody, someone needs to do it. I'll be the PM, I'll be the PM. So I was literally working with 3 or 4 or 5 different teams over time, engineering teams as one PM. And I think you're absolutely right. I love that statement. Opportunity shines where responsibility is abdicated. Yes, exactly. But again, the first thing is you got to do the core thing well. I think the other thing I do think it's important is if you don't— your manager has brought you in to do something, make sure you're doing that really well first and foremost, crushing it, and then taking on more stuff. Don't try to take on more stuff before— if you're not doing the core thing well, take on more stuff after your core thing is doing well.

Yeah, there's almost like an underlying theme of like that you explicitly mentioned it, but like having like a low ego almost of like, you know, nothing is beneath me. Like I'll do whatever it takes.

That's what I told myself. Nothing is beneath me. I literally said something very similar. Anything they ask you to always have a smile on your face, volunteer for the tough tasks and say, yes, yes, sir. Yes, ma'am. I got this. I got this. Ask for help. Don't be afraid. Don't be too proud to ask for help. Ask for help. That's the other thing, people. I'm expected to do it myself. No, no, you're not. You have a team around you. You have a manager, you have peers. Ask them for help. How are things done here? How do I write a PRD? Show me some examples. Ask them for help.

Yeah, you're making me think of— I think it's like a term that Keith Raboi popularized around like barrels, and like you want to become known as like a barrel, like someone who can— like when stuff goes into this person's world, it just like boom, just happens, right?

That doesn't mean you're doing it as a solo hero, right? Many barrels have great relationships across a company that allowed them to essentially leverage other people and get their knowledge and then get it done. Very few barrels are just going to do it themselves in isolation. Yeah, it seems like the way you build those relationships and like get ammunition together to fire.

But too much ammunition with not enough barrels, nothing gets done either.

Correct. But it seems like the way you build that social capital is by actually like getting things done, being fun to work with, and just having that contagious energy that people are like, oh, I want to be around this and whatever form it takes. And that's how you got pulled into Facebook.

It sounds like, because Sheryl Sandberg saw you.

I had only 3 or 4 meetings before that, but I think she saw my energy. She saw, basically, she heard about maybe I believe to get stuff done, etc. And yeah, that caused her to say that, yeah, Gokul should come and run ads at Facebook.

This has been awesome. I just have so much respect for you, Gokul. Like, I feel like you still carry that energy of like high energy, low ego, even though you're like a total legend. Like, you've done so many cool things.

It's actually presentations. You know, a lot of people think it's about the content. I actually think it's about the same content. It's about presentation. I think, yeah, I think why is my energy high? Because I think if you think about what our job is, we're basically talking and making, typing on a computer. Think about 50 years ago, we might be in a factory doing hard industrial work, or 100 years ago at that point. We have such an easy job compared even today. I mean, we probably are in the 1% of the 1% of the 1% compared to if you look at the 7 billion people. I mean, we are so lucky and privileged. I know we have all these first world problems. How can we not be energized with the life, lifetimes as short, as long as they are? I mean, we work on something we enjoy doing. So I think all these small irritants have to be put in the bigger context. And so we have to remind ourselves to be grateful. And when you are grateful, I think you get energy.

Amen. I think this is a perfect place to end it. Two final questions for you, Gokul Rajaram. One is, Where can people find you and then how can our audience be helpful to you?

Gokul Rajaram on X and then just my name. It's actually the same content on LinkedIn and X. I have some content resonates more on LinkedIn, some on X, so I just post on both. Anyone and anybody who has interesting ideas, I'm an investor now, so I'm always looking to meet founders, even to just help them even if I don't end up investing for some reason or the other. So if you have interesting ways that you're looking at the world, please ping me at, you can find my email address, gokulr@gmail.com. Happy to take emails and I'll be fairly responsive, I promise.

Amazing. Thank you so much. This has been a real pleasure. I've learned so much and I'm excited to re-listen to this actually. So this is great.

And thank you, Mark. Thank you. This is amazing. I learned a lot actually. I've taken some notes. I was typing as you were saying some things.

Yeah, super grateful that we were able to make this happen. And this is a wrap. Thanks, everyone.

Thank you, guys.