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.
Claude37, in particular for legal reasoning.
It's better at long-form legal reasoning and drafting long-form outputs.
This is 20 Product with 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 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 hyper-growth AI unicorn, having previously held product leadership roles at 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 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 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 forward slash 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, 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 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.ai forward slash 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 forward slash 20VC.
Let's make your meetings work for you.
All right, 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 14000 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 forward slash 20 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 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 you were more bucketed into different roles than you are.
So focus on skill set, 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 things that a more traditional product manager would do.
And so I ended up joining Shield, where I could put myself in opportunities to flex those skill sets and get better at those skill sets without 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.
You do love.
Because you're good at it.
Yeah, exactly.
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, I think.
I have to ask, Scale is a generational defining company in many respects.
It just raised $25 billion.
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 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 what 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.
Everyone else would follow.
Early on in self-driving.
Nuro was super, super early on in a lot of LIDAR and a lot of really hard what's called pedestrian work pedestrian labeling work.
We ended up doing a lot of custom things for Nuro, 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 today's world is definitely the case find the customers who are really good at what they do and then chase them, even over a fit to them, as long as you have conviction that 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.
To what extent do you agree with that given the experience you have?
Yeah, so I do think there's this idea of like, you know, tough 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 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.
You know another.
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.
And this is on GPT-2.
And this is actually one of my first projects at scale.
We ended up doing something super custom, built a custom product for labeling Reddit passages.
And then maybe two years later, it opened up super ahead.
Two years later, everyone started asking a lot of this stuff and a lot of the similar needs.
And so maybe opening up 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, customer requests gets 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 Nuro, or the contributors, kind of the taskers who were 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 framing that you should probably have is you're not glue, you're WD-40.
Have you heard of WD-40?
Yeah, I have.
It's like industrial lubricant.
In the engine of a company and a hyper-growth startup.
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 customer wants to talk to engineers and engineers wants to have 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 wd-40.
What can i do to be wd-40 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 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's 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, 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 the main character.
I just have to make the product and the company succeed.
So funny.
You said that about kind of main character that I always hear on the show.
PM is the CEO of the product.
Yeah.
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 um, the americans have zero discipline on price respectfully, None.
We can get into that if you want.
I mean, none, which makes it fun to raise from you guys.
But markets are the only thing that matter.
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 one takeaway.
Do you think scale's market was great?
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 an autonomous car data labeling service.
I think again, what we did well was there was self-driving, of course, and 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 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 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 um, 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 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 a lot of thrash.
But there's these huge markets out there. 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 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 tk and everyone was like really going at it.
And 2019 or whatever, there's that deleted Uber, there's a lot of chaos.
But Uber is standing and is profitable, and obviously credit to Dara, but the market is insane.
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.
So I do think great markets can hide some of that stuff.
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 and 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 sheer brute force, not a lot of diplomacy.
In general, there's a lot of brute force involved.
And you can do the same with startups.
You can do founder-led sales, you can do brand, you can do marketing.
Scale up a whole sales team.
Really get far, and far ahead.
But 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.
People will see the falsehood here.
And so you do have to follow it with with product and why product is present.
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.
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 where you focus on product.
And ultimately, I think some of the for us especially, I mean some of the longer term modes 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, you know, way back when.
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.
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 where 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 15x 12x.
Your employee count is more than 1.5, 2x.
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.
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 go.
You know, this extends to engineers, 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 tragedy of the commons.
Something's 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's just a lot of things at 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 that clarity into action plans and execution.
So 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?
Like 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.
Yes.
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, that's 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 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.
At Harvey, we definitely have not nailed this, but- What did you do wrong?
So I think particularly early on in 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 hypergrow, 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 all the 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 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 the 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 memos 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 actually matters?
And it's not features.
This is like one framework that we have 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 a moat 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 are the operating cadence should be?
It's something that you know 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 what should the UX be and how much should be invested in technical debt cleanup versus not?
Those are 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.
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.
You know 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 you know, PMs on my team create prototypes all the time using cursor or using a cloud to show you know, 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, what the exact UX should be, particularly like, again with AI, when these new patterns are being established without actually having you play with it.
Some internal customers play with it, 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 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 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 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 you know 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 like 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 investor for a living.
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 you know 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 like, imagine a factory, like a conveyor belt system.
You have, okay, the customer says something and then PM writes to 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's how you demotivate your whole team, because no one wants to be just stuck in what they're.
You know the specific section.
And so the biggest thing 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?
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, 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 PMs 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 are 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 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 as like technical debt overall, it is just like you can go forever cleaning up technical debt.
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- Do 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 writing out 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 5 pm 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 postmortem?
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 to see why that happened.
How do we resolve it?
How could we have prevented it?
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 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 like 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, 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.
How often is the things identified as causing the problems, the things that cause the problems?
You know it's the Mike Tyson, you know 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, is like unknown, unknowns like COVID.
Or the customer is not going to like the feature or, you know, a new model is going to come out and it's going to wreck all our plans.
That happens sometimes.
On 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.
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 like admin IT teams are averse to change.
And so we can have a product launch.
And it's not GA to 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 the 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 we iterate.
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 like the whole general public.
And so you know this is probably true for most products and most enterprise teams is you want to make sure you're testing this way, like 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 ten things, and Harvey will decompose your initial prompt and suggest like OK, here's the ten things.
Am 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 show it to people, People 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, you know, 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 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 that 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 I'll pick.
One of them was the one I kind of just said right now around vault and, you know, 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&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.
I think it's maybe lawyers, maybe something else.
They just didn't know.
Hey, when I am creating a response to a complaint, what should I use?
Draft or assist?
And this is like, everyone had this complaint.
And then we started solving this by enablement, saying 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 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 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 it 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've 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 like tech audience, because everyone loved playing around with like 01 versus GP4O, 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.
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 Benchmark?
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 Benchmark public displays of evals.
Are yours correlated or are yours wildly different?
Yeah.
So our eval is very different.
A lot of public legal benchmarks and then even things like scales humanities, last exam.
They're all multiple choice.
I would love if legal work was multiple choice, but 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 not the right thing.
And so we created this benchmark called Big Law Bench.
Consists of tasks that a real billable work task 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 like hundreds of different tasks and each task has a rubric.
And the benefit that we have and we kind of architects from the beginning is we have a lot of lawyers that we have brought from big law to work with our IT 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 open AI 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, what is Claude better than OpenAI?
Claude, so we did this, 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 name thing in the deal.
You have to like 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 any 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 already?
If you look at, like you know Bunny, you've got OpenAI, which is deliberately chosen.
It is now going to be a consumer product company 129 billion in revenue, consumer product company.
I think very clearly.
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 the end 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 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 inside you want to work, you want to build products.
Maybe work with some particularly 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 Codium.
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.
You know, I've heard some engineers say they like cursors 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 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 tailor the outputs that do not ensure is right?
And I know Kodium 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 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 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 replant, agent mode, lovable bolt are a little more attractive than some of the IDs.
Do your team prefer Kodium 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 good friends and networks of a lot of our team.
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 the 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 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 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 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 what happens.
And everyone's like we're going to need some indemnification, liability of like all these different things that if AI autonomy starts to take actions in the world, what happens and who is 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 like Claude or Chachapati for kind of therapy or like emotional advice, of like I'm thinking through this problem.
It's really 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.
Catch PT doesn't.
It's not as empathetic, unfortunately.
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 a higher sentiment and more happiness after doing that for like 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 Gen AI 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?
You know.
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 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 the 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 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.
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.
It's happening, right?
Well, I mean, it's not in the UK.
A Department of Culture and Department of Sport.
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.
But 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 something.
Yeah, I'm fascinated.
That's so cool.
I've never heard that before.
It's because whenever I have an opinion, I write it down and then my recall memory in my brain is not great, so I just need to write everything down.
No, I don't do it.
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 2 a.m. it's like, new show.
Okay, yeah, I got one that I can say out loud.
I'll say the other one's not on recording.
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?
Um, so there's a few things in, in different parts of my life.
Um, maybe in college.
Um, 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 go to 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 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 L.A.?
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.
Um, 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.
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 can you use AI in a way that you're not already?
Um, unit testing, uh, is, I think can be way more automated with, with AI.
Um, 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 do in your role, but because of decision making or resources, you're not able to do?
Uh, go on podcasts.
No, I'm already doing that.
Um, I think um, I would like to work on.
So there's Harvey.
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 want to just tackle that, that work, um, 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 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 company because OpenAI put 2 million on the table for your best engineer or Codium or WinCursor or whoever.
Yeah.
Yes, I think churn is very real.
I think the talent quote-unquote 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 space 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-melting 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.
Yeah.
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'm like... 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.
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 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.
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.
I'm 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 Gen AI in your product?
If so, you need Turing.
Turing is an AGI infrastructure company.
But 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 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.
To take the guesswork out of GenAI, visit turingcom.
Forward, slash 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 want to make your meetings way more efficient and save time.
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 is 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.ai forward slash 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 forward slash 20VC.
Let's make your meetings work for you.
All right, 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 14000 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 forward slash 20 product.
As always.
We so appreciate all your support and stay tuned for an incredible episode coming on Monday with Victor Lozate at Benchmark.
