← Return to Index Archived October 20, 2025
The Lead — Oct 20
SUPRA INSIDER · MARC BASELGA, BEN EREZ

#80: Becoming an IC again is how products leaders will stay relevant in the AI era | Gokul Rajaram (Investor and Company Helper; ex-Google, ex-Facebook)

1h 06m / October 20, 2025 /aiproduct / Transcript sourced from openai
All episodes from Supra Insider →·Podcast website →·Listen on Apple Podcasts →

Overview

This episode explores why the “age of AI” is an unusually strong moment for experienced product leaders—especially those who’ve been managers—to move into (or back into) individual contributor roles. Gokul argues that AI has changed the leverage of a single IC, reshaped what “credible” product leadership looks like, and compressed the gap between managing people and producing outsized output directly.

The conversation also goes deep on what great product execution looks like now: customer outcomes over feature velocity, experimentation over “launch theater,” and how founders should rethink hiring heads of product in AI-native companies.

Key Takeaways

AI meaningfully increases IC leverage, making hands-on product builders disproportionately powerful. Gokul’s core claim is that a strong IC with AI tools (and even “a team of agents”) can deliver output previously associated with much larger teams—narrowing the practical output gap between a manager and a top IC.

Credibility in AI-native environments increasingly comes from being close to the work. For product leaders who grew up in the pre-generative era, returning to IC work can be the fastest way to rebuild technical and execution credibility—especially as orgs flatten and rely less on layers of management.

Founders often hire a Head of Product/CPO too early—and pay for it. Gokul notes many CPO hires fail within months because founders remain the de facto product leader. His repeated heuristic: promote from within when possible, or hire a strong senior PM first, then grow into a product leader over time.

Judgment and influence remain “human” moats; execution is what changes. AI can accelerate prototyping, analysis, and drafting, but the hard part is still choosing what matters (taste/judgment) and aligning the org (influence).

Customer outcomes should replace launches as the unit of success. Launching is not success; behavior change is. Without a clear customer outcome hypothesis, shipping becomes “slop”—especially dangerous as AI makes building faster and cheaper.

Moats are built later, not upfront. Early-stage companies rarely have real moats; durable moats emerge from compounding product quality, brand, talent density, and founder-led long-term bets.

Practical Steps

  • If you’re a product leader considering an IC move: do it as a “skills and credibility reset,” aiming to become fluent in AI-native execution (rapid prototyping, short context docs, agent-assisted workflows). Treat it as a tour of duty that expands future leadership options rather than a step backward.
  • Define success as customer behavior change. For every initiative, write a clear hypothesis: which customer behavior will change, for whom, and how you’ll measure it. If you can’t answer, don’t ship.
  • Run experiments instead of “launches.” Start with a subset (e.g., 5–10% or a defined cohort), measure the behavior shift, and only then roll out. If it fails, commit to root-cause analysis rather than abandoning the line of thinking.
  • Bias toward trajectory and talent density when choosing companies. Look for momentum (growth in customers/usage), a high bar for hiring (interviews that feel “hard”), and a founder with compelling long-term vision and dissatisfaction with the status quo.
  • In a new role, get a tangible win within 60 days. Learn the org, but also ship something visible (a prototype, experiment, PRD, or measurable improvement). Early perception is sticky.
  • Run toward the vacuum. Volunteer for ambiguous, high-impact work others avoid—after you’re already executing well on your core responsibilities.

Notable Quotes

  • Gokul: “The leverage equation has changed fundamentally… you could become an IC that does the work of 10 people.”
  • Gokul: “Launch is not success… if a feature has shipped and no customer behavior has changed, did the feature really ship?”
  • Gokul: “Opportunity shines where responsibility is abdicated… run towards a vacuum.”

Full Transcript

Source: openai 1h 06m runtime

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 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 really excited about it. And 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 are 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 were productive. So a single IC, I mean, you earlier, we were managers managing a team of say, 10 people, they were managing another for 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 your career is only two 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, 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. What do you tell those founders? 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 two PMs. You want them to manage two PMs? Get a senior PM who's basically worked for two or three 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 three 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, five, because he hired wrong, then he fired them, then he had to do their job for six 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, yeah. I'm curious if when you talk to those founders about, hey, like maybe hire that senior PM, are there any new like competencies that you're telling them to focus on when hiring them? Or maybe like any existing ones that you think are way more important today than maybe they were like, let's say three 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 a hundred ideas on 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. So with 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 would say, invented at Microsoft. Google in the 2000s made the product manager role a much more agile document with the 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 what is changing. And the roles, I think of analysts, I always feel there are four roles that you're not engineering, analyst, designer, product manager, there's one more, actually, and front end engineer, you could say, back end engineering is slightly different. Those four, I think, will eventually converge into two. So I think you need a PM who can take on at least one or two of these other roles. Why do you say two? Two, because I do think front end engineer, I think into one just seems a hard thing for a team, for one person with four different roles. I think two people in four roles seems more manageable and feasible. Maybe it becomes one as the tools become better. I always found that I always underestimate technological progress. So it might be that in five years, it could be one. But I feel even two, 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 market product managers, analyst product managers, engineer product managers, etc. And so depending on where you came from, you actually 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. And a front end engineer, there's nothing stopping that designer from also being the front end engineer right now. Like an engineer, that's right. Those three, exactly. So those three, I think. And you then have for multiple parts, maybe one dedicated designer. You no longer need a dedicated designer per part, 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 part or dedicated front end engineer per part or dedicated analyst per part. So I think that's what you're going to see. You're going to see more sharing of these crucial resources across multiple parts. But then the PM is the pinch hitter who's basically coming in and doing a bunch of different roles. And 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 you know customers, you know, you have the most obviously on everyone else, but you need to be talking to customers, understand their pain points better than anyone else in the company. 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 when 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 that they 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, you'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 a PM should do. I think another word that I hear of in the LinkedIn sphere or 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, what are your thoughts there? Do you think that's realistic? I know I look at your career and I feel like 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 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're 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 to being a loyal customer. 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 acts as some customer outcome. And why is that important? Because the customer outcomes moves the business outcomes. I tell my CEOs, 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 are 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 bring some 100 features, but look at the best products we use, like this product. It has minimal features. One of the things about great products is that 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, Facebook cafe, 10 years, 12 years ago, had a Square point of sale. And I was talking to the baristas, 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 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, in 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 your 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 that. DoorDash was the best at it. It was excellent because they always, even today, I've never heard of, 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 you 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 we're running. So I think that's the mindset orientation that needs to be there. These are experimenters. These are hypotheses we have. And then you should ask, 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'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 are obligated as a product person or product team to understand why did this, we had these assumptions that this running the experiment will satisfy this hypothesis or prove this hypothesis. Why? Why did it not happen? And you need to get to the 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 were asking five why's or something like that. You can't just throw the experiment away and move on to the next experiment. You've got to follow it through a few times. Sometimes hydration leads to the best insights. 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 candidates 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 such clear behavioral triggers 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? We actually don't have ice cream in the fridge. Sounds like this pretty easy to add, right? So I can just hit a button and bam, that delivery is going to come and it's going to 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 I think the customer has to 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 because 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. The leading indicator has to be usage of the product, because we all know Salesforce, Instance 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 most 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 could be daily, it could be weekly. And that should be a trigger. If they're not using it, it's probably going to be a churn customer. And so you can't just use revenue as the indicator of success in B2B SaaS products. Yeah. 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 three months now I can, 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 quickly reacting to, you know, big customer features. And now like the prioritization question is getting easier because it's taking less time. So I think like, that's like going to be, I have a feeling that's going to be a lesson that people are going to have, painful lesson that people are going to 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 and almost like playbook to follow here to make sure that you're, you're actually, you know, creating customer outcomes. 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 Fonder is going to go to one to really like test those customer outcomes when, you know, you just maybe have like two pilots or three pilots and, and, you know, not, 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 much experience, but it's 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 cost 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, a revenue driven argument, which is have you somehow increased the revenue of these companies? So for example, there's a company I met, which is doing sales coaching and a very young company. And they found that essentially, 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 it'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 pat it 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 a advocate, et cetera. If they're not able to articulate value, none of those things is going to happen. Even if they're paying today, they'll probably churn, the pilot is not going to go through, they're not going to expand, et cetera. 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 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 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. 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. I'm surprised we didn't see it more often. 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 a lot of stories. It's like we're in a transition period, right? From 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 if usage is associated with outcome, it's a proxy maybe for it. But I agree with you, Mark. I don't see the outcome-based pricing as often as I probably want. Yeah, it's like usage is the launch. Yeah, I think it's exactly the right, there's 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 product, the 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 or 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 setting, whatever it is you can deliver. I think therefore, 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. Yeah, like 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. Fin, Sierra, etc. All of them are going to outcome. I think Intercom is doing that, yeah. Exactly. Or something like Cursor, they're not going to write the code and be responsible. It's not like they're not going to charge, here's an engineer's salary or something like that. Here's an engineer. Yeah. But Devin, that model is more 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. 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, like the focus on outcomes, the customer empathy, the curiosity of talking to customers. Even pricing, understanding pricing and understanding how to align incentive structures between the company and the customer. So 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, these product leaders that they've hired. Are there any signals to you? How do you know that there's sparks, that there's magic there? I'm guessing one product leader is not going to be the right hire for a different CEO. There's some chemistry that has to happen. Do you think it's the philosophical alignment on the importance of the kind of things we're talking about here? If they're on the same page about that, then that's a really good predictor of that successful relationship? Yeah. I think again, the chief product officer role or head of product role is maybe the hardest role for many CEOs to hire because the product is something 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. In almost every situation I've seen a CPO hired, they have unfortunately left the company within the first three months. Because they don't know, I think 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 two years become a CPO, find someone who can be a manager of PMs. And therefore it all comes on again, back to the first question, do you have already someone in your product team who's already a manager or a director? And I can't tell you how many times this has happened where at least three or four 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. And now they're 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 your, 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, 10 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, or you want product should be run, it basically could cost you the company or cost you every single engineer you have. It's like a bone that's like stuck in the throat of the company. There's just like, it's impossible to breathe when there's like that kind of blockage. And these are somewhat one way door decisions. I mean, it's exact decisions are one way door decisions. It costs 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 like, can't you, can you add them as an advisor to start with, get them as an 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 relation that could last a decade. You're going to make that decision after two weeks of pitching someone. That is a tough thing. It's like marrying someone, right? I mean, it's as long a decision, it's like a multi-decade relationship in some cases, so. Well, what's the shortest that you've worked with a company as like an advisor, friend, or 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 found that that could take? Probably six months, I think. Yeah, six months. I think Coinbase, it was 2019, late 2019. And I joined the board in mid 2020, so six or seven months. At Pinterest, I had known Ben Silverman for 15 years before I joined the board. And at Trade Desk, I'd known Jeff Green for 10 plus 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. And I knew some of the board members well, but yeah, it was about six to nine months, basically, six. 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 they 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 as an advisor, informal advisor, that too, just to see if 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 clearly are someone who has really good judgment, has made really good decisions of not only where you work, but 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 if you put yourself in the shoes of that product leader, maybe who's in this 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? I'm curious, one, how would you think about what company to join? And how would you think about that? And then two, assuming you go back to IC, 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 do my tour of duty for a couple of years and then get back into the management track. Can you walk me through how would you make that decision? 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 a 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 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, I- How do you? Yeah, go ahead. One quick question there, 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 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 would 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 it's not necessarily, you're right, highfalutin 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 four years, five years, six 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 hundred billion plus dollar company. Google was extremely young, not clear. They had excellent technology and they offered, one was 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. I mean, once a company is in a good trajectory, I think, is it growing fast? Is there momentum? And I think within, 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 like this good people just have, just by being at a fast growing company, you just get promoted, you get more responsible, 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 a many dimensions. Top line revenues, probably one dimension. Customer growth, customer count is another dimension. Just, you know, cache could be another one, which is hard to quantify. You know, even how many of you say customers and revenue are probably the right ones. But in general, you want the trajectory to be strong and growing. I think 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 five 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 enough people. No, no, let's get more specific. Because I think like it's helpful to have almost like a persona as we think about this decision. So let's imagine 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, but maybe they haven't had like that massive home run, right? 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 could kind of put on as 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 a 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 may 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 a somewhat, it's 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 I, maybe it wasn't 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? You then, I mean, one of the primary reasons I'm at Facebook is because I worked with many of my colleagues at Google, went down to Facebook, including Sheryl Sandberg, who then pulled me onto Facebook, who advocated for me to join Facebook. And basically I joined Facebook. And so I'm very, 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 Google 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. We're going to go out into the world and work at other great companies and they're going to pull you in. 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. So vertical is when you're going 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 become 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, and then you become a manager of ICs in your function. But then the goal is to become a multi-function, multi-disciplinary manager. You manage multiple functions and then ultimately to manage P&L as a GM or CEO of a company. How do CEOs become, 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? So career- Because 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. Talent density is the third thing. I think I interviewed with a company called DE Shaw, but it was one of the first companies I interviewed with very, very long ago. And- They're a hedge fund, right? Or- Hedge fund, yeah. Out of my graduate program in computer science. 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. It 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 would 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 rings, I was like, this is it. There's no way. Wow, you come in? Wow. I thought I'd 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're not the smartest person in the room because truly that's a talent density. 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 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're getting a chance to understand what their vision of the world is and their grit is. And 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 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 in here interviews, you're like, here's the things we can do better. And you want someone like that. I think even as an investor, I truly always look at the 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 Zach, 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 he would do those like weekly Q and A's even after you left when I was there. And still talk to the company for like a whole hour every week. And 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, because 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? No, no, no, no, they're showing the vision which is so clear that 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? When I talked to Tony Hsu, which was many years ago, he said, we're 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, 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 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. I think that's a company betting move, essentially betting that more cash, you're guaranteeing. It's almost like you could argue open AIs doing some of that stuff. They're essentially spending more money than they have, or in theory could even have over the next decade. They've already made that many deals. I'm committed to it. It sounds like courage, almost like courage. It's like another big one there as well. Like you have to be brave. That's right, you want to follow the leader who's making bold bets. You want to follow the leader who's 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 were actually talking about it. I think it's the mission, trajectory, I think those four things. Yeah, Ben, we have the second part of the question around and how, which mindset he would go into. But before we do that, I do want to go back into walking. But I think it's 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 nine 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, 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 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 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 two 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 worked with a bunch of great people. I think actually it's a great thing to work at a Lovable or Cursor, 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 BE 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'd 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 ERP company, which is like a BE-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, 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 at Lovable, you know that they have basically, you know, they have worked at a 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 to emerge there. Exactly. 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 the top three 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 is 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 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 was not obvious to Google that building Chrome would even be a possibility. We all say it as a moat, but for the first seven 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 a 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. And, but that was a project that came out of, if we didn't, Google didn't have the talent density, they would not have been able to build a browser from ground up. I don't believe that moat is something you should consider even as a, because great companies build their own moats over time. So it was like, this core 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, great statement. Yes, exactly. Exactly right. Okay, so yeah, let's start. Let's wrap with the, so okay, so Gokul is this candidate that we're talking about. You're determined to go into this, call it super icy kind of role in a very hot company that's checked all the boxes for you and like love the founder, love the mission, wanna 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 in to the role and crushing it? Yeah, like what is your mindset? Yeah, like 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, 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 with taking on stuff that others are afraid to take on. And so I remember before I joined Google, I was at a hardware company. I was a product manager at a hardware company one and a half 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, 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 a 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 two or three years out? And we had projected a 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 very gross margin negative for the next two or three years. And so I felt really, I just really stuck in my psyche for a while and it just stayed with me. And so when I got off 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 gonna 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 decisions and one-way decisions. With two-way decisions, 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 six weeks about whether to make a decision or not. With one-way, clearly, there's only a few one-way decisions. And so those are, you have to take time arguing. So really, it's not worth too much time arguing. Let's just run the experiment fast. Let's 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 three months from zero, three and a half months, which was the fastest ever for a Google product. And so that really, I just focused 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 six months to three 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. 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 a 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 just 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 three 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 three to six months, you can, I shouldn't say you can coast, but you can carry it. It will give you a lot of great stuff. The first three to six 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 three to six 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 world, if you're not showing a win, people are constantly judging or like have expectation that you're 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 right, a PRD, something, change of process. Hopefully you can do something more than changing the 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 three, four weeks, but then the half-life on that organization patience goes down. Yeah, there was a saying, just one last thought, Mark, and then you 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, you hear these conversations happening and you're 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, so I basically said, I'll be the billing PM. I'll be the front-end PM. I'll be the PM for like six different things, targeting PM, et cetera. 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 three or four or five 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've 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, 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 done. Yeah, there's almost like an underlying theme of like, that you didn't explicitly mention 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? And battles doesn't mean you're doing it as a solo hero, right? Many battles 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 battles are just going to do it themselves in isolation. Yeah. It seems like the way you build those relationships. You have to get ammunition and like get ammunition together to fire. But too much ammunition, when not enough barrels, nothing gets done either. Correct. Yeah. But it seems like the way you build that social capital is by actually like getting things done, doing 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 as a- I had been with Sheryl in only three or four meetings before that, but I think she saw my energy. She saw, basically, she heard about maybe our ability to get stuff done, et cetera. 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 true for 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, you'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 a hundred 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. How can, I know we have all these first world problems. How can we not be energized with the lifetimes as short, as long as they are? I mean, we work on something we enjoy doing, you know? So I think these, 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. One is, where can people find you? And then how can our audience be helpful to you? Gokul R on G-O-K-U-L-R on X. And then just my name. It's actually the same content on LinkedIn and X. I have some content residents 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 they 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, G-O-K-U-L-R at gmail.com. Happy to take emails and I'll be fairly responsive. 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're able to make this happen. And this is a wrap. Thanks everyone. Thank you guys. If you enjoyed this conversation, please share it with someone who you think would benefit from it as well. We really appreciate it. We'd also love a follow or a rating on Substack, Spotify, or YouTube. That's gonna let other people find us. And if you have any topic recommendations for a future episode, please send myself or Mark a DM on LinkedIn. We'd love to hear from you. Thanks.