20Product: 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

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 the 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 3.7 in particular for legal reasoning it's at long form legal reasoning and drafting long form outputs.

This is 20product with me Harry Stebbings now. 20product 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 Atish 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 third Hypergrowth AI unicorn, having previously held product leadership roles that scale AI from 40 to 800 people and shield AI from 20 to 100 people. But before we dive into the show today, are you struggling to beat model benchmarks or implement Gen AI 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 Sales, Salesforce, Anthropic and Meta enhance their LLMs with advanced reasoning, coding, multilinguality, multimodality and more. 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 5 minute self assessment to help you pinpoint your place in the Gen AI 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 Gen AI. Visit turing.com 20vc to start your free assessment today. And once your Gen AI strategy is on point with Turing, make sure your team stays just as sharp in the day to day. Hey managers and leaders want to 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 million 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 AI20VC and grab a 30% discount. My word, they're so generous. When you subscribe to a business plan for your team, that's getotter a AI20VC. 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 risk. Businesses love the control, engineers love the freedom. Everyone wins. Start for free today at Pando iO20 product.

You have now arrived at your destination.

Atish.

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.

Yeah, I'm excited to be here and it's a great day in London for for this podcast.

Dude, it is so special. Stuart 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?

One big thing I was always optimizing for is 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 is my title a product manager, is my title a software engineer. So skill set growth was super important. I think one thing back then was like you were more bucketed into different roles than you are. So focus on skillset growth. And 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 post that you want to try to strive for the top 1% of what you do and of course not everyone's going to 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 want to do? What am I good at? What am I 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 want to get better, but instead I wanted to get better at things like 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.

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 what everyone tells me. No, no, no, do what you're good at.

Yeah.

And it compounds.

Yeah.

And then most often what you're good at, you do also. You do love a lot because you're good at it.

Yeah, exactly.

And that's why I 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. I think. I have to ask. Scale is a generational defining company in many respects. Just raised at 25 billion dollars. It ends this year at 2 billion. Fucking nuts. 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?

Yeah, I think maybe a few things to touch on. So one, I think Scale was at the frontier of a lot of different AI movements over the last five, six years. And I think one thing we did really well was listening to Frontier customers, customers that are at the frontier of whatever 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 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 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 you agree with that, given the experience you have?

Yeah. So I do think there's this idea of tough customers. So tough customers who ask for the world want all this new custom stuff. I think it does take a tremendous discipline to say what are they asking for that you think is going to be very, very specific to them and what are they asking for other people are going to 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. Another example of this is skale 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 GPT2 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 is 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 intense proximity to customer and really listening was one. Any others?

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 request gets to the engineer, it's like maybe you, you know, 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 training centers all around the world to literally observe how people are using the labeling products and different scale products and prototype and build right there respectfully.

With that reduction in chasm between customer and engineer, what is the role of a PM in that world?

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 I'm going to do this, I'm going to 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 your WD40. Have you heard of WD40?

Yeah, I have.

It's like a industrial lubricant, right. So in the, the engine of a company in 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 want to make sure everyone else can shine and be good at what they do and, you know, grease the skids or however you want to call it. And what that means maybe is putting the engineer in front of the customer because the customer wants to talk to engineers and engineers wants to talk to customers, and that gives them confidence.

If I'm a PM and I currently consider myself the glue, and I'm listening.

To you going, I want to be WD40.

What can I do to be WD40 where I would have been glue?

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 the face of their 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's just give others the opportunity to shine for the skill set that they have. And then, you know, as I said, putting designers, putting engineers in front of customers, giving them Room to give ideas, brainstorming with everyone in the room, and a lot of kind of tactical things. But it really starts with saying I don't have to be the main character. I just have to make the product and the company succeed.

So funny. You said there about kind of main character. I always hear on the show PM is the CEO of the product. And I always find that funny. You know what I find funny?

The CEO is the CEO of the product.

Exactly. It's so funny. I had the CPO of Shopify on the show and they said, I'm not the cpo. Toby is the cpo. I mean, I am by title, but not really. 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 get into that.

I mean, none. Which makes it fun to raise from you guys, but market is the only thing that matters. Fascinating why? Can you unpack it for me?

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 going to have Robo taxis. 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 like the founders are brilliant. Every single one of them is probably somewhere either now working on LMS or at Waymo or Tesla or whatever. But I think it's really important to find a market that is huge before you are too late. So I think that's like one thing.

Scale's market was great. Like data labeling as a market. Is that a good market?

Yeah. So I think data labeling, any type of data intake 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 in Terms of needs for data.

Because this was always a criticism of scale, which is just like it's just an autonomous car data labeling service.

I think again, what we did well was there was self driving, of course. We started with that sort of 3D self driving and then we pivoted to 2D self driving. So images, videos, all of that. And then that led to robotics, like warehouse robotics and other types of robotics. And then that pivoted to government, where 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 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?

Yeah, so it was hard, I'll say. I think for vision, like 3D and 2D, it was more straightforward. You know, scale was very operational and 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 2D and in 3D. And so yeah, you do have to build products. But I think credit to Alex and his tenacity for being able to say, guys, we got to do it, it's fine, it's going to cost us a thought of thrash, but there's these huge markets out there. One thing I'll also say just 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 interned at Uber in 2016, like way back when it was super fascinating to see that this was when this was kind of like their heyday TK and everyone was like really going at it. And 2019 or ever, there's like that delete Uber, there's a lot of chaos. But Uber standing and it is profitable. And you know, obviously credit to Dara, but the market is insane. Like Robo or just taxis on demand, like who doesn't want that? And as when the cat was out of the bag, that's possible. Everyone was asking for it. Right. So I do think like great markets can, you know, hide some of that.

You said something fantastic before. I'm a big, big believer in focusing on distribution. I don't think nearly enough people do. It's a big difference between first time founders, second time founders. But you said if distribution is king, then product is president. And I thought give this man a podcast. Can you explain if distribution is king, then product is president.

Yeah. So I think distribution can bring a lot of early traction by sheer amount of brute force. If you look at aristocracies and kings and kingdoms, 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, 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 falsehood here. And so you do have to follow it with product and why product is president, because presidents in democracies are for the people, by the people. And product, you ultimately want to listen to your users. All the promises that we've made, 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.

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?

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 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 a product. And so I think it depends on when you focus on product. And ultimately I think some of the, for us especially, I mean, some of the longer term moats are the UX that you build around product chatgpt kind.

Of made it the default by consumer expectations. Do you think that chat is the right interface?

Definitely not. It's the command line starting point of this new frontier. Like the Ms. DOS was way back when. I think there's a few things in 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 and 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 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. You know, of course now people hire people to assemble things, but that just created this like cult like following with ikea. And so for us, how you can start to change the 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 going to 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.

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. So maybe defining Hypergrowth is every three to six months, let's say your revenue is more than 1.5x, 1.2x. Your employee count is more than 1.52x. Like it's a different company every single quarter, let's say, or half. And so a few things that break are one. It becomes super hard to know what to actually prioritize. 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 go. 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 going to do a lot of the wrong things. That's I think one. And then generally you also get either too many people making a decision or not enough people making a decision. You get a lot of kind of tragedy of the commons. Something is breaking and no one knows who should be responsible for it. For example, product enablement of sales, who is responsible for that? No one really thinks about that as much. 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 PM's engineering team to turn those kind of 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. Of course, depending on the founder, for early product leaders, it's really important to build a really, really good relationship with the founders. Maybe that's obvious, but it is important to say, okay, why did you hire me? Or why do you want to hire me? 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 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. I've seen product leaders, product managers kind of end up in bad places because they didn't have that conversation. And then the founder doesn't want to let go, it becomes really hard.

So the CPO of Spotify said on the show once, that talk is cheap 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 and 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?

So I believe in benevolent dictatorships. So Singapore as an example, I totally agree. I think it's super important that you have very, you know, clear vision and like, execution from the top, because otherwise you're going to 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 definitely have not nailed this, but what did you do wrong? So I think particularly early on at Harvey, we did the dictatorship. Me and Winston are just like, we're going to do X, Y and Z and go, go, go. I think again, as you hyper grow, you assume everyone has the same context that you do, and that's just not the case. They're not in all the conversations, they're not in investor meetings. They don't see what the models are going to do six months down the road. And so that caused Thrash and the team watching this is probably going to 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 you know, 99% of the time, if your reasoning is right and if it's not, you should debate it. If your reasoning is right, they will agree with you. But just sharing that context, writing memos, having brainstorm discussions, welcoming debate, I think it's super crucial as long as it doesn't slow things down. And you debate for seven weeks.

When you think about writing those product memos, what does that look like in terms of process and how it's enacted?

Yeah, so there's like an altitude of different product numbers you can write.

Great. Can you dive into it with me?

Yeah. So the top level is what are we going to 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 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 the operating cadence should be? It's something that I write, our 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 philosophies attached to that. And then there's things like tangibly what should the UX be? And how much should be invested in technical debt cleanup versus not. Those are kind of two different types of memos and thinking and reasoning. But I think there's multiple layers and kind of like a fractal nature to this stuff.

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?

I think the most important skill is communication of your ideas. Whether that happens in a written way, whether it happens, probably 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 PMs on my team create prototypes all the time using Cursor or using Claude to show their ideas. And so I think communicating ideas, being very crisp about why you want to do certain things and communicating that is super important.

Do we lose the design stage in a world of seamless prototyping where anyone really with some competence can spin up a prototype pretty quickly and we don't have to spend a long time in the design pre prototype phase.

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 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 going to really know how to build the product or what the exact UX should be. Particularly like again with AI, when these, 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 doing proper designs. But because You've done all this pre work in prototyping, you can actually save a lot of cycles and just move faster at the end of the day and 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 some evidence that why we're doing what we're doing. And then what it does also include is kind of like a strawman user journey of like, here's what the user should do step by step, here's 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? 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 to be the pitfalls? And really calling those out at the end of the PRD is super, super important.

I just want to 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? Don't laugh. I'm a venture ambassador for a living. So if you give me do I submit it to you and then we discuss it in a meeting, who comes? How does that work?

Yeah. So one general thing that again, this is actually coming from a lot of learnings at scale. One thing you want to avoid is this idea of feature factories. And what that means is 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, this specific section. And so the biggest thing when you've, when you've written a PRD is get everyone in a room who's going to get involved in it, who's ever even going to touch it, debate it, discuss it. That's why the questions are so important, because you want to say, where am I wrong? What are you worried about? What is going to cause problems or what is actually going to be delightful? How can we make this delightful and really having that first, we do PRD reviews, ERD reviews in an hour setting every week where anyone can bring any doc, and we debate it, we discuss it with everyone in the room who is even going to touch the product or kind of be consulted on the product. And so it is not something that it should just be the PM's doing this in a hole in the back room and being like, we're going to do this, this and this, and then hand it off to engineering. It is super important to compress everyone together.

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?

Yeah, as you can imagine, engineering candidates ask me this all the time because they want to know what the header probably thinks about cleaning up code. So the nice thing I'll say is.

How dirty our code bases, how much debt is there really?

If you're growing really fast, things will break and 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 if the answer is like, oh, we could have spent one week in 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 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 going to 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 going to spend two weeks in refactor something you want to time bound it like with any other feature because otherwise engineers will love to just forever clean up code. And there's obviously 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 write net new things.

Wow. In terms of the 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?

So there's retros and postmortems.

What's a retro and what's a post mortem?

Yeah. So retros are. You want to 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 you 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 want to evaluate that very specific decision or event that happened. If there's an incident and our app goes down for X amount of minutes, you want to make sure you do a postmortem, see 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 pre mortems. Pre mortems are before you start something like a big project or big initiative, you want to 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 going to go wrong. And so maybe it's self therapeutic for me to be like, guys, I think this is going to happen, this is going to happen. It's going to go wrong. But I think we've done a few of these and I think it does help with anxiety, it does help with alignment so that people aren't confused on what success looks like.

How often is the things identified as causing the problems? The things that cause the problems? It's the Mike Tyson kind of getting punched in the face or whatever. You never expect it, whatever that quote is that I'm going to get butchered for now. But how often can you predict what it actually is versus something that you never expected?

Yeah, oftentimes it is. The things that are called out are the things that go wrong. If you say that we're not going to 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 going to 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 customer Covid. Yeah. Or the customer is not going to like, like the feature or a new model is going to come out and it's going to wreck all our plans.

That happens sometimes on the post mortem 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.

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 admin IT teams are averse to change and so we can have a product launch and it's not GA'd 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 what we do is you branch out user testing to concentric circles and 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 consistent for most features externally. We give it to them, they feel part of the process, it's really good, they give feedback and then there's a broader list of beta testers, like beta customers. We give it to them iterate and then there's the whole general public. And so this is probably true for most products and most enterprise teams is you want to make sure you are testing this way much more often with kind of expanding circles.

What have been the biggest mistakes you made in user testing or biggest mistakes you see other people make in user testing?

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 10, 20, 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. Am I on the right track? And check, check, check. And then you launch it. It demos really well because it takes your prompt and then converts it and shows a little thing. And when we showed it to people, we were like, oh, 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 at least 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 give it to them for a real use case, and then you end up in some of these traps.

What's the biggest product mistake that you've made and how did you learn from it?

Yeah, so there's a few things. Maybe I'll pick. One of them was the one I kind of just said right now around Vault and doing extraction. Another one that we were doing was 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 assist mode, which is doing, you know, Q and A and analysis. And then another one is a draft mode, which helps you draft contracts, draft, you know, clauses, emails, you know, whatever lawyers do. And the thinking was you want to 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, this is the joys of user testing. 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 Assisted Draft. They were just, 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 this model is good for this reason 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 complaining in general. And then obviously they started using the product and they said, oh, the draft mode behaves this way and is more legalese than the assist mode. But that is an example where 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 they should do.

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 and I have no idea what any of them are. And Grok have them too. And I'm just like, this is. I think it's ridiculous. You will never have that. In five years time you will not have a choice of which model. Correct.

Yeah, exactly.

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.

On average, humans are lazy and just need to be told what's best for them. The whole model choice. And again we fell into this trap. I think that whole paradigm was created for the Silicon Valley or tech audience because everyone loved playing around with like 01 versus GPT 4.0 versus these models. 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. And 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 what extent are your evals the same as the public evals that are done on Benchmarked? I had Tamar, the CPO and president of Glean, on the show recently 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?

Yeah, so our evals are very different. A lot of public legal benchmarks and then even things like Scale's Humanities last examination, they're all multiple choice. I would love if legal work was multiple choice, but any lawyer will tell you there are a million options of what you could do. And so one, it's like multiple choices 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. The problem with open ended tasks is how do you evaluate them consistently across tasks. If you're saying, Harvey, generate a chronology that is very different than draft me a motion for summary judgment, which is another litigation task, then what we had to do is create rubrics for each of those tasks as well. And those got very specific. And basically we have hundreds of different tasks and each task has a rubric now. And the benefit that we have and you know, we kind of architect 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, 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 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 these evals recently, Claude 37 in particular for legal reasoning, 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, like a share purchase agreement is very nuanced because the answer isn't a verbatim text in the agreement. It's like this is getting a little in the weeds 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 named 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. Claude is 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 the performance better than OpenAI.

When you think about the distribution of value and usage in the model landscape, what do you think that looks like in three to five years time?

Yeah, I think the model companies are going to have to start to become product companies way more.

Do you not think they are already? If you look at like Bunny, you've got OpenAI, which is deliberately chosen. It is now going to be a consumer product company. 12.9 billion in revenue. Consumer product company, I think very clearly. Yeah, I think anthropic, not as much as it fucking should be, but is choosing very much to be a developer first and API company.

Yeah. But I think more of these labs should start to think about what is that and product you want to deliver. And the cloud companies, they're going to, they're going to run the best software, they're going to, 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 you want to work, you want to build products, maybe work with some particular application layer companies like Harvey to deliver your products end to end.

You're 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 Codeium. To what extent is there Lock in for Cursor? And how do the two compare in your mind?

I think it's like UX is super important. I've heard some engineers say they like Cursor's Agent mode much better 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 a little more nuanced. And then it's like data and governance, particularly in the enterprise, 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 tailor the outputs that data engineers write. And I know Codeium has focused a lot on getting a lot of the enterprise data, the enterprise understanding of existing code bases and making sure that knowledge architecture is really good.

As a user, which do you prefer?

I currently use actually Claude for prototyping because I actually don't want to deal too much with the very nuanced stuff that Windsurfer 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 want to mess with deployment, front end, backend 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 can see it as it's building it, and then you can see the code, of course, and modify it. And so things like, again, for my target audience, things like Agent, Replit, Agent Mode, Lovable, Bolt are a little more attractive than some of the IDs.

Do your team prefer Codeium 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 Silicon Valley, everyone talks. And so a lot of the Cursor folks are good friends and networks of a lot of our team, and so they tend to prefer Cursor. But again, I think time will tell.

Final one 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?

In a world where 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 their product decisions. Because you need to bridge the gap between what the model and the 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 literally sitting next to engineers.

Final one, and it is on the future of AGI. But you said some really interesting comments that I do have to touch on for a quick fire. You said humans are a bottleneck to AGI. Why?

Yeah, everyone in Silicon Valley thinks that AGI, it'll 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 kind of like 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, advising as a board member, being a CEO. What are the governance frameworks for regulating an AGI that is running a company? 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 what happens and everyone's like, like we're going to 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 talked to Claude or Chachmiti for kind of therapy or like 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, it's because I'm European and so we actually are good at talking to other humans 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 Claude does. ChatGPT doesn't. It's not as empathetic.

That's really interesting.

Grok does too, actually. Grok does. Really good advice.

I might try it.

Yeah, you should. So that's 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 60 to 70% of them reported higher sentiment and more happiness after doing that for four or five months compared to the control group who mostly talk 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.

Yeah. I think your willingness to open up is probably so much greater when you're speaking to an LLM. Final one. Why do agents need humans more than humans need agents?

There's this one interesting thing about Genai. 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, 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 I think the humans don't just always trust AI, they trust other humans using AI. 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.

I don't think anyone suspects that we're going to get rid of law firms and have direct consumer law for consumers, do they? I mean, that's not a thought. It's like saying we're going to get rid of accountants because we're going to have AI do accounting for you.

No, you'd be surprised how much some people have that opinion.

Wow.

People who are not familiar with technology and same thing with marketing.

Maybe like super, super low level. I need a rental agreement for a one bed flat. This is the address. One page, please. Done. Do you know what I mean?

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 going to 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 going to 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 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, I'm thinking way more like doing very complex work. Agents.

Dude, I want to 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, I think we should scrap the Department of Education.

That's happening, right?

Well, I mean, it's not in the uk. Yeah, yeah, that's true. Department of Culture and Department of Sports. I mean, what the fuck?

Yeah, yeah.

I mean, ridiculous.

Yeah. I actually have a list of these that some of them I don't know if I should say out loud.

Well, you have a list of your controversial opinions.

I do, yeah.

Wow.

Yeah.

On notes or like.

Yeah, yeah, on notes. I can pull it up if you have said.

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.

No, I don't do it. I mean, I have. My thing is I have a pen and paper beside my bed 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, like.

Okay, yeah, I got one that I can say out loud. I'll say. The other one's not on recording.

Yeah. So what's the most controversial opinion?

Yeah, I think people generally welcome stability, but I think 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 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.

What was the most uncomfortable thing you embraced?

So there's a few things in different parts of my life, maybe in college, I willingly took probably one of the hardest courses at Carnegie Mellon, Operating systems. You have to build operating systems from scratch. And I didn't have to take that. I could go out of my degree without it. I had just heard a lot of crazy things of people staying up two nights in a row doing it. And I was just like, let's do it. Why not? Another thing is out of college, like a lot of CMU graduates, we were offered jobs at the big companies, Microsoft, Palantir, Stripe, whatever. I decided to not do that, moved 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.

Biggest advice to graduates today? Entering a new AI workforce world.

Yeah, so I think it goes back to what I said in the beginning. Focus on the skill sets that you want to learn. I think I still get this where a lot of engineers are like, I want to be a product manager. And it's like 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 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 20s. That's just not the case, especially now with AI. You don't know what's going to 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 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 could you use AI in a.

Way that you're not already unit testing? I think can be way more automated with AI. 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 do in your role, but because of decision making or resources you're not able to do?

Go on podcast? 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, which 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 enterprises. And that is stuff that enterprises pay millions of dollars to do. I want to just tackle that. That work that is 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 Harvey that does the work end to end.

I say that it's easier to build an AI company in London than it is San Francisco. Everyone goes wah, wah, wah, wah. 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 companies because OpenAI put 2 million on the table for your best engineer or Codeium or Windcurster or whoever.

Yeah. Yes. I think Churn is very real. I think the talent is war is, I think, very real. I mean, this is not just in AI. Some of the best executives in the world live in this tiny, slim peninsula 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 in there, have families, they have all these people who just want to 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 second to none.

Which company is the hottest company right now for the best talent, do you think?

I mean, 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.

Final one, what recent company product strategy, say in the last 12 months, have you been most impressed by other than Harvey?

Yeah, of course. I had this below, but I like it.

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 a marketplace style dynamic where you can kind of bluntly borrow, add on, lend to anyone's creative whims in a really cool way. It really solves the cold start problem.

Yeah. So okay, I will say I do think Perplexity is honestly just killing it. I have a lot of respect for that team and the speed that they're moving. Sure you can say, oh, they're doing a lot of things now, but I think the focus on the core experience of making an answer really, really, really fast and everything else out of the way is I think, second to none. And this is actually one where product is the king. 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 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 strategy is really smart.

As an investor in Perplexity, I'm thrilled to hear that. I think Aravind 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.

Yeah, thanks so much and glad it was useful.

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, 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. One, they help leading companies in AI labs like Salesforce, Anthropic and Meta enhance their LLMs with advanced reasoning, codec, 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 5 minute self assessment to help you pinpoint your place in the Gen AI 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 Gen AI. Visit turing.com 20vc to start your free assessment today. And once your Gen AI strategy is on point with Turing, make sure your team stays just as sharp in the day to day. Hey Managers and leaders want to 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, 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 million 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 AI20VC and grab a 30% discount. My word, there's so generous when you subscribe to a business plan for your team. That's getotter AI20VC. 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. Everyone wins. Start for free today at Pendo iO20 product. As always, we so appreciate all your support and stay tuned for an incredible episode coming on Monday with Victor Lazarte at Benchmark.