Invest Like the Best with Patrick O'Shaughnessy
· Patrick O'Shaughnessy
[00:00:00] S0: My guest today is Gokul Rajaram. Gokul is one of the most prolific product builders of the last 20 years. He’s built the core ads and product businesses at Google, Facebook, Square, and DoorDash, working at each company during its most formative scaling periods. Alongside his operating career, Gokul has invested in more than 700 companies, giving him an unusually broad view into how products are built and scaled. This conversation is about how product building is changing with AI, and what remains durable when software becomes increasingly cheap to create but hard to defend. We discuss the one thing Gokul believes is truly future-proof in AI, why companies like Zendesk and Slack are more exposed than Salesforce and NetSuite, and the few sources of defensibility. We also talk about everything Gokul has learned from helping build the most important ads businesses, including the only three ways an ads business can make money, how those constraints shape product decisions, and what consumer behavior change threatens every major platform. Gokul shares lessons from working with Larry and Sergey, Mark Zuckerberg, Jack Dorsey, and Tony Xu, and what he learned from watching each of them build generational companies. Please enjoy my great conversation with Gokul Rajaram. I thought an interesting place to start would be the changing nature of how people are building products. The biggest story by far in technology seems to be Claude Code or Claude Cowork as well. The ease with which both technical and non-technical people are able to build something that they can imagine. It seems to have been just a complete explosion in their ability to do so. You've built a million things. You've invested in 700 companies watching people build things. You're about as prolific as they come as a product person. Maybe just give us your state of the union of how the world feels to you in terms of technologists building products and how fast that's changing.
· Gokul Rajaram
[00:00:00] S1: What is interesting about product development is that 10 years ago or even five years ago, there were very clearly defined roles. Product managers articulated what to build, designers designed it, and engineers built it. Over the last few months, I've been talking to many companies. But over the last two months, in particular, December ‘25, and January ‘26, it's become very clear that something has fundamentally changed. And what that thing is, is the notion of a long horizon, a long-running agent. I've experienced it myself. About six months ago, I tried to use Claude Code in the early days to build something. I call it a video transcription tool. I've tried to build it. It kept failing. And then I had to go in and try to debug it. Ultimately, I gave up. Two weeks ago, while watching some episode of some TV show, in one hour, I was able to basically prompt my way to a good video transcription tool. Because these agents now are resilient to failure, and you don't have to be very technical to use them, this changes the expectation of product teams. After I did that, I started talking to three kinds of companies. One, portfolio CEOs of companies I've invested in. Second, the large AI labs. And third, a bunch of AI-native young companies, to see what the similarities are between them. A few things that emerged. First, product development as we know it is changing, because the models and the capabilities are growing so fast that if you try to be very strict and stringent about describing exactly what you're going to build or prescribing what you're going to build, it is going to not work. So almost everybody has gone to a bottoms-up approach, where it's not done by product management anymore. Product managers, the only thing they do now is they articulate what the customer needs are at the highest level, and then they are the guardian of the why. But the actual product is built bottoms-up by engineers, researchers, and product managers, and designers all working together on the code itself. So, capabilities and models are changing very fast. Whatever you think of six months ago, if you continue thinking on that dimension, you're falling behind. It's very, very important for the product managers to be understanding of what these models are capable of, and to be hands-on.
· Gokul Rajaram
So they sit with the engineers and the researchers and write code, do prototypes, do anything and everything it needs in a hands-on way. The first thing we are seeing now happen is that PMs are starting to check in code with either Codex or Claude Code, into the actual production repository. Right now, engineers have to review the code, but you're going to soon see that Claude Code, Codex, and other tools actually review the code itself before engineers commit. So all the companies are struggling with how to evaluate these people. Earlier, there was nothing called a prototyping interview. Now, there's an explicit interview, in the interview loop called prototyping. It literally forces product managers to be hands-on. Second, the product manager and designer role are merging increasingly. The designer role is an interesting role in particular. A lot of companies are going through headcount allocation this year, and I'm hearing from many teams that when given the choice between an extra designer and extra engineer, they're saying, "You know what, the design systems are already laid out. Now that we have the design systems already laid out, we can use AI to do work around these design systems. So we need maybe a small number of designers at the company level to manage the design systems and the design language, but AI can leverage the design language to do designs. So please give us an extra engineer." The number of designers and product managers relative to the number of engineers, when I was growing up in product, it used to be 1:3 or 1:10. It's going to 1:20 now. And then I think the other very, very important thing that's happened, which is fundamentally different is – when I was growing up, products were deterministic. Where there was a workflow, you knew if a user did X, Y happened. Today, you could do X, Y happens. But if you do slight variation of X, something completely different happens, non-deterministic software. What that means is, you have to be on the other side, an evaluation, or what is called evals in AI. And someone has to evaluate whether or not what the software is producing is reasonable or not across various use cases. Obviously, they can be human evals, AI evals, et cetera. But who owns the evals? It's the PMs. It's the PMs and the researchers.
· Gokul Rajaram, Patrick O'Shaughnessy
So the PM's job is to be very clear at a high level about what the user needs are, and then have a very clear sense of whether this product is good to ship or not by evaluating it. Many times you've got to write AI yourself to evaluate the results of AI, because humans can't. So PMs are good at coming up with evaluation techniques. It's the non-determinism of software, the speed of which things are going, and overall, the notion that the capability frontier is being pushed out every two months makes it an incredibly challenging, yet incredibly exciting time to be in product development. [00:00:00] S0: If you think about, my friend Zach has this great way of thinking about AI, which is, we had the industrial revolution for goods, and that basically this kicks off an industrial revolution for services. This is an interesting opportunity to ask about what your philosophy of product is. You're such a product-centric person and builder. That's what you've done. That's what you've invested in. As we face down this industrial revolution for services, what is your broadest possible philosophy of product as we enter this era?
· Gokul Rajaram
[00:00:00] S1: Very simple. A product person, or product manager if you call them, their job is to balance customer needs and business needs. The product manager, there has to be somebody at the company who's the keeper of the why. Why are we building it? What customer need are we solving? Why is this a pain point? How intense is it and how deep is it? And second, how does it add value to the company? If you build this thing, solving this customer need, how does the value add to the company? And I think balancing those two is a very delicate act. You can build something amazing that adds a tremendous amount of value to the customer, but doesn't build any value to the business. And you can do something that is awesome for the business by raising prices, but it is value detracting for the customer. So balancing customer needs and business needs at the highest level is what I think of the product. And what it comes down to, in my opinion, over the last 10 or 15 years, I've really gone down to this notion of outcomes. Outcomes, I think, are what define the best product people, and outcomes have to be defined in the form of customer behavior. Because customer behaviors are leading indicators for every business outcome. If you think about it, the simplest thing that a product does is to make somebody go from not a customer state to becoming a customer state. And from becoming a customer state to becoming a loyal customer. And then maybe to become a loyal customer to become a paying customer. Or if you do a poor job, you can go from becoming a loyal customer to becoming a churn customer. So these are all behaviors. Everything you do or build should be attuned to the goal of, what customer state change does it lead to? What customer behavior change does it lead to? So, I tell every CEO I meet that is trying to hire their first PM or doing their first product review; you need to ask why. The only question you need to ask is why. Why are you launching this feature? And you should not let any feature go out if there's not a clear hypothesis behind this feature. And the hypothesis has to be articulated in the form of a customer behavior change. We believe that by launching this thing, the customers will go from doing X to doing Y, or from spending X minutes a month doing this to Y minutes a month doing this.
· Gokul Rajaram, Patrick O'Shaughnessy
You have to have a hypothesis, which is grounded in some data or something you know about the customer, some secret about the customer. [00:00:00] S0: You mentioned at the start, the difference between the video transcriptions tool six months ago versus more recently and how quickly that changed. It's just such a hard future to reason about given the pace of change. So how do you reason about it? Is there anything that can be truly future-proof?