# How Scale AI and Harvey Build Product Why PMs Are Wrong: They are not the CEOs of the Product · How to do Pre and Post Mortems Effectively and How to Nail PRDs · The Future of Product Management in a World of AI with Aatish Nayak 20Product · Apr 11, 2025 · 65 min · 12,821 words Speakers: Aatish Nayak, Harry Stebbings Source: https://www.996.fm/episodes/20vc--ep-d90577c6/ ## Cold open **Aatish Nayak** [0:00]: PMs have a main character syndrome sometimes, that they have to be the CEO of the product, be the face of the product. The first thing you have to do is, is it actually the best thing for the company for me to do everything I do? Domain experts are driving more of the product decisions. You need to bridge the gap between what the model and UX is to how you actually apply it to a certain profession. Those ideas, domain experts will matter a lot more. We did these evals recently. Claude three seven in particular, for legal reasoning, it's better at long form legal reasoning and drafting long form outputs. **Harry Stebbings** [0:35]: This is 20 with ## Intro **Harry Stebbings** [0:37]: me, Harry Stebbings. Now 20 product is a monthly show where we sit down with one of the best product leaders to discuss how they start, scale, and manage the best product teams. Joining me today, we have Aatish Nayak, head of product at Harvey, one of the hottest startups in Silicon Valley, where he oversees product vision, strategy, design, analytics, marketing, and support. This is also his third hypergrowth AI unicorn, having previously held product leadership roles at Scale AI from '40 to 800 people and Shield AI from 20 to a 100 people. But before we dive into the show today, ## Sponsor read **Harry Stebbings** [1:12]: are you struggling to beat model benchmarks or implement GenAI in your product? If so, you need Turing. Turing is an AGI infrastructure company backed by incredible investors like Foundation Capital and Westbridge Capital, and they do two things. Number one, they help leading companies in AI labs like Salesforce, Anthropic, and Meta enhance their LLMs with advanced reasoning, coding, multilinguality, multimodality, and more. Number two, they combine human and artificial intelligence expertise to deploy cutting edge AI systems for awesome companies like Rivian and Reddit. Right now, Turing offers a free five minute self assessment to help you pinpoint your place in the GenAI journey, get tailored next steps to optimize your model strategy, and then finally, learn how Turing can refine and implement your models for better performance. Take the guesswork out of GenAI. Visit turing.com/20vc to start your free assessment today. And once your GenAI strategy is on point with Turing, make sure your team stays just as sharp in the day to day. Hey, managers and leaders. Wanna make your meetings way more efficient and save time? With over a billion meetings processed, otter. Ai is the ultimate AI meeting productivity tool. It gives you real time transcripts, quick summaries, action items, and insights, plus a voice activated agent that keeps you focused and productive. It's unbelievable. Imagine cutting down your meeting prep and follow ups and freeing up more time for what matters. Otter's trusted by over 25,000,000 users, including Fortune 500 companies, to boost productivity and collaboration. So are you ready to take your meetings to the next level? Well, head over to get.otter.ai/20vc and grab a 30% discount when you subscribe to a business plan for your team. That's getotter.ai/20vc. Let's make your meetings work for you. Alright. Meetings sorted. Now let's fix your software. Whether it's the software you build or the software you buy, your tech stack should be creating results, not creating roadblocks. Well, Pendo's no code software experience management platform makes your software better with tools to see where users get stuck, guide them with in app messaging, and constantly improving your UI. It's so easy that over 14,000 businesses use Pendo to increase revenue, lower costs, and reduce risks. Businesses love the control. Engineers love the freedom. Wins. Start for free today at pando.io/20product. You have now arrived at your destination. ## Conversation **Harry Stebbings** [3:50]: Aatish, I am so looking forward to this. I had so many good things. We were literally just talking about HubSpot, and I spoke to Katie beforehand. So thank you so much for joining me. **Aatish Nayak** [3:58]: Yeah. I'm excited to be here, and it's a great day in London for for this podcast. **Harry Stebbings** [4:03]: Dude, it is so special to do it in person. Now I wanted to start. When I was chatting to some of our mutual friends, I heard that you early on made a decision to move from engineering to product. I wanted to start with that, actually. Why did you make that decision, and how does that decision lead your advice to others who might be doing the same? **Aatish Nayak** [4:21]: One big thing I was, you know, always optimizing for is like skill set growth. What are the skill sets you need to know? What are the skill sets I'm good at? What are skill sets I want to get better at? Versus like, is my title a product manager? Is my title a software engineer? So skill set growth was, you know, super important. I think one thing back then was like, you were more bucketed into different roles than you are. So focus on skill skill set growth. And, you know, early on, I think I had read Sam Altman's post on how to be successful. This was before Sam Altman was Sam Altman. And one of the things that really stuck with me was working hard and focusing on something that you're good at and like getting better at will compound significantly over time. He said in that in that post that you wanna try to strive for the top 1% of what you do. And of course, not everyone's gonna get that, but if you have that mindset, then you'll get there. And so I looked at myself and I was like, what do I actually, you know, wanna do? What am I good at? What am I, like, intellectually interested in? And sure, software engineering, I had done a CS degree at CMU. I was above average probably at software engineering, but I realized I didn't really wanna get better. But instead I wanted to get better at things like, you know, commercial sense, leadership, product sense, motivating others, user discovery, you know, things that a more traditional product manager would do. And so ended up joining Shield, where I could put myself in opportunities to flex those skill sets and get better at those skill sets without, you know, the pressure of I'm a software engineer or a product manager. **Harry Stebbings** [5:48]: It's so funny. It makes me think of actually Scott Galloway. He says, don't do what you love. And at that moment you're like, what? That's everyone tells me. No. No. No. Do what you're good at. **Aatish Nayak** [5:58]: Yeah. **Harry Stebbings** [5:58]: And it compounds. Yeah. And then most often what you're good at, you do what you tend to love. **Aatish Nayak** [6:02]: Because **Harry Stebbings** [6:03]: Because you're good at it. And that's why I actually think like parental encouragement is so important early on. Because when you tell children they're great at something, they then tend to love it and they tend to put more time into it and get better and better at it. It's a really important start, think. I have to ask, Scale is a generational defining company in many respects. Just raised $25,000,000,000. It ends this year at 2,000,000,000. Fucking nuts. Yeah. Well done, Alex. You were there for like four and a half years. How did your time at Scale shape how you think about product? **Aatish Nayak** [6:32]: Yeah. I think maybe a few things to touch on. So one, I think, you know, Scale was at the frontier of a lot of different AI movements over the last, like, five, six years. And I think one thing we did really well was listening to frontier customers, customers that are at the frontier of voter we were pushing. And because we were just at the cusp of new markets every single time, it was super beneficial to get deep with those customers because you could have conviction that they would basically define the market and everything they wanted, you know, everyone else would follow. And so, you know, early on in self driving, neuro was super, super early on in a lot of LiDAR and a lot of really hard, what's called pedestrian work, like pedestrian labeling work. And so we ended up doing a lot of kind of custom things with for neuro, getting super deep with them, and then lo and behold, everyone else started asking for the same thing. I think whenever you're at these cutting edge markets and, you know, today today's world is definitely the case, find the customers who are really good at what they do and then, you know, chase them, even overfit to them, as long as you have conviction that, you know, everyone else will follow. Can I just dive in on **Harry Stebbings** [7:39]: that? Often founders are told, don't do anything custom because then it's not applicable to a wider customer set, and then you're just building for one. Yeah. To what extent do you agree with that given the experience you have? **Aatish Nayak** [7:50]: Yeah. So I do think there's this idea of, like, you know, customers. So tough customers who ask for the world, you know, want all this new custom stuff. I think it does take a tremendous discipline to say, what are they asking for that is you think is gonna be very, very specific to them? And then what are they asking for other people are gonna want as well? I think you really have to tease those two apart and use those customers as forcing functions to push what you want forward and say no to the things that are maybe too custom. You know, another example of this is Scale partnered with OpenAI very, very early on before ChatGPT came out. This is like very early on RLHF when they were trying to tune models to summarize better based off of Reddit passages. And this is on GPT two. And this is actually one of my first projects at Scale. We ended up doing something super custom, built a custom product and for labeling Reddit passages. And then maybe two years later, OpenAI was super ahead. Two years later, everyone started asking a lot of this stuff and a lot of the similar needs. And so maybe OpenAI was super early and maybe we were super early, but we ended up using a lot of that again when everyone caught on to the benefits of RLHF. And so it's more nuanced than that, and you need to tease it apart. So if **Harry Stebbings** [9:07]: intense proximity to customer and really listening was one, any others? **Aatish Nayak** [9:12]: Yeah. So another one was, I think you have to reduce the distance between the customer need and the code written. What does that mean? So as companies grow, you end up adding a lot of layers between the customer and the engineer who's running the code. Like, there's a product manager, there's a salesperson, there's the founder, there's a designer, you know, all these people in the way. And ultimately, by the time the customer customer request gets to the the engineer, it's like maybe you lose a lot of nuance, because, you know, information transfer between humans is very lossy. Like when you tell me something, there's no way you can capture everything that a customer said, their emotions, their enunciation, right? It was super important for us to reduce that distance, and what that meant was putting engineers right in front of customers, whether it's the customer like neuro or the contributors, kind of the taskers who are actually doing the work. And so we would actually even fly engineers out to train centers all around the world to literally observe how people are using the labeling products and and, you know, different scale products and prototype and build right there. **Harry Stebbings** [10:12]: Respectfully, with that reduction in chasm between customer and engineer, what is the role of a PM in that world? **Aatish Nayak** [10:18]: Yeah. Great question. I get asked for PM advice a lot. And people say, hey. I'm trying to act as the glue in the organization. And, you know, I'm gonna do this. I'm gonna do that. From founders, I'm getting a lot of signal, customers, engineers, whatever. I think the the the framing that you should probably have is you're not glue, you're WD-forty. Have you heard of WD-forty? Yeah, I have. It's like a industrial lubricant, right? So in the the engine of a company and a hypergrowth startup, like, if you're the glue, that's really bad because things will break down. You're a single point of failure. Your team is a single point of failure. But instead, you wanna make sure everyone else can shine and be good at what they do and, you know, grease the skids or however you wanna call it. And what that means, maybe, is putting the engineer in front of the customer, because customer wants to talk to engineers, and engineers wants to talk to customers, and that gives them confidence. **Harry Stebbings** [11:06]: If I'm a PM, and I currently consider myself the glue, and I'm listening to you going, I wanna be WD-forty. What can I do to be WD-forty where I would have been glue? **Aatish Nayak** [11:17]: Yeah. I think this starts with coming to terms that you don't have to be the star of the show. I've made this mistake, I maybe sometimes still do. PMs have a main character syndrome sometimes, that they have to be the CEO of the product, be this face of the product. The first thing you have to do is, is it actually the best thing for the company for me to do everything I do? It starts with that. It maybe sounds simple, maybe sounds baseline, it just give others the opportunity to shine for the skill set that they have. And then, you know, as I said, putting putting designers, putting engineers in front of customers, giving them room to give ideas, you know, brainstorming with everyone in the room, and a lot of kind of like tactical things, but it really starts with saying, I don't have to be a main character. I just have to make the product and and the company succeed. So funny **Harry Stebbings** [12:01]: you said that about kind of main character that I always hear on the show. PM is the CEO of the product. Yeah. I always find that funny. You know what I find funny? The **Aatish Nayak** [12:09]: CEO **Harry Stebbings** [12:09]: is the CEO of the product. Exactly. So It's so funny. I I had the CPO of Shopify on the show. Yeah. And they said, I'm not the CPO. Toby is the CPO. I mean, I am by title, but not really. Yeah. And I thought it was absolutely fascinating. Okay. So we have those as takeaways. If we think about the core components of what it takes to build an unbelievable company like Scale, you said to me before that markets are the only thing that matter. As a venture investor who thinks about, you know, market, people, attraction, and price, to be honest, European in me. The Americans have zero discipline on price, respectfully. None. We can **Aatish Nayak** [12:46]: get into that view. **Harry Stebbings** [12:47]: I mean, none. Which makes it fun to raise from you guys. Yeah. But market is the only thing that matters. Fascinating. Why? Can you unpack it for me? **Aatish Nayak** [12:55]: Yeah. So I think if you don't find a great market, you'll get killed. There's examples all over the place. Self driving is a great example where five, six, seven years ago, you can say, oh my god. Great market. Everyone's gonna have robotaxis, but extremely capital efficient or inefficient. You have to spend a lot of money upfront to do it. There's a lot of regulatory hurdles. And if you actually look at the companies that did well, it was, I mean, Tesla and Waymo, basically, and they have near infinite data and near infinite capital, and there's a wake of a graveyard of a lot of companies that you end up failing. And you can't say, oh, the founders are bad. No, it's it's like the founders are brilliant. Every single one of them is probably somewhere either now working on LMs or at Weinberg, Tesla or whatever. But I think it's really important to find a market that is huge before you are too late. **Harry Stebbings** [13:46]: I think **Aatish Nayak** [13:46]: that's The like one **Harry Stebbings** [13:47]: Scale's **Aatish Nayak** [13:47]: thing to **Harry Stebbings** [13:47]: market was great. Like, data labeling as a market, is that a good market? **Aatish Nayak** [13:52]: Yeah. So I think data labeling, any type of data intake for, you know, for AI was a great market. I think what Alex and we did well was being able to pivot to different sectors at the right time when that sector was blowing up, you know, in terms of needs for for data. Because this was always a criticism of Scale, which is just a it's just a autonomous car data labeling service. I think, again, what we did well was there was self driving, of course, and we started with that. Well, it started with three d self driving. And then we pivoted to two d self driving. So images, videos, all of that. And then that led to robotics, like warehouse robotics and, you know, other types of robotics. And then that pivoted to government where, you know, if you remember back in 2019, Project Maven was a thing, and the DOD was starting to gear up a lot of their AI investments. And so it was like, how do you like, Scale really, you know, how do you keep finding these new markets where data labeling and data needs were so big? To **Harry Stebbings** [14:49]: what extent was the product requirements the same when shifting from ancillary to ancillary? For you, leading product, how easy was it to be plastic across multiple different verticals? **Aatish Nayak** [15:00]: Yeah. So it was hard, I'll say. I think for vision, like three d and and two d, it was more straightforward. You know, was very operational, so you'd have to tweak the operations to ensure quality for warehouse robotics versus self driving, that was like fairly different. But when we started getting to outside of vision, we had to build brand new products. Like I started the e commerce team at Scale where we were labeling e commerce data like from Meta, from Instacart, from DoorDash. That was a completely different product than the core two d and in three d. And so, yeah, you you do have to build products, but I think, you know, credit to Alex and his tenacity for being able to say, guys, we gotta do it. It's fine. It's gonna cost a thought of thrash, but there's these huge markets out there. One thing I'll also say just on back to the markets thing is conversely great markets can hide execution problems. An example with this is Uber. So there was delete Uber. There was a lot of internal chaos at Uber. So I I interned at Uber in 2016, like, way back when. It was super fascinating to see that. This was when, like, this was kind of, like, their heyday, two k TK, and everyone was, like, really going at it. And 2019 or whatever, there's, like, that delete Uber, there's a lot of chaos. But Uber is standing, and it is profitable, and, you know, obviously credit to to Dara, but the market is insane. Like, robo or just taxis on demand, who doesn't want that? And when the cat was out of the bag that that's possible, everyone was asking for it, right? So I do think great markets can hide some of that. **Harry Stebbings** [16:31]: You **Aatish Nayak** [16:31]: said something **Harry Stebbings** [16:31]: fantastic before. I'm a big, big believer in focusing distribution. I don't think nearly enough people do it. It's a big difference between first time founders and second time founders. But you said if distribution is king, then product is president. **Aatish Nayak** [16:45]: Yeah. **Harry Stebbings** [16:45]: And I thought, give this man a podcast. Can you explain if distribution is king, Yeah. Then product is president. **Aatish Nayak** [16:53]: Yeah. So I think distribution can bring a lot of early traction by sheer amount of brute force. If you look at aristocracies and, you know, kings and kingdoms, like, they bring in soldiers, armies, wealth, take over and conquer lands, but just just sheer brute force. Not a lot of diplomacy. I mean, in general, there's a lot of brute force involved. And you can do the same with startups, like you can do founder led sales, you can do brand, you can do marketing, scale up a whole, you know, sales team, really get far and far ahead. But, you know, the problem is it can get you really far, but it doesn't ultimately last. If you don't follow that with substance, the people will realize the emperor has no clothes. You know, people will see the the falsehood here. And so you do have to follow it with with product. And why product is present? Because prod presidents in, you know, democracies are for the people, by the people, and product, you ultimately want to listen to your users. They all the promises that we've made, you know, you want to make sure we follow-up on that. As of now, hopefully, democracies last very long time and are generally more stable, bring more wealth. And so product will last a really long time. Distribution can get you there really fast. **Harry Stebbings** [18:04]: Does product last a long time in AI? This is a world where we're seeing the commoditization of products and code bases incredibly fast. You know, the distillation of large models in weeks, and these are some of the most complicated models to, you know, bluntly copy. Is there actually such preservation or longevity to product anymore? **Aatish Nayak** [18:22]: It depends on what you mean by product and where you focus. I don't think the foundational models are products. You're seeing this with OpenAI right now. They're they're more pivoting to a product company, and Satya even said this. The reason the image Studio Ghibli stuff blew up is because they have a mobile app that is in everyone's hands already, and that is product. And so I think it depends on where you focus on product. And ultimately, think some of the for us, especially, I mean, some of the longer term moats are the UX that you build around product. **Harry Stebbings** [18:50]: ChatGPT kind of made it the default by consumer expectations. Do you think that chat is the right interface? **Aatish Nayak** [18:55]: Definitely not. It's the command line starting point of of this new frontier, like the MS DOS was, you know, way back when. I I think there's a few things in how, you know, how I think about it. I think one is chat is very linear and very one shot. You put in something and then you get an answer, then sure, you can follow-up and ask questions on top, but real work, you need to gather a lot of information to actually produce some work product, right? You may have to get data from people that you don't even know have that data, or that context, whatever. And so one principle that we use when building products is something called the IKEA effect. The IKEA effect is like, you know, when IKEA started going super viral and super big, they made it super simple and nice and delightful to actually assemble the furniture. And what that did was build brand affinity of like, I put this together. I am responsible for it. Of course, now people hire people, assemble things, but that just created this like cult like following with IKEA. And so for us, how you can start to change this chat UX is like, how can the AI ask for more information or be like, hey, I wrote this first draft of something, give me feedback on it before I continue. Like a real coworker, like a good coworker would do. So yeah, I think chat is the very, very beginning, and I think it's gonna take a lot of experimentation by folks like us and Harvey, by application layer companies, by OpenAI to figure out what is the right interface. **Harry Stebbings** [20:17]: Can I ask you, when you have distribution and you have product as president, you then get hypergrowth and you get amazing customers adopt you and you have this virality that you see within certain circles? And that's why I really like actually vertical software because I think you get that virality much easier because of brands in those spaces. What are the first things to break as you move into hypergrowth in product teams? Yes. Lots of things break. **Aatish Nayak** [20:42]: So maybe defining hypergrowth is every three to six months, let's say, your revenue is more than 1.5 x, 4.2 x, your employee count is more than 1.52 x, like it's a different company every single quarter, let's say, or, you know, half. And so a few things that break are one, it becomes super hard to know what to actually prioritize. Like by definition, you're getting a lot of customers and a lot of demand and people are asking for a lot of different things. You don't know what direction to This extends to engineers, this extends to the founders, PMs, whatever. You just don't know. If you don't provide that clarity, then you're gonna do a lot of the wrong things. That's I think one. And then generally, also get either too many people making a decision or not enough people making a decision. Like you get a lot of kind of tragedy of the commons. Like something's breaking and no one knows who should be responsible for it. Like, you know, for example, product enablement of sales. Who is responsible for that? No one really thinks about that as much, you know, when you're growing a sales team alongside a product team. And Winston put me in charge of it, so now I'm figuring that out. But I think there are just a lot of things that break that don't have owners. And so I think it's super important for the founder to provide clarity on what's important, what to prioritize, why we should do certain things at certain times, and then PMs, engineering team to turn those kind of like that clarity into action plans and execution. To what extent do you push back on founders? I think it's super important to push back on founders, even for the sake of debate, to be honest. You know, of course, depending on the founder. For early product leaders, it's really important to build a really, really good relationship with founders. Maybe that's obvious, but it is important to say, okay, why did you hire me or why do you wanna hire me? Like, what do you actually want me to do? And for product minded founders, they may say, I just want you to execute. I know the strategy. You should do execution, make sure everything, you know, happens. And it's like, that's fine. And you can learn a lot from that. But it's super important to have that conversation on what do you actually want the role to be? Like, I've seen product leaders, product managers kinda end up in bad places because they didn't have that conversation, and then the founder doesn't wanna let go. It becomes really hard. So the CPO **Harry Stebbings** [22:50]: of Spotify said on the show once that talk is cheap **Aatish Nayak** [22:52]: Yes. **Harry Stebbings** [22:53]: And so we should do more of it. Now I disagree with that. I believe in bluntly dictatorships. I think they're much more efficient. Yeah. And a when in a world where speed is everything, they allow for a much more efficient and speedy process. To what extent do you agree in the dictatorial nature of product decisions? Or actually, do you think brainstorming and discussion is important? **Aatish Nayak** [23:14]: So I believe in benevolent dictatorships. So Singapore, as an example. I totally agree. I think it's super important that you have very, clear vision and like execution from the top, because otherwise you're gonna end up a tragedy of commons. And so it is very clarifying to say, hey, we are behind from this competitor, do x, or we need to land these types of customers, do y. And that direction is extremely helpful from the founders. But I think you, especially as you're hyper growing, you end up with a lot of confusion or maybe the details don't actually end up in the way you want if you don't bring your team along the journey. And I think I've learned a lot of lessons from this, seeing Scale. You know, at Harvey, we we definitely have not nailed this. But What did you do wrong? So I think particularly early on at Harvey, we we did the dictatorship. Me and Winston are just like, we're gonna do x y and z and go go go. I think, again, as you hypergrow, you assume everyone has the same context that you do, and that's just not the case. Like, they're not in all the conversations. They're not in all investor meetings. They don't see what the models are gonna do, you know, six months down the road. And so that caused thrash, and the team watching this is probably gonna agree with me. And I think it's super important to explain why you're doing certain things, even if at the end of the day, you're like, please listen to me and please trust me. Because you need to build mutual respect with your team and with everyone at the company. If you've done the right thing in hiring great people, great people want to be told, here's why we're doing things, and then 99% of the time if your reasoning is right, if and it's not, you should debate it. If your reasoning is right, they will agree with you. But just sharing the context, writing memos, having brainstorm discussions, welcoming debate, I think is super crucial as long as it doesn't slow things down and you debate for seven weeks. **Harry Stebbings** [25:00]: When you think about writing those product memos, what does that look like in terms of process and how it's enacted? **Aatish Nayak** [25:07]: Yeah. So there's like an altitude of different product memos you can write. **Harry Stebbings** [25:11]: Correct. Can you dive into it with me? **Aatish Nayak** [25:12]: Yeah. So the top level is what are we gonna focus on as a company? Like, what what actually matters? And it's not this is not features. This is like one framework that we have at at Harvey is land, expand, lock in. What things can we build slash do to help us land new customers? What can we do to help us expand and grow usage? And then third is how do we make ourselves remote and very sticky with customers? That is something that Winston wrote and, you know, defined, and that is at the top level. And then how do you go about deciding, okay, let's say we really need to focus on lock in, and how do you go about deciding what to build, and then what are the operating cadence should be? It's something that I write, or engineering leaders write, on, okay, how should you think about making decisions? Why are we making decisions? There's both the meta aspect of process, like move really fast or iterate quickly or prototype quickly, and kind of like philosophies attached to that. And then there's things like tangibly, should the UX be? And how much should we invest in technical debt cleanup versus not? Those are kind of two different types of memos and thinking and reasoning. But I think there's like multiple layers and kind of like a fractal nature to this stuff. **Harry Stebbings** [26:20]: When you think about writing as a skill for product people, is it the most important skill for a product person to be a good writer? **Aatish Nayak** [26:26]: I think the most important skill is communication of your ideas, whether that happens in a written way, whether it happen you know, product people love slides, whether it happens in slides, whether it happens if, you know, nowadays you can build prototypes very quickly and communicate your ideas. Like, you know, PMs on my team create prototypes all the time using Cursor or using Claude to show, you know, show their ideas. And so I think communicating ideas, being very crisp about why you wanna do certain things, and and communicating that is is super important. Do we lose **Harry Stebbings** [26:58]: the design stage in a world of seamless prototyping where anyone really with some competence can spin up a prototype pretty and we don't have to spend a long time in the design pre prototype phase? **Aatish Nayak** [27:12]: Short answer is no. I don't think you lose the design function or you lose kind of designers. I think you actually get better designs because you can prototype much faster. Especially with AI, I I actually always say prototype before the PRD. Whenever you have an idea, whether it's engineers, designers, PMs, whatever, you should do the prototype before because you're not gonna really know how to build the product or what the exact UX should be, particularly like, again, with AI when these new patterns are being established without actually having, you know, you play with it, some internal customers play with it, you know, whatever it is. And then when you do the whole formal PRD kind of design process, whatever, you end up writing PRDs and whatnot and just and doing proper designs. But because you've done all this prework and prototyping, you can actually save a lot of cycles and just move faster at the end of the day, and then ultimately get a better outcome. What makes a fucking great PRD? Yeah. Good question. I view PRDs as alignment docs. It is not a bible for how something should work or something should happen. It is a alignment or kickoff doc. It explains, I think a really good PRD explains why you're doing certain things, motivation with ideally data or customer quotes or, you know, some evidence that why we're doing what we're doing. And then what it does also include is kind of like a straw man user journey of like, here's what the user should do step by step. Here's what, you know, how how it'll work, and ideally including different personas. And then the other big thing that is really important is what are all the hot questions and hot debated questions? Like, I think a good PM should have an instinct for looking around the corner, what is engineering going to say, why is this complicated, or what are customers going to say about this little feature? You want to make sure you call out all the elephants in the room and all of the debates at the bottom of the PRD so that when you do the kickoff, you can start to get alignment very early on. And looking ahead, and again, this comes with practice in your organization, looking ahead when you actually start building, when you start rolling out, what are going to be the gotchas, what are going be the pitfalls? And really calling those out at the end of the PRD is super, super important. **Harry Stebbings** [29:20]: I just wanna dive as granular as possible into the process that you build with today. So when you think about that, and I have written a PRD now, what do I do? I I don't laugh. I'm I'm a venture investor for a living, so give do me I like submit it to like you, and then we discuss it in a meeting? Who comes? How does that work? **Aatish Nayak** [29:39]: Yeah. So one general thing that, again, you this is actually coming from a lot of learnings at scale. One thing you wanna avoid is this idea of feature factories. And what that means is like, imagine a factory like a conveyor belt system. You have, okay, the customer says something, and then PM writes the PRD, and then designer does the mock, and then the mock is handed off to the engineer, then the engineer hands it off to QA, then the QA hands it back to PM, and then PM goes to enablement, and then goes to sales. Like, you have this very linear process, and that is how you make really bad products. That is how you demotivate your whole team because no one wants to be just stuck in what they're, you know, the specific, you know, section. And so the biggest thing when you've when you've written a PRD is get everyone in a room who's gonna get involved in it, who's ever even gonna touch it. Debate it, discuss it. That's why the questions are so important because you wanna say, where am I wrong? What are you worried about? What is gonna cause problems? Or what is actually gonna be delightful? Like, how can we make this delightful? And really having that first, you know, we do like PRD reviews, ERD reviews in like an hour setting every week where anyone can bring any doc and we debate it and we discuss it with everyone in the room who is even gonna touch the product or kind of be consulted on the product. And so it is not something that it should just be the PMs doing this in a in a hole in in, you know, in the back room and being like, we're gonna do this, this, this, and then hand it off to engineering. It is super important to compress everyone together. **Harry Stebbings** [30:59]: What is your prioritization framework between net new features versus technical debt? I interviewed the CTO of Microsoft, and he said that basically his most exciting application for AI today and moving forward is how AI will be used to basically demolish technical debt. To what extent how do you think about that balance between net new feature and revenue upside or product upside or usage upside and then technical debt reduction as the alternative? **Aatish Nayak** [31:25]: Yeah. As you can imagine, engineering candidates ask me this all the time because they wanna know what the header probably thinks about cleaning up code. So the nice thing I'll say is How dirty are code bases? How much debt is there really? If you're growing really fast, things will break and you just, like, engineers have to accept that. The important thing is if something breaks or something goes wrong or something goes slower than necessary because you have to refactor something and it didn't work in a certain way, it's really important to do a postmortem on that and say, what could we have done to avoid that? And the answer is like, oh, we could have spent one week in, you know, two sprints ago and said, let's clean this up before we do this thing. That's great because then you actually want evidence of technical debt affecting revenue, affecting customer outcomes. And you want to compile the evidence because otherwise, if you don't have evidence or you just refer to it as like technical debt overall, it is just like you can go forever cleaning up technical debt, to be quite honest. And so I think it's super important to identify examples of where cleaning something up would have avoided problems later. When you say, okay, we're gonna work on technical debt because of x, y, and z, you have to be very, very crisp about what does the outcome look like. Is it a bunch of tests are written? Is it you're gonna spend two weeks and refactor something? You wanna time bound it like with any other feature. Because otherwise, like, engineers will love to just forever, you know, clean up code, and there there's obviously, like, more way more you can do with The engineers rather clean up code than write new code. My take is I think engineers would like to clean up code in startups more so than than writing net new things. Wow. And in terms of the **Harry Stebbings** [33:01]: postmortems there, can I just ask you, is there a structured time every week for postmortems where you're like, Monday, 5PM, we do postmortems? Is it on an ad hoc basis? What does that look like? **Aatish Nayak** [33:11]: There so there's there's retros and postmortems. Post What's a retro and what's a postmortem? Yeah. So so retros retros are you wanna look back at some period of time and say, here's what we did well. Here's what we didn't do well. And retros should be generally more regular, like every month. For example, at the end of the month, say, what did we accomplish this month? What could have gone better? Here's what we should do for the next month. Postmortems are when there's an incident or issue or we made the wrong decision, you wanna evaluate that very specific decision or event that happened. Like if there's an incident and our app goes down for X amount of minutes, you wanna make sure you do a postmortem and see like why that happened, how do we resolve it, how could we have prevented it. And so postmortems are more ad hoc. One thing we're starting to do more of, and this is again me learning as a product leader at Harvey, is premortems. Premortems are before you start something like a big project or big initiative, you wanna sit down with your team and say, what does success look like, and what will prevent us from achieving that, and what will go wrong? Give me all your worries. I'm generally a very anxious paranoid person when I'm operating. I assume everything's gonna go wrong, and so maybe it's, like, self therapeutic for me to be like, guys, I think this is gonna happen. This is gonna happen. It's gonna go wrong. But I I think, you know, we've done a few of these, and I think it does help with anxiety. It does help with, like, alignment so that people aren't confused on what success looks like or How gets often **Harry Stebbings** [34:38]: is the things identified as causing the problems the things that cause the problems? You know, it's the Mike Tyson, you know, kinda getting punched in the face or whatever. You never expect it. Whatever that quote is that I'm gonna get butchered for now. But how often can you predict what it actually is versus something that you never expected? **Aatish Nayak** [34:55]: Yeah. Oftentimes, it is the things that are called out are the things that go wrong. If you say that we're not gonna do testing fast enough, and then you don't put an owner on this, like an owner to say, make sure testing goes faster, then it's gonna fail because no one's thinking about that. I don't think there's generally a lot of things that can go wrong that are out of the question. Of course, there's like unknown unknowns like COVID. Customer COVID. Yeah. Or the customer's not gonna like like the feature or, you know, a new model's gonna come out and that's gonna wreck all our plans. That happens sometimes. On **Harry Stebbings** [35:27]: the postmortem side, how quickly do you know when a new product or feature is not working versus it just needs time to sink into customer behaviors and adoption? **Aatish Nayak** [35:38]: This is something I think a lot about particularly for our user base because law firms don't like to move fast or are averse to change. At least the the like admin IT teams are averse to change. And so we can have a product launch, and it's not GA ed and roll out to 100% of users for a few months because people are just slowly adopting it. So I think you need to let it bake depending on the customer base. The ideal thing, you know, what we do is you branch out user testing to concentric circles, and that your concentric circles get bigger and bigger. The first thing we do when we build something is we have an extensive set of lawyers internally doing various roles. We give it to those lawyers and they test it and they give feedback and reiterate. And then we have selected design partners that are, you know, consistent for most features externally. We give it to them. They feel part of the process. That's really good. They give feedback. And then there's a broader list of beta testers, like beta beta customers. We give it to them, iterate, and then there's, like, the whole whole general public. And so, you know, this is probably true for most most products and most enterprise teams is you you wanna make sure you're testing this way, like, much more often with with kind of expanding circles. **Harry Stebbings** [36:52]: What have been the biggest mistakes you made in user testing or biggest mistakes you see other people make in user testing? **Aatish Nayak** [36:58]: I think one of them is biasing the users for what you want them to think. This is most useful maybe with an example. So we built this product called Vault last June ish, and the essential thing is it allows you to do large scale extraction of documents. Like if you have a bunch of lease agreements, credit agreements, and you want ten, twenty, 50 deal points out of it, out of each one, it creates a whole grid for you. And the way we went about building that is when you upload a bunch of files, you say, hey, I want these 10 things. And Harvey will decompose your initial prompt and suggest like, okay, here's the 10 things. I on the right track? And you know, check, check, check, and then you launch it. It demos really well because it's like takes your prompt and then converts it and shows a little thing. And when we showed it to people, people were like, my god, wow, that's amazing. And then we didn't really put it into the hands of people for live matters, live use cases. We just showed it, and they were like, oh my god, cool. It's a demo, and it's like interpreting my intent. The thing that we did wrong there was actually people want to just make those terms in the grid itself. People don't want the AI to convert it. They just want to say, for these 10,000 agreements, I just want this one thing created in the grid itself. They want to get really tailored with what each of those terms means and not have the AI guess all 10 terms. You get in your head sometimes and you bias your users, you, you know, give it to them for a real use case, and then you end up in some of these traps. **Harry Stebbings** [38:25]: What's the biggest product mistake that you've made, and how did you learn from it? **Aatish Nayak** [38:29]: Yeah. So there's a few things. I'll pick one of them was the one I I kind of just said right now around Vault and, you know, doing attraction. Another one that we were doing was, you know, again, at Harvey because it's recent. Last year in Q4, we were revamping our core assistant product. We introduced basically two modes in assistant. One is kind of assistant mode, which is doing Q and A and analysis. And then another one is a draft mode, which helps you draft contracts, draft new clauses, emails, you know, whatever lawyers do. And the thinking was you wanna give lawyers some choice of like, okay, what am I doing? And pick the right user interface and the model for the job because those are two different models and user interfaces. Again, is, you know, the joys of user testing. We we didn't user test this that much. We should have done it a little more. We were just trying to move fast and get something out. As we built it, we launched it, rolled it out, and almost everyone was super confused on when to use what. They didn't know when to use assistive draft. There was I think it's maybe lawyers, maybe something else. They just didn't know, hey, when I am, you know, creating a response to a complaint, what should I use? Draft or assist? And this is like everyone had this complaint. And then, you know, we started solving this by enablement saying the mall this model is good for this reasons, and the UX is good for this reasons, and so here's what you should do here. And some of those complaints died down, but it was mostly because people just got tired of of complaining in general. And then, obviously, they started using the product, and they said, oh, it the draft mode behaves this way and is more legal eased than the assist mode. But that is an example where the the right user experience is the AI should just pick for you. The AI should just know what user query and intent is, or it should ask you questions to understand it better, and then should just route you to the best system for the job and not have the user think about what that what they should do. **Harry Stebbings** [40:27]: I think it's preposterous that we're choosing our models. Whenever I'm on Anthropic, I'm like, what the fuck? And they've got these ridiculous names. Yeah. And I have no idea what any of them are, Grok have them too. And I'm just like, this is think it's ridiculous. You will never have in five years' time, you will not have a choice of which model. Correct? **Aatish Nayak** [40:45]: Yeah. Exactly. **Harry Stebbings** [40:46]: And Is user choice good? If you think about the paradox of choice and users get confused when they have too much choice, If you're just told, I think humans are lazy, just tell them which one. **Aatish Nayak** [40:57]: On average, humans are lazy and just need to be told what's best for them. The whole model choice, and again, we we fall into this trap, I think that whole paradigm was created for the Silicon Valley or tech audience because everyone loved playing around with like one versus GP4, versus these models. We hadn't, I mean, we still haven't quite figured out what the models are good at such that you can route appropriately. The biggest problem with these models, and we have this problem, is just like the capabilities are very eval constrained. You don't know exactly which model is better for the job. Sometimes it's user preference. We do a lot of side by side testing, sometimes it's still not super clear. So I think the whole industry as a whole kind of fell into this trap. Put everything in a dropdown and give users a bunch of choice. To **Harry Stebbings** [41:40]: what extent are your evals the same as the public evals that are done on benchmark? I had Tamar, the CPO and president of Glean, on the show recently. Yeah. And she said actually that their evals were very, very different to the benchmarked public displays of evals. Are yours correlated or yours wildly different? **Aatish Nayak** [41:59]: Yeah. So our evals are very different. A lot of public legal benchmarks and then even things like, you know, Scale's Humanities last exam, they're all multiple choice. I would love if legal work was multiple choice, but every any lawyer will tell you there are, like, a million options of what you could do. And so one, it's like multiple choices is is not the right thing. And so we created this benchmark called Big Law Bench, consists of tasks that are real billable work tasks that lawyers do on a daily basis at our biggest customers and big law firms. The nature of these tasks are they're very much open ended. What the problem with open ended tasks is like how do you evaluate them consistently across tasks? Like if you're saying Harvey generate a chronology, that is very different than draft me a motion for summary judgment, which is another kind of like litigation tasks. Then what we had to do is create rubrics for each of those tasks as well. And those got very specific, basically we have like hundreds of different tasks and each task has a rubric now. And the benefit that we have, and you know, we kind of architected this from the beginning, is we have a lot of lawyers that we have brought from, you know, big law to work with our AI team and with our engineering product team who sit side by side with them and say, here's how legal work actually happens. Because I'm not a lawyer. I come from AI. I don't know what good often looks like. It's really hard to do product management for sometimes for something you don't know what good looks like. So it's really important to rely on that domain expertise. And then another thing is our models of choice are OpenAI right now. Has that changed? So they've been investors in us from the beginning. We've gotten early access to OpenAI models for a long time. We've built some custom solutions with them. For the most part, that's still the case. We are seeing some capabilities now with Claude, with other models that are better for some tasks. And so now we're exploring Can I ask why is Claude better than OpenAI? Claude so we did this we did these EVOLs recently. Claude 3.7 in particular for legal reasoning, it's it's it's better at long form legal reasoning and drafting long form outputs. So a whole section of a merger agreement, for example, and making it super consistent, it's really good for. And then things like extraction, where extracting some terms from SPA, a share purchase agreement, is very nuanced because the answer isn't a verbatim text in the in the agreement. It's like, this is getting a little in the weeds on on legal, but if you're getting the indemnification cap on a share purchase agreement, you have to reason over four or five different clauses because that cap is not a name thing in the deal. You have to reason over the dependencies of four different clauses in that agreement and then extract that out. For some of those types of extractions, 3.7 in particular is starting to get better. Every single model release that's come out from OpenAI, from the other competitors, we've benchmarked for since the beginning of time at Harvey. And 3.7 is really where we're starting to see some of of the performance better than OpenAI. **Harry Stebbings** [44:58]: When you think about the distribution of value and usage in the model landscape, **Aatish Nayak** [45:03]: what do **Harry Stebbings** [45:03]: you think that looks like in three to five years' time? **Aatish Nayak** [45:06]: Yeah. I **Harry Stebbings** [45:07]: think the model companies are gonna have to start to become product companies way more. Do you not think they are already? If you look at, like, you know, Bunny, you've got OpenAI, which has deliberately chosen, it is now gonna be a consumer product company, 12,900,000,000 in revenue consumer product company, I think, very clearly. Yeah. I think Anthropic, not as much as it fucking should be Yeah. But is choosing very much to be a developer first and API company. **Aatish Nayak** [45:29]: Yeah. But I I I think more of these labs should start to think about what design product you wanna deliver. And the cloud companies, they're gonna they're gonna run the best software. They're gonna, you know, drive margins to the ground. And so competing on inference with cloud companies is really hard over time. And so if all your revenue comes from inference and developers, it's not an ideal place to be. And instead, wanna work, you wanna build products, maybe work with some particular application layer companies like Harvey to deliver your products end to end. You're **Harry Stebbings** [46:00]: building one of the hottest AI products in Silicon Valley today. I'm fascinated to hear your thoughts on this. Cursor is the golden child. There's also Codium. To what extent is there lock in for Cursor? And how do the two **Aatish Nayak** [46:13]: compare in your mind? I think it's like UX is super important. You know, I've heard some engineers say they like Cursor's agent mode much better than than Windsurf. Some people have said the opposite. So it's like, what is the most delightful UX? And sure, maybe you can copy UX, but I think it's it's a little more nuanced. And then it's like data and governance, particularly in the enterprise. Like the models are only as good as the context you give it. And so any of these products, can you actually tap into knowledge that the enterprise has about its code, its products, its architecture, and use that in more helpful ways to, you know, tailor the outputs that do not insurance right. And, you know, I know Codium has has focused a lot on getting a lot of the enterprise data, the enterprise understanding of existing code bases and making sure those that that like knowledge architecture is really good. As a user, which do you prefer? I currently use actually Claude for prototyping because I actually don't wanna deal too much with the very nuanced stuff that Windsurfer or Cursor has. And so I end up using Claude, and then I've actually been using also Replit agent mode. The reason being is because Replit takes care of deployment for you. Like, I don't wanna mess with deployment, front end, back end, servers, all that. And it really has a nice interface because you can give it some task of give me a legal chatbot app or something, and it'll say, here's my plan, here's the additional features I think that would be useful, and you can check, check, check, and it starts building it, and then you see it as it's building it, and then you can see the code, of course, and modify it. So things like, again, my target audience, things like agent replant agent mode, lovable, Vault are a little more attractive than some of the IDs. Do your team prefer Cursor or Cursor? They prefer Cursor, I believe, is the latest. I think it's mostly because we haven't procured Windsurf yet. Cursor have a better developer brand. They do. They do. And, you know, Silicon Valley everyone talks, and so a lot of the Cursor folks are are good friends and networks of of a lot of our team. And so they tend to prefer Cursor, but again, I think time will tell. Final one **Harry Stebbings** [48:22]: before we do a quick fire. When we look at AI, it changes so much of the product leadership and product management role. What do we not know about the future of product that you think a lot about in your leadership role today? **Aatish Nayak** [48:34]: In a in a world where, you know, prototyping and the actual execution of ideas is much cheaper, the ideas will matter a lot more. And, how you incorporate unique knowledge will matter more, like domain expertise. Maybe the future is lawyers, doctors, domain experts are driving more of the product decisions because you need to bridge the gap between what the model and UX is to how you actually apply it to a certain profession. Those ideas, domain experts will matter a lot more than they even do right now. I think we've seen the benefit of having lawyers in house, like, literally sitting next to engineers. Final **Harry Stebbings** [49:17]: one, and it is on the future of AGI, you said some really interesting comments that I do have to touch on before a quick fire. You said humans are a bottleneck to AGI. Why? **Aatish Nayak** [49:26]: Yeah. Everyone in Silicon Valley thinks that AGI will just happen. You'll see a lot of GDP growth and everyone will live happily ever after, UBI, whatever. I think realistically, you will run into cultural, legal and regulatory barriers to actually wide scale adoption of AI, like kind of breaking each one down. If you end up, again, AGI, you assume it can do really high level tasks like advising on a merger or advising as a board member of being a CEO. What are the governance frameworks for regulating an AGI that is running a company like no one knows yet? And that's going to take time to happen. I'm sitting on legal just because I actually have asked this question a lot to our partners and our customers on like what happens and everyone's like, we're gonna need some indemnification liability of all these different things that if AI autonomy starts to take actions in the world, what happens and who's responsible? I think on the culture side, it's like, what are the last domains where humans actually want AI involved? So as an example, in Silicon Valley, I and many of my friends actually talk to Claude or her for therapy or emotional advice of, like, I'm thinking through this problem. It's really, you know, hard. You do? Yeah. Exactly. That's the reaction I get from my hometown friends. Well, **Harry Stebbings** [50:48]: it's because I'm European, and so we actually are good at talking to other humans Exactly. Rather than transactional nature of you Silicon Valley beasts. But so you talk to them about, like, emotional stuff as well. Yeah. Do they give good output? **Aatish Nayak** [51:01]: Claude does. JHPT doesn't. It's Well not as empathetic. That's really interesting. Grock does too, actually. Grock does really good advice. I might try it. Yeah. You should. That's So another one where it's like, I think everyone should have AI therapists. That should probably happen at some point. And there's actually a study done recently where someone did a study where they had a bunch of participants talk to a bot that was based off of OpenAI or something for advice. And I think like sixty to seventy percent of them reported higher sentiment and more happiness after doing that for like four or five months compared to the control group who mostly talked to humans. And it's because people don't want to be judged by other humans, even if you do have a therapist that is in a safe space or something. **Unknown** [51:42]: Yeah. I think your willingness to **Harry Stebbings** [51:43]: open up is probably so much greater when you're speaking to an LLM. Yeah. Final one. Why do agents need humans more than humans need agents? **Aatish Nayak** [51:52]: There's this one interesting thing about GenAI where so who is the consumer of the product or service or the work that's being created, and who is the producer of it? Examples here are in architecture, it's the client versus the architect creating the design, or there's the marketer versus the brand person for content, or it's like the client versus the lawyer. And do you end up like what model do you end up taking? Do you help the producer 10x their output and make them more productive, or go direct to the consumer? And a lot of people have thought they can go directly to the consumer and say, here's a bunch of leads or here's a bunch of legal work, whatever. But ultimately, think humans don't just always trust AI, they trust other humans using AI. I I think, again, depending on the domain, the right thing is more likely that the agent partners with the producer of the work to deliver for the consumer. **Harry Stebbings** [52:43]: I don't think anyone suspects that we're gonna get rid of law firms and have direct to consumer law for consumers, do they? I mean, that's not a thought. It's like saying we're gonna get rid of accountants because we're gonna have the AI do accounting for you. No. **Aatish Nayak** [52:58]: You'd be surprised how much some people have that opinion. **Harry Stebbings** [53:00]: Wow. **Aatish Nayak** [53:01]: People who are not familiar with technology. And same thing with marketing. **Harry Stebbings** [53:05]: Maybe that is super, super low level. Yeah. I need a rental agreement for a one bed flat. This is the address. One page, please. Done. Do you know what I mean? **Aatish Nayak** [53:14]: Yeah. Yeah. And, again, the other thing is if you're booking a flight, sure. Let the agent do it. It's easy or you're ordering dinner or whatever. If you're doing something much more complicated like an architecture drawing, like legal work, tax work, the agent is gonna need a lot of human context to actually make that work, whether that's from the consumer, whether that's from the producer. And so it's gonna have to ask you a bunch of questions, even more complex knowledge work that enterprises do. I think people just have this assumption that agents will just do everything automated and black box and it'll be fine. But people don't trust black boxes. There are human unique human elements like context, like emotions that you need to factor in. And so I'm thinking beyond just like the booking flight agents, something way more like doing very complex work agents. **Harry Stebbings** [53:57]: Dude, I wanna do a quick fire with you because I could talk to you all day. Yeah. What's the most controversial opinion you hold that many disagree with? Yeah. So mine is like, think we should scrap the Department of Education. I think it's happening. Right? Well, I mean, it's not in The UK, Yeah. Yeah. That's true. A Department of Culture and Department of Sport. I mean, what the fuck? **Aatish Nayak** [54:16]: Yeah. **Harry Stebbings** [54:17]: Yeah. I mean, ridiculous. **Aatish Nayak** [54:18]: Yeah. I I actually have a list of these that some of them I don't know if I should say out loud. But you have a list of your **Unknown** [54:24]: controversial **Aatish Nayak** [54:24]: opinions? I do. Yeah. **Unknown** [54:25]: Wow. **Aatish Nayak** [54:26]: Yeah. **Unknown** [54:26]: On notes or, like **Aatish Nayak** [54:27]: Yeah. Yeah. On on notes. I can pull it up if you have second. Yeah. I'm fascinated. That's so cool. I've never heard that before. It's because I whenever I have an opinion, I write it down and then my recall memory in my brain is not not great. So I just need to write everything down. **Harry Stebbings** [54:47]: No. I I don't do it. I mean, have my thing is I have a pen and paper beside my bed. **Unknown** [54:52]: At night because I often get ideas when I'm lying in bed, and I scribble it down. Yeah. Yeah. Or I send it in the subject line to my EA. At 2AM, it's like, new show. I was like, what the fuck? **Aatish Nayak** [55:13]: Okay. Yeah. I I I got I got one that I can say a lot. I'll say the other one's not not on recording. Yeah. So **Unknown** [55:19]: what's most controversial opinion? **Aatish Nayak** [55:21]: Yeah. I think people generally welcome stability, but I think the to truly be happy, to truly be fulfilled, I think you need to embrace chaos, you need to embrace instability because that makes life much more interesting. I think there's always the I'm going to settle down and be fine and retire and be chill. You could you could do that, but I think the road to getting there, you should actively embrace conflict. You should actively embrace uncomfortability because you'll be much more resilient to whatever life throws at you over time. **Unknown** [56:00]: What was the most uncomfortable thing you embraced? **Aatish Nayak** [56:04]: So there's a few things in in different parts of my life. Maybe in college, I willingly took probably, like, one of the hardest, like, courses at at Carnegie Mellon, like operating systems. You have to build operating systems from scratch. And I didn't have to take that. I could got my degree without it. I had just a lot heard a lot of crazy things of people staying up two nights in a row doing it, I was just like, let's do it. Why not? Another thing is, you know, out of college, like a lot of CMU, you know, graduates we were offered jobs at the big companies, Microsoft, Palantir, Stripe, whatever. I decided to not do that, move to LA, join my friend's company, which ended up failing in a year, but just something off the beaten path. And when else would I live in LA? And so I ended up doing that and then meandered my way through startups instead of kind of going for the big companies. **Harry Stebbings** [57:01]: Biggest advice to graduates today entering a new AI workforce world? **Aatish Nayak** [57:07]: Yeah. So I think it goes back to what I said in the beginning. Focus on the skill sets that you wanna learn. I think I still get this where a lot of engineers are like, I wanna be a product manager. And it's like, the one of the most valuable things you have is your ability to code if you're an engineer, let's say. And I wish I I stuck to it more, but I think it's super important to stick to that at least because it's much better with vibe coding or whatever now. And then don't be afraid to try a lot of things. I think people, expect that they have to figure everything out in their early twenties. That's just not the case, especially now with AI. You don't know what's gonna be valuable when you're 26, when you're 22. So I think try a bunch of things, experiment, see what you like, see what you don't like. How much of Harvey's code is AI written? That's a good question. I mean, I I think it's probably it's not that much. It's probably like 20%. 20%. Is that normal today? I would guess so. I think we can probably use AI way more than we are. How can you use AI in a way that you're not already? Unit testing is, I think, can be way more automated with AI. I think, I mean, individual engineers still use AI somewhat for writing their own unit tests, but that whole layer of unit testing should just be all AI. What would you most like to **Harry Stebbings** [58:27]: do in your role, but because of decision making or resources you're not able to do? **Aatish Nayak** [58:32]: Go on podcasts. No. I'm already doing that. I think I would like to work on so there's Harvey, like the productivity suite that we have today, is the core product, and then there's Harvey that does a lot of the end to end work in collaboration with law firms and and enterprises. And that is stuff like, you you know, that enterprises pay millions of dollars to do. Like, I wanna just tackle that that work. That is way, you know, way out. You need to do research. You need UX experimentation. So we'll get to that. But right now we have to focus on Harvey, the productivity suite, the software that lawyers use, and not the the Harvey that that does the work end to end. **Harry Stebbings** [59:20]: I say that it's easier to build an AI company in London than it is San Francisco. Everyone goes, and it's like, we have the supply of AI talent from some of the best institutions and universities. But crucially, we don't have the churn. Is the churn in San Francisco AI as brutal as it looks from the outside? What do you mean by churn? Like employee churn? People going to other hot company because OpenAI put 2,000,000 on the table for your best engineer or Codium or **Unknown** [59:51]: Wind Cursor or whoever. **Aatish Nayak** [59:53]: Yeah. Yes. I think I think churn is very real. I think the talent, quote unquote, war is is, I think, very real. I mean, this is not just in AI. Like, some of the best executives in the world live in this, like, tiny slim peninsula in in the Bay Area. And especially if you are growth stage companies where you need to bring in experienced people, experienced executives, they're all concentrated there, have families, they have all these people who just wanna stay there. And so, sure, you can have a lot of the early stage talent in other places, but I think the mind melding you get, the experience you get there, I think is is second to none. Which **Harry Stebbings** [60:35]: company is the hottest company right now for the best talent, do you think? **Aatish Nayak** [60:43]: I really think OpenAI and Anthropic. I think I would have said OpenAI maybe six months ago, but I think Anthropic is really starting to appeal to a lot more people. **Unknown** [60:51]: Yeah. **Aatish Nayak** [60:52]: Final **Harry Stebbings** [60:53]: one. What recent company product strategy, say, in the last twelve months, have you been most impressed by other than Harvey? **Aatish Nayak** [61:01]: Yeah. **Harry Stebbings** [61:02]: Of course. **Aatish Nayak** [61:06]: Yeah. I'm like, I I had this below, but I'm like **Harry Stebbings** [61:09]: So for me, it's actually like Canva. I think Canva's been super smart in how they've done templates and how they've opened up like a marketplace style dynamic where you can kind of bluntly borrow, add on, lend to anyone's creative whims in a really cool way. **Unknown** [61:23]: Yeah. It **Harry Stebbings** [61:23]: really solves **Unknown** [61:24]: the cold start problem. **Aatish Nayak** [61:25]: Yeah. So okay. I will say I do think perplexity is honestly just killing it. Like, I have a lot of respect for that team and the speed that they're moving. Like, sure, you can say, oh, they're doing a lot of things now, but I think the the focus on the core experience of making an answer really, really, really fast and everything else out of the way is, I think, you know, second to none. And this is actually one where product is the king. Like, I mean, sure, they have distribution and stuff, but people adopted it against consumer, but people adopted it because the product is just so good. And I think they're they're starting to now focus on certain verticals like shopping, like travel, like finance, where you need a lot of Internet knowledge. And I think that that strategy is really smart. **Harry Stebbings** [62:12]: As an investor in perplexity, I'm thrilled to hear that. I think Aatish is amazing. Listen, I've so enjoyed this. Thank you so much for putting up with the slightly wayward approach to the schedule, but you've been fantastic. **Aatish Nayak** [62:24]: Yeah. Thanks so much, and glad it was useful. **Harry Stebbings** [62:28]: God, I so enjoyed that episode. And if you enjoyed it too, then I would love it if you left a review or liked it. It makes such a difference for Discovery and really do so appreciate that. But before we leave you today, ## Sponsor read **Harry Stebbings** [62:40]: are you struggling to beat model benchmarks or implement GenAI in your product? If so, you need Turing. Turing is an AGI infrastructure company backed by incredible investors like Foundation Capital and Westbridge Capital, and they do two things. Number one, they help leading companies in AI labs like Salesforce, Anthropic, and Meta enhance their LLMs with advanced reasoning, coding, multilinguality, multimodality, and more. Number two, they combine human and artificial intelligence expertise to deploy cutting edge AI systems for awesome companies like Rivian and Reddit. Right now, Turing offers a free five minute self assessment to help you pinpoint your place in the GenAI journey, get tailored next steps to optimize your model strategy, and then finally learn how Turing can refine and implement your models for better performance. Take the guesswork out of GenAI. Visit turing.com/20vc to start your free assessment today. And once your GenAI strategy is on point with Turing, make sure your team stays just as sharp in the day to day. Hey, managers and leaders wanna make your meetings way more efficient and save time? With over a billion meetings processed, Otter dot ai is the ultimate AI meeting productivity tool. It gives you real time transcripts, quick summaries, action items, and insights, plus a voice activated agent that keeps you focused and productive. It's unbelievable. Imagine cutting down your meeting prep and follow ups and freeing up more time for what matters. Otter's trusted by over 25,000,000 users, including Fortune 500 companies, to boost productivity and collaboration. So are you ready to take your meetings to the next level? Well, head over to get.otter.ai/20vc and grab a 30% discount. My word. They're so generous. When you subscribe to a business plan for your team, that's getotter.ai/20vc. Let's make your meetings work for you. Alright. Meetings sorted. Now let's fix your software. Whether it's the software you build or the software you buy, your tech stack should be results, not creating roadblocks. Well, Pendo's no code software experience management platform makes your software better with tools to see where users get stuck, guide them with in app messaging, and constantly improving your UI. It's so easy that over 14,000 businesses use Pendo to increase revenue, lower costs, and reduce risks. Businesses love the control. Engineers love the freedom. Everyone wins. Start for free today at pendo.io/20product. As always, we so appreciate all your support, and stay tuned for an incredible episode coming on Monday with Victor Lazarte at Benchmark.