Why CRM Needs an AI Revolution, with Day.ai Founder Christopher O’Donnell

If you ask 100 CRM users, you know, classic user interview questions to get to the core pain, it's all always 100 of them will give you some flavor of. I'm scared about things falling through the cracks.

Hmm.

All of them. Now why would we care about something falling through the cracks? Makes us look bad. You know, we're coming into work, we want to add value, but we want a sense of respect. You know what I mean? That's what's common across all of these departments, from engineering to sales cs. Everybody just wants to kind of feel like they belong, feel like they're, they're worthy, they've earned their paycheck, they're respected by their peers, they're not going to get fired. And this whole new world allows us to operate kind of at that level of belonging and respect and weighing in creatively on kind of how we want these conversations to evolve without having to worry. Just like taking notes. Like, I don't have to take notes in a meeting. I can make eye contact. Oh, my God, that's incredible.

Today we're joined by Christopher O', Donnell, architect of HubSpot's CRM, the one competitor to successfully challenge Salesforce's domino. Now Cristoper is building Day AI, an AI native CRM that reimagines how customer relationships are managed. What makes Day special is how it eliminates the data entry burden that plagues traditional CRMs. By automatically capturing conversations across email, meetings and messaging platforms, it constructs a comprehensive customer database without manual input. It's essentially self driving CRNT that gives salespeople the superpower of perfect memory and preparation. Christopher's vision goes beyond automation. It's about transforming how people connect and make business relationships more human by allowing people to be fully present. All right, we got a special edition of training data. We're on the road in Boston to see Christopher o'. Donnell. Christopher, welcome to the show.

Great to see you. Thanks for coming out to Boston.

Okay, before we get going.

Okay.

I'm going to set some context now. Some of our listeners are aware of this. Some may not be. There are three categories of enterprise software that sit above all the rest. There are three kind of super categories. There's CRM, there's erp, and there is productivity. And in the world of CRM, you've got this monster called Salesforce, which is the single most valuable company to have emerged from the cloud transition system. Salesforce has been a dominant force in CRM for a couple of decades with one exception. There is one company that has actually Mounted a successful assault on Salesforce. And that One company is HubSpot. HubSpot has the most beloved CRM product in the market with a billion plus of revenue growing at a nice clip with nice margins. It's fundamentally changed the shape of, of the HubSpot business. And the reason I mention all of this as context is because the man who built that business at HubSpot is Christopher O'.

Donnell.

So Christopher, can you start by giving us a little bit of the story of how the CRM product at HubSpot came to be?

Yeah, sure, sure. So I joined HubSpot through an acquisition in 2011 and I had sort of three chapters at HubSpot. The first chapter was really on the heels of the famous ICP decision. This is what they teach at Harvard Business School and other business schools, the kind of HubSpot case around the owner Ollie versus Marketing Mary. Yep, I remember, yeah, you know this decision very well and I think it worked out very, very nicely. So I came in right after the Marketing Mary decision, the second contact, second axis for contact pricing and so forth. And they really needed an email system. And so that was kind of the first chapter was Whitney Sorensen who's CTO there to this day. And I kind of mounting this assault into marketing automation, Marketing email. And it was from Zero Rewrite Replatform. We had about four months to get off of a well known enterprise email app and and we managed to do it. I was hands on, I built the front ends because there was no one really else to do it and, and Whitney did all the back ends and everything and we always kind of had an eye toward this universal contact database that felt like the vision and this sort of one stack unified way of doing it that felt like it was going to grow outside of marketing email. So about four months to using it internally, about seven months to bring it to market, we were able to take the company public and arguably win that category. Marketo was the big competitor and they went public and then went private and have kind of faded away. The second part of my time there was what you're describing and it was interesting. I started to build a product management practice. This is end of 2013 and as that kind of came online and I was able to give the marketing stuff that we had been working on to a team and let that start to scale out. Kind of like the fishermen throwing the fish back in the water started over. We did a startup within a startup. Stanford's actually doing a case on it now which is I think going to be really, really interesting. They have some folks there that study this kind of innovation. It was very innovators dilemma. Literally from the book ripped from the pages of the Clay Christensen. How do you get that what Brian Halligan would call the second S curve? How do you do that in an environment where incremental investment in the core product is going to yield margin, it's going to yield results.

And HubSpot is one of the very few companies that pulled that off. And so what did you do to make that work? Because I think the default is that it doesn't work. And in HubSpot's case, it worked to wild success.

Yeah, in hindsight and talking to the Stanford people, in hindsight, it looks like it was very smooth and brilliant and it was rocky and hard. You know, it was really messy. I give credit to the founders for their decision to do a startup within a startup. So we did what the business school professors would call the skunk works. We literally hung up a pirate flag behind us. We had a small team. It was at the beginning, just me and Mike Peachy, my co founder at Day AI, and then kind of grew the team from there. We were on our own stack. It's a cool story. I mean, it's really neat how the strategy played out. There was a big question about core CRM versus sales acceleration and we were seeing a lot of tools, you know this space extremely well. We were seeing a lot of wallet share going toward these kind of plugins to CRM that would maybe give you more enrichment data or help you do better presentations or write better emails. And so we started there and did email open notifications, the simplest possible thing. We did it on our own stack. We did our own stripe billing and had a lot of fun with it. Built that kind of into a sales acceleration suite and a year or two into it also made the decision as a company to do core CRM system of record. This made a lot of sense to product and engineering. We were very on board with this and had built things in a way to set ourselves up to be able to do this. And so it kind of merged. It was a sales acceleration suite on top of CRM. We grew the team to about 100 people, went from zero to about 40 million in revenue, and then were acquired back into the mothership. And that happened department by department, which I think is really interesting, which in a traditional normal acquisition of another company wouldn't be how it's done necessarily, though it's actually not a bad idea. An interesting way to think about getting an Acquisition to be successful. So sort of engineering went first, then product, you know, up the stack through sales, and finally to customer support. That was the last thing to kind of integrate. And part of our mandate had been to reinvent, go to market and explore these bottoms up adoption methods, bottoms up monetization. And there wasn't PLG back then, right? Nobody had a PLG blog. There was no such thing. And so we were kind of discovering that for ourselves, while some other companies were as well, you know, Expensify and Atlassian and there are a bunch of examples in hindsight. But again, there was no real textbook. So we were sitting there like, oh, we could generate demand from this feature and rotate it to sales. And then peachy. And Mark Roberge, who is a huge part of this chapter, came in one day and had this spreadsheet where they had figured out the lifetime value by product area limit that people had hit. I still remember where I was sitting when they showed me this on a laptop. They're like, look at this model we made. And that was just a massive breakthrough. And that led into the third chapter where I was fortunate enough to be steward of the overall team and did that for four or five years. So yeah, it was, it was really interesting. It was a great opportunity.

And on the CRM piece of that, because I think that's, I think that's exceptional in part because CRM is such a big obvious category for people to go after. Nobody else has been successful. You guys were successful. I think that makes it really exceptional. The second thing that I think makes it really exceptional is the default is for Act 2 or a startup within a startup to fail. And based on what you just said, there are kind of three things I heard as maybe big strategic decisions or big principles that certainly didn't cause it to work, but maybe helped set it up for success to some degree. One was the startup within a startup, and that being a real thing, you guys were legitimately by yourselves as opposed to feeding off of the resources of the mothership. Second was a little bit of the end around, you know, starting with the sales acceleration tools and getting the system of engagement, so to speak, before going into the system of record, which is core CRM as opposed to a full frontal assault and starting with the system of record. And then the third thing is the plg. And to your point at the time, that wasn't necessarily a thing. So you kind of had to invent the playbook as you went. Let's transition a bit into day. And so with day, I see Similarities. And I see differences. One similarity I see is plg. One difference I see is the full frontal assault. Because my understanding with Day is that you're not sneaking around the edges and then popping out of a cake and saying, hey, we're a CRM. You're actually starting with the CRM. So maybe we start with that before we get into that. Why does the world need an AI native CRM? Let's start with that.

Yeah. Well, it's an incredible time to be doing this from scratch. And there are 14, 16, 17 fundamental things about all of the existing CRMs that are never going to change and are huge drawbacks. You know, fundamentally these systems are supposed to be working for you and they end up being things that we work for. There are a few fundamental problems. There's the data problem where there just isn't canonical data. And we can talk more about this because it's a big topic and a really interesting one. But even the best CRM implementation on the planet is probably 40, 50% of the data that it even thinks that it should have, let alone what is now possible. So that's the first problem is how do you actually populate this thing so that it has all of the information so that you can do your job? The second problem is user workflow. You know, where do you start? How do you get something done? How do you answer a question? Typically, if you see a heavy CRM user at work, you're going to see 40 tabs open with that CRM, you know, all the way across. And so it's very easy to lose your place, it's very easy to lose the plot. And you're not working back and forth with it to really understand a relationship. And that leads into the third part, which is walking away from it with some sort of work product.

Yep.

You know, CRM users are not sitting down and doing things, asking questions, getting answers, and then walking away with an incredible internal memo or a knowledge base article or an email draft, or prep notes for a meeting that's happening somewhere else. Maybe it's happening in Notion or Google Docs or something. And it seems like a really obvious thing that you should be able to sit down. The CRM has the full history of everything that's happened between the company and the customers. It's extremely obvious where to start and we can talk a lot more about that. And at the end of that thread, whatever it is, prepping for a meeting or following up on an email, or reviewing all of the deals, if you're a sales manager, understanding what are you going to do this week? Where are you going to dive in? Where are you going to help out? You know, I have a fundamental belief that people really do want to buy things. Yeah, you know, I've always built sales and marketing tools from the perspective of a buyer. I'm in those databases as like a decision maker. You know, I'm getting those calls more than I'm making those calls. And I'll tell you, buyers, we love buying stuff. I love buying things. You know, I. I like buying datadog and configuring it and learning how to, you know, have richer traces and doing all this kind of stuff. I mean, these are. This is like Christmas. And it doesn't feel that way to reps. I also like sales reps. I like working with a rep. I like building the rapport. And so it's this kind of combative relationship that I think is gunking up the economic engine of a bunch of earnest, good faith people trying to deliver value and push their companies forward. It doesn't need to be this hard. And a lot of it comes down to trust, improving relationships. That comes from keeping promises, remembering details. And there's a lot of fear there, too. You know what I mean? Sales is a hard job. There's a lot of rejection. There's a lot of disappointment. And that bleeds into everything else. That bleeds into the life of that person and their family. So I think all this could be a lot more fun, frankly. We're incredibly blessed to live in this age of software and be able to use cool things at work and have interesting conversations with interesting people, and we ought to be able to do it a lot better with no extra effort.

Yeah, I would bet there are a bunch of people sitting in Salesforce Tower in San Francisco thinking to themselves, wait a minute, we're going to be the AI native CRM? What would your response to them be? Why can't Salesforce build this?

You know, look, I do think that anybody can do anything and there's nothing stopping anybody. I mean, we're just a handful of people with laptops. And the flip side of that is the data model is going to really need to change. So if we think about CRM, traditionally a really good way to think about it, Eric Munson, our founding engineer, talks about it this way, and I really like it, which is we have compressed the data. If you have a lot of data, one way to store it somewhere is to compress it down. So you can think of legacy CRM data as a photograph that has been down Sampled into pixel art. And it's just a few little blocks. It's like one of those crypto apes kind of thing, maybe not as valuable. And so it's really radically down sampled. Why? Because people have to put this data in.

Yeah.

And so you're really limited in terms of what you can ask for. You're only going to add fields into the CRM to collect data. If you think somebody is going to have the wherewithal to actually fill it out.

Yeah.

Otherwise it's going to remain empty. And so that's kind of the fundamental principle. And I think the legacy CRM companies are going to do a pretty good job of going from kind of 8 bit to 16 bit. But there's this opportunity to say, well, hold on a second, we now have what we need to build PlayStation 5 with ray tracing. It's like going from Super Mario Brothers to Elden Ring is really what's possible. If I show my parents modern video games, they believe it is reality. They don't really immediately grasp that it is a video game. So that data decompression in the CRM, why is that happening? How is that happening? But in terms of expanding this, why do we need this to understand relationships and to allow people to do these things, give them these workflows, allow them to ask questions, allow them to walk away with work product, you need as close to the actual reality of those conversations and relationships as possible. You need the full picture. You need to invent, not just a camera to take a photograph, you need a 3D reality scanner and you need a way to store that. Right. And so that kind of pulls into a couple of elements. One is everything is about context. So if you want to build a chat interface where you can ask a CRM a bunch of questions, which we are not the only people who will try to do this and build this. You need the data that you're working with to be of a certain type. It needs to be very detailed, it needs to be a natural language, it needs to not assume what's going to be valuable in a particular context in the future. And so the primary aspect of this compression of the data over time has been reducing it down to a checkbox, reducing it down to a dropdown. And with AI, you don't need to do any of that. You can just have all of the raw conversations and maybe you can transform them into in some ways so that they're more convenient, more portable. But all of that needs to be interlinked, all of that needs to point back and Forth with citations and sources. There needs to be provenance. You need to understand why an answer to a question is, you know, if you say, you know, what's my team going to do this quarter? And it shows you a chart, that chart can be absolutely perfect and, and it will not be a usable product if you can't inspect that data and go into the details and understand all of the assumptions that the AI is making and point back to all of these different things. Right. If a CRM is generating a to do list for you, which we have, we won't be the only ones doing it. Why was this generated? You know, why is this bug in the, in the support inbox? Oh, it's this moment in this call that generated this thing and then we deduplicated against this thing that came from a Slack message where somebody said a similar thing. Here's how they said it. Right. And so it's not just six tables in a relational database that have foreign keys that point to each other. It's this constellation, endless kind of universe of data points that are all interlinked. So to the question of why can't somebody do it? They could. I think data migrations are extremely painful and large incumbent, you know, $100 billion trillion dollar companies have done them. Netflix has done one, you know, square, you name it, you know, people have gone through these data migrations. They're generally moving from one technology to a relatively similar technology. The idea that the use cases around the core data of a company, a system of record company is so wildly different.

Yeah.

So suddenly I don't think there's an example of that.

And if I am a sales rep, an account executive, what's the biggest way in which my life will be different with AI native CRM versus whatever I was using before?

I think the way to think about that would be, you know, how is life different with a meeting recorder and without a meeting recorder? If you, there are a bunch of these meeting recording bots out there and many of them are really, really good. And if you read the verbatims, you know, they're largely five star reviewed. A lot of stuff is five star reviewed reviewed these days. I'm a little skeptical, but, but these are great products and if you read the verbatims, it's not about this feature, it's not about that feature, it's I can be present in a meeting now. Yep. So that's the benefit and that's a glimpse into the type of benefit that you're going to get across the entire business and And I think people are still tied to this idea of data entry is cumbersome. We should make data entry better. That's a little bit like the 16 bit PAC man.

Yeah.

You know, data entry as a concept will entirely go away. Now. Being able to shape things and sort of say, well this part of this is not quite right. Or I kind of agree with this take over here in the system learning and adapting. We need to have control over these systems and with these systems and be able to work and coexist with them. But we don't need to be entering this data. All of that administrative work goes away. We don't need to be writing an email from scratch. We can be looking at the email and weighing in on what we think we can be maybe developing as a team the way that we want to email. And it kind of moves up a level. And so everything becomes much more strategic and much more intentional and we aren't going to forget things. The classic thing, if you ask 100 CRM users classic user interview questions to get to the core pain, it's always 100 of them will give you some flavor of I'm scared about things falling through the cracks. All of them. Now why would we care about something falling through the cracks? Makes us look bad. You know, we're coming into work. We want to add value, but we want a sense of respect. You know what I mean? That's what's common across all of these departments from engineering to sales cs. Everybody just wants to kind of feel like they belong, feel like they're, they're worthy, they've earned their paycheck, they're respected by their peers, they're not going to get fired. And this whole new world allows us to operate kind of at that level.

Yeah.

Of belonging and respect and weighing in creatively on kind of how we want these conversations to evolve without having to worry. Just like taking notes. Like I don't have to take notes in a meeting. I can make eye contact. Oh my God, that's incredible. Now take that to prepping for the next meeting. I'm prepared for the next meeting because I remember all of these details and by the way, these other things have happened and that's really valuable context and I can incorporate that really easily just by asking the right question or clicking a button to meeting prep. Right. Yeah. So the level of effort basically goes to zero and the level of presence and human respectability and self esteem shoots up. I think that's going to be the biggest change.

Yeah. It's interesting that a lot of the examples you gave have AI actually making people feel and behave more human. You know, it's a nice example of like AI enabling people, AI providing superpowers to people. I want to ask you a question about DAY itself. And specifically, you started the company. You and Peachy started the company maybe five, six months after the ChatGPT moment. You started, I think April 2023 or thereabouts. What was it that inspired you to start a company? What did you, what did you see? What made you want to build from scratch again? Kind of what inspired that?

I think it was as far back as 2017 that I said out loud, I'm never building a product from scratch without pg. So he kind of came on the job market and I could kind of make that work. The ChatGPT thing was capturing our imagination and it just felt really good, like the stars aligned. In retrospect, I don't think we could have picked a better time. Yeah, it was a little early. So it was that right at the end of the spring of 23, and the ChatGPT had its moment. But the fundamental stuff of what we're doing in this trade of taking natural language and building and editing and updating structured output that then gets used, you know, to sort of rinse and repeat, that was not possible yet. Yeah, that became possible in June of 2435 Sonnet. You started to see glimmers of it with GPT4 and function calling and you could kind of coax it into returning JSON and that kind of thing. But we really had a year of understanding the problem space and starting to understand what was going to happen with the AI that that had not. So that was that perfect window. It's kind of like if you're surfing, you catch the wave a little early and then you swim like hell to try to drop in on it. And I think we kind of maybe got lucky there. It's funny, I was looking at some old code that I was killing the other day, and I was looking at the ChatGPT35 Turbo era and the prompts that we had in there and it's like all caps just begging for it to return a type safe object. And then, yeah, in June of last year that became possible. And you could say, hey, look, Claude, here's what we're trying to do. Here's the context we have. This is the type of output that we need to be able to work with heuristically, right? And it's that hopping back and forth between heuristic and non deterministic worlds that makes our days colorful and long. You know, that was when it was really possible. And it was July, basically July 1st. I remember because I took a few days before the 4th to just go deep and I went up to New Hampshire and just opened up my laptop for 72 hours and started working on some of the pipeline stuff and actions to do stuff. So that's kind of when we let it rip. Before that, it was mostly the, the meeting recording aspect of the system, which we knew we needed for a bunch of reasons as an entry point into user workflow. It's a really good one because it's that moment of contact. And so if we can have some seat at the table, we knew that would be strategically interesting. We knew that these were really easy to adopt. It turns out they're very sticky. We have basically 100% user retention. I don't think I've told you this, but maybe. No, I showed you some data on this. That's why you still hang out with me. But they are actually pretty sticky and people will try different ones but have stuck with ours because of a few particular qualities of it and how it's integrated now into that deeper CRM stack. Principally, though, we needed to capture that data and we needed to be able to capture the raw data and massage it, transform it, you know, kind of cook it, chop the wood, as we say and use that to start to feed the CRM. So that. And then Gmail. And we had been doing Gmail in that first year too, which is, you know, I wouldn't wish on anybody. It's hard, right. Google Calendar and Gmail ingestion is tricky. And then we added Slack and continue to add data sources from there. But it was really July of 24 that we started on core CRM.

And the basic idea in what you said with the meeting recorder and Gmail and Slack is be present where your users are and ingest as much context and information as possible so that you can sort of auto populate or even auto construct this CRM that they need. Is that the basic idea?

A hundred percent, you know, peachy. And I have had this idea for a long time of the Spotify of sales.

Yeah.

You know, the idea of somebody who grew up with Spotify that you would choose a CD to buy.

Yeah.

And then that would be your cd.

Yeah.

And you know, the ones that you prefer you would keep in your car. So that of those eight disks you could easily access them. And you know, and we all had the visors. You have one of those visors Oh.

I had the thing that sat in the backseat. You know the little binder full of discs that kind of sat on the floor in the backseat.

Yes.

Yeah, that's what I had.

Yeah, exactly. I think this stuff is going to feel that ridiculous. You know, Dan Chen, one of our early users who you talk to, and I think he made this comment to you as well. The next generation of people coming into the workforce, it's not going to be this idea of data entry is too cumbersome. They're going to look at these things and people are going to explain something like Salesforce to them.

Yeah.

And they are going to think that they are on Punk'd. You know, it's like, hold on a second. So I do these zooms and I do these emails. Yeah, yeah, okay. And then I like DM with my prospects and we do all this. Okay, cool. And then I tell the computer all of that. But like I put that into the system. They're like, yep, right here, it's that button right there. And then there's a form and you got to fill it out. You really have to fill it out. It's going to be completely insane to people. So back to the ingestion, if you're going to do that, you know, Spotify had to go out and do contracts to get access to all of the. All of the data for us that is binding to these inputs. And they're natural language inputs. You know, it's plain text. And then bringing in some of what we know about the CRM data model, even though, as I've sort of hinted at it, under the covers looks totally different. You are going to want to be able to see a list of people and a list of companies. You know, you're going to want to be able to add a column if for no other reason than inspecting it so that you can trust it. You need to be able to do all of that. So that's all 100% automatic. Folks come in, they sign up, they invite a couple of coworkers, they off their Gmail, maybe they add the bot to Slack and within half a day, four hours, eight hours, the entire CRM is built. Contacts, companies, deals, tasks, everything. Deals is the interesting one because you have to have this idea of business process context and that's kind of advanced mode, I think, building company records, contact records, not that it's easy, but it's a lot of looking at the web, it's a lot of know that type of thing. And you have domain and email address to work with. When you start to get into, to DOS and opportunity management and all the rest of it, it's like, whoa, okay, hold on a second. You know, what does this mean? What is, what does due date mean? What does this stage in this pipeline mean?

Yeah.

And so getting it right requires a lot of input from the user and they may not show up having all of these answers. It's not like everybody shows up and says, the entrance criteria for our fourth stage of the business development partnership pipeline is the following. You know, they don't know, they don't know. And so you have to kind of get that metadata out of them and then use that as you're looking at all of this data and continually return to the data set as things change and reevaluate things move a deal from one stage to another because a particular meeting happened where particular things were set. Like I said before, you need to show proof of why you did that. And then on top of all of that, the user has to be able to say, no, no, no, it should be over here, let me weigh in on this or let me make a hard edit to this. And so it really is very, very different under the covers.

Yeah. It's almost like self driving CRM.

It is self driving CRM. And you know what we learned? You do know this, I know you know this is that. So that was kind of that arc from July through. Then we got into automated opportunity stuff in November and up through, you know that. I can't believe it was a month. Oh my God. So by December, what we, what we were learning was full self driving is too scary. Yeah, it's too scary. And so from New Year's to now, the big push for us, it's, it's been getting that last 10% of data quality for sure. You know, avoiding false negatives on saying something's an opportunity, getting to do's right, we call them actions, getting actions right. But it's really more about this control and configurability layer.

Yeah.

And getting the balance of the best, best of both worlds where okay, the data is right and I can also correct it. I can also understand why it is what it is and make sense of it. I can debug it. Sources and reasoning. Right. A very simple example of this is perplexity. You know, if you do a search on perplexity, it'll show you the web pages that it's using to build the answer. Yep. And this now becomes kind of the core product challenge, I think for all of these AI native apps across disciplines is Managing transparency and managing control as you are prompting and working with the LLM, being able to approve the output, being able to have rules and instructions about the output so that it sort of fits your standards. I think on some level, we're all in a similar game.

Yeah, yeah. Which all comes back to trust. You know, can you trust what the AI is doing on your behalf? Let's talk about building with AI a little bit. Can you share maybe some of the surprises or some of the magical moments along the way?

Yeah. So I. I am a heavy personal user of the AI coding apps. I've tried. I can't say I've tried all of them because there are so many, but I'm regularly checking back in with. With most of them. I've most heavily used Cursor and have been pretty deep in that for over a year. These things are evolving incredibly quickly.

Yeah.

Week by week, they will have not just pros and cons and sort of ones ahead of the other in the horse race, but they're dramatic movements. You know, one week, Windsurf will do something kind of cool, but people don't really like the pricing model. And then the next week, Cursor says, okay, well, here's, you know, a new way of doing rules management and system instructions that's like, way ahead of what anybody else is doing. But then a new model comes out and it responds to this stuff differently. And so it's like, oh, you actually shouldn't use any of that in these types of circumstances. So it's really a moving target. It's fascinating and thrilling to kind of watch. One of the things that's happening right now as we speak is that less context and less instruction layer in a lot of cases is better. And so apps that have less of that off the shelf. Right. Like, fewer features, fewer stuff going into particularly three seven Sonnet, you get a better result for a lot of questions. And so, you know, you have companies that have been adding all of these features to let you do all of these system instructions, and then it's like, whoa, how do we respond to this? So, man, you know, long days and nights for everybody working in that field. You know, one interesting thing about that playing field, I will say, is that they are all working off of the same raw input. They are all able to look at a code base.

Yeah.

And what's interesting for us is there's no code base. You know, we have to create the code base and then we have to do the kind of coding stuff on top of it, which is. Which is really interesting.

Can you talk about how going from a world of software that executes things deterministically to a world of software that is in some ways deterministic and in some, some ways probabilistic, how does that change the art of building software products?

I will say that generally speaking, software engineers are not liking this. It's not the kind of curveball that they were hoping for, I think, you know, I mean, and there are ways to kind of coax it into being more deterministic. So in terms of surviving the day to day and really making progress, a lot of stuff, you know, you turn down the temperature and you kind of say, okay, you know, especially when you're doing natural language, just structured output, but it's still non deterministic. Yeah, I think hallucinations are not nearly the problem that we would have thought a year ago.

Okay.

You know, a year ago having this conversation saying, well, this ChatGPT thing is just saying some nonsense, you know, what are we going to do about this? A lot of that's gone away in this type of use case. I can't obviously speak for every use case, but if you're saying, here's a whole Gmail conversation, you know, is this a promotional email, is this a cold email, what's going on? Are there pending action items and so forth, There isn't an enormous amount of hallucination, you might get a slightly different result. And it is tough because there isn't a lot of tooling out there for, you know, non deterministic stuff. I think, you know, from a, from a venture perspective and so forth, the new generation of tooling is super interesting for sure because this idea of eval and obviously a lot of people kind of in this race, but you know, these are really interesting products that are really valuable to product builders like us that are going to do really well. So as that tooling matures, that's another kind of tailwind to it. But if nothing had changed from where things were a year ago, it would be very scary.

How have UX patterns evolved in a world of AI?

The UX patterns I'll say a couple of things about. One is consumer grade. So we have talked in B2B SaaS for a long time about consumer grade. And the truth is what we meant was kind of a coat of paint, a design system, a big investment in information architecture and trying to arrange things in an intuitive way and so forth. We did not mean, you know, Facebook native mobile app level transitions and auto scrolling and you know, all this kind of Stuff. And so the work that folks at Anthropic and chatgpt and Perplexity and these types of companies, they're building consumer products.

Yeah.

And the quality is extremely high. They are very well funded. They have the best engineers. A lot of those engineers are coming from social media and consumer apps. And so the level of polish is insanely high, which only in the last, I would say month, am I coming to fully appreciate because I'm matching up our stuff against, you know, what's out there. And in the past, when you've done that and kind of looked at what's out there and where the bar is, you know, you can get over the bar.

Yeah.

And B2B SaaS, you, you can do it. Maybe you need to invest more in design, you know, value it more, give them more of a seat at the table. Now it's a little different. And things are going to need to be unbelievably fast, unbelievably smooth. So that's one. In terms of ux, the second thing I would say is control and transparency balanced with automaticity is the core attention. So if you ask a user, do you want all of this to be done automatically for you? Of course they're going to say yes. When you do it automatically for them, they then have a lot of questions of why things are a certain way, what they can do about it. And there are a lot of levels in there. Do you want to let the user just flag something as a miss? Maybe not that valuable. I mean, everybody's doing that, you know. But how often am I in Claude Webb saying thumbs down? It's, it's, it's never like a thumbs down in Claude Webb. It's, you know, let me push you in this direction or let me. You're missing this piece of context. Okay, yeah, let me paste this document in or whatever.

Yeah.

And so you have to be able to do that. You have to be able to manage the context that, that the system is using. You need to be able to undo and correct the data. So we have a document internally that Daphne made, Daphne Funston, and it's called the Rules of the Game. And it outlines like, hey, anything we do, you have to see why the AI did what it did. You have to be able to override it as a person and know that you're overriding it, not have it flip back because you'll run into that too.

Right.

Oh, I moved this thing, you know, into this stage because, you know, I thought it was correct, but then the AI moved it back.

Yeah.

Okay, well, what do you want? Do you want the AI to be able to continue the decision making after the user has weighed in? Sometimes, not all the time? Again, the data model is sort of ridiculously involved. To be able to give the user very basic things like, hey, if I say that the status on this thing is such and such, it needs to what, update the status and never change it or take that piece of information into account for every status that it prints moving forward. In that case, probably the latter. The UX patterns around control, progressive disclosure, you know, it's show me the clean shiny thing that's automatic, but then let me turn it around, you know, let me flip the hood and see what really happened leading up to this. And so I think that kind of modality is going to be really interesting.

You mentioned the document that Gwen put together, which is a little bit of a glimpse into how the day the company works. Let's talk a little bit about day the company.

Yeah.

And maybe starting with two things that are on my mind. One is I think you guys are a very good example of this idea that a lot of people have talked about, which is you can just do a lot more with a smaller team. And particularly now that we're in a world of AI, you can do a lot more with a smaller team. Team is very small, but it's very high caliber people and you work extremely well together. The second thing which is what I want to ask you about is I tend to be a big believer in, in office culture. You know, we, we Sequoia have been back in the office since May of, you know, we're five days a week. We think it, we think it works. You guys are not all in the office together and yet you seem to have extremely good flow. And so I guess the thing I'm curious about is how do you achieve that? How do you get this small group of people in different corners of the country to come together and actually have extremely good flow?

Yeah, no, it's a great question. And the spoiler is I bet we'll end up in the office. Yeah, I bet we will. You know, fewer sites, I think fewer time zones is generally good. And we've been kind of letting the universe sort that out for us. And it may be that the universe just sorts it out and that we end up in an office together in Boston. And going into that office, I think having had the experience that we're having now, the flow will be very different. Peachy wrote a really cool post on LinkedIn about the off site that we had recently and a couple of things about it, characteristics that I think are emblematic of the way that we work. You know, our company culture. Yeah, but it's. It's really just, you know, the way that we work. And to your point, I would say they are very high caliber people. There's a little bit of a. A thing to these particular people in terms of their level of emotional intelligence, how much they like the work for the work's sake. The willingness for everybody to be so directly exposed to customers like, this is not all for everybody. I, you know, I wouldn't, you know, stand on a soapbox and say, everybody should do this, but it works really well for us. And it's the kind of people that we want around. You know, if. If an engineer never wants to reach out to a customer to verify that a bug is fixed, like, they're just not gonna have a ton of fun. You know what I mean? So that's a really important layer. Is that the primary source material? It's kind of what we're trying to do with the product. Right. And we use our product for this too. If you say, you know, oh, that's a great idea, that would kind of get us the thing for Dan. Yeah. Everybody knows what you're talking about, and everybody's following along on the plot and seeing what you're synthesizing. So that's kind of an unwritten contract that we've all entered into, which is, you know, I am willing to hold an enormous amount of customer conversations in my head so that we can have these conversations. I find it makes it really fun, you know, it makes it possible to come in and do a day of work where you feel like you've actually made a difference for somebody. Now it's software. So making a difference for one person, if you've chosen the right person, you know, it's going to make a difference for a lot of people. And the team's nice. You know, Daphne joined. I asked her a few days in how it was going, and she said, everybody's really nice. And that's part of it too.

It's.

I think part of that comes with seniority. It's the emotional intelligence part of it. It's the, you know, people are kind of here doing it for similar reasons. What would.

I don't know. If you've codified the company's values, if you have, what are they? If you haven't, what would you say they are for the people who are on the team, what's their Lived experience of what the company cares about.

Yeah, the lived experience is very truly customer driven in a literal sense that.

Our customers talk about the same hour bug fixes and same day feature releases. It seems like the feedback cycle is incredibly fast.

That's the fun right there.

Yeah.

You know, if you're going to do something anyway and it's the right thing to do, you can do it right then and get word of mouth and get momentum and thank somebody. I mean, this is early software, this is early stage software. People are investing their time and energy into this and we need to reciprocate, you know, we need to show them that it's worth it. If we do that, it'll be really fun for them too. And they'll feel like they're a part of something because they are a part of something and their feedback is creating this, this larger thing. It's one reason we've kept it a little bit on the smaller side because you can't do that forever with, you know, not even a certain volume of people. Because I think you can, I think you can do this with a very large volume of people. But once the product is at a certain maturity and once you've really nailed who those people are, you know, this last year and a half has involved a lot of kind of understanding. Okay, what's this like for solopreneurs? You know, you know, there's a case to be made that this, that we should try personal CRM or, you know, very small business founder CRM. Or that we should start with VCs, you know, because they're early adopters and boy, they're certainly willing to give it a try, you know. And so we've kind of been updating ICP and doing that, staying focused on the people who we take the most seriously in terms of having strategic weight. Yeah, it's easy to take those people very seriously and build a thing for them that hour.

Yeah.

Because you are giving them credit for being right. Yeah. In a very macro sense. Like you have it. There isn't, you know, a product management off site and you know, sticky note sorting exercise to be doing around it. It's like you are the user, you know, you are correct. We will do the thing and it happens to be really fun for them, which makes it fun for you. The other thing Peachy noticed about our off site is we pull the work up like. And I think the pithy answer to your question of how have we been getting by remotely? It's a lot of slack huddle. Yeah, it's a lot of slack huddle, very low stakes. We don't have any recurring meetings. And when we get on huddle, I'll get on huddle with Gwen. We've had a bunch recently and we'll work for six hours, you know, and it's kind of magical to be able to do that. So there's a whole practice of pair programming. I actually don't know anything about it. And in the body of knowledge, I should say stop and probably read a book on it. But that is actually really great. You know, you don't want to go out for a huge hike or mountain climbing thing by yourself for a number of reasons. And you know, diving in to do some of this data model stuff. It's buddy system that's worked really well. And I don't think that the gulf between the customer and the code needs to be as wide as it is. You know, we're used to these sort of senatorial trappings where you ultimately have go to market and R and D sort of as the Republicans and the Democrats.

Yeah.

You know, and everything is some flavor of managing expectations for their frontline people who are the voting base that have all the power in a SaaS business. Right. And so there's a lot of distraction that comes with that. There's a lot of subtext, there's a lot of peeling it all back again. Everybody having good intentions, like everybody solving for the customer, like best possible case. You have this huge gulf. And so we're trying to build and I would say at this point, really have a culture where, you know, here's this question from a customer, here's a doc on it. We do a lot with docs, we do a lot with the written word. You can't compete with the clarity of the written word, I think. But pull the code up, you know, pull the code up. It's not like this secret backroom thing for just the software engineers, like look at how things are labeled. Look at the conditionals of when we show that button and when we don't. Let's look at it together. It's not rocket science. Some of it's going to be pretty opaque. If you show it at a company level, a lot of it isn't, a lot of it isn't. And so that lets us get to technical decision making and polish a lot faster too. And again is kind of fun and rewarding.

One more question and then we'll jump into the lightning round. So one of the mantras that applies to some businesses and I think it applies to Day in some ways, which I believe is stolen maybe from the Navy SEALs or some other branch of the military, is the idea that slow is smooth and smooth is fast. And you are anything but slow when it comes to working on the product. But you've resisted the temptation to juice the vanity metrics that a lot of startups feel pressured to juice. Said differently. Your customers today are as much design partners as they are customers. And you've been very deliberate about crafting a product that meets a certain bar of excellence or certain bar of quality before releasing it out into the world. And I guess the question is, where did that strategy come from? Is it AI specific? Is it just the way you like to build products? What's sort of the philosophy behind the slow is smooth, smooth is fast strategy?

It's not typically what I would do. It's not. I like the Y combinator wedge kind of thing. I like incremental improvement. I like broad customer exposure. With the exception of when you are doing software that is of a certain scope and stake, that the investment that you need from somebody to get any feedback is very high.

Yeah.

And the scope is also very wide. I mean, part of it is I don't necessarily want the entire world to know how wide it is, but I guess they'll find out from. From this. You talked about the three main spaces.

Yeah.

I mean, we're doing the entire CRM.

Yeah.

It's every function, a lot of surface area, AI native, everything. You know, it's probably going to happen faster than people expect.

Yeah.

So doing things in that way, where we are trying to meet this bar with a particular customer, this is system of record software. You know, I don't know how Parker did rippling. I'm guessing he didn't say, let's launch payroll in one state. Yeah, maybe he did. I'd actually be really, really curious to hear the story from him. If you're doing HR payroll, you know, benefits, there is a level of completeness that you need to get to, you know, even be in the game. CRM has some of that. CRM. You can get a little bit cute with some use cases and say, okay, here's a meeting recorder, but there's a contact sidebar, and it has, you know, personal history and everything like that. And it's a CRM record and you're sort of Trojan horsing in. So it's not what I would typically do. I think it's very appropriate for us now. And I also think that, you know, we're setting ourselves up for the Very, very long term. The thought experiment of, you know, if you are in a race to a million arrows, how do you think about things? Think about the Y combinator, which, okay, and you say, all right, let me break your brain, you're in a race to 100 million ARR from zero. How do you think about things? You immediately start to think about things differently and you think, okay, well we're going to need something that people just don't cancel, that has a certain asp, a certain adoption pattern and so forth. It doesn't force you out of the way of thinking. Go to market or SaaS economics or anything like that. So when you say you're now in a race to 10 billion ARR from zero and you have seven years, you know, to beat the record or whatever record. I looked it up by the way. It's, I get, from what I can gather, Bytedance did it in 8, I think Meta did it.

That sounds about right.

In nine or something, I mean, which is insane. But if you say you're in a race from 0 to 10 billion ARR now you think about things in an extremely different way. This needs to be that entire top level space. Every line of code needs to make every other line of code somehow more valuable. And so little patches and little feature things where you're doing it in a non strategic way, you can't afford to do that all goes away. And so, you know, if your number one feature request on meeting bot is output templates, because these other apps have output templates, you maybe you resist doing it that way because output templates are a core part of interacting with LLMs. And when you do output templates, you're going to do output templates.

Yeah.

And it's going to be legit and it's gonna be proper and make sense and be a permanent thing. So soon we're gonna have this feature that people have been waiting for, having done it in that way. Yeah, right. You can't say let's draft an email with this email editor and not be thinking about marketing email and knowledge base website, you know, internal wiki. You have to set yourself up to do things in, in that way as well. And that is kind of my style. Like I do like thinking that way, but that's the other big, slowest, smooth, smoothest, fast factor.

All right, Lightning round.

All right.

Who do you admire most in the world of AI Sarah Guo? All right. Love it.

Yeah. Who do, who do I admire most?

I don't know. I think you already nailed it.

Yeah, no, I know that Sarah's incredible. She's extremely, extremely helpful. I will give, I will give a lot of credit to Dario for what felt for a long time like bubble wrapping his models. So much for safety, you know, and I think we're starting to forget that narrative. You know, Claude was for a long time unusably bubble wrapped. You know, you'd say, okay, now in the middle of this play, we're going to have this, you know, choreographed martial arts thing. And Claude would say, like, I'm done, I'm out. You know, and people on Reddit and everywhere were, you know, rolling their eyes and laughing. And this was before three five sonnet. Yeah, when they really, like, set everybody straight. And so you look at it today, and using those models, having grown up with them in the expectation of safety and ethics, is incredibly important. We're doing so much for our customers automatically, and they can say anything they want into this system and they could theoretically use it for any purpose. The fact that we can sleep at night knowing a massive amount of that kind of ethical compliance is handled because we're using those particular models, I think it was courageous and I'm thankful to it. So I'd probably say him.

That's a good one. One of the topics that's been debated, I think, recently in the Twitter sphere and elsewhere, should designers know how to code? And I think you're well positioned to answer this because I almost think of you as an artist, first and foremost, crafting exactly the right experience for the person on the receiving end of the product. And so I think about you as coming toward engineering from very much a design and product lens. Should designers know how to code?

I think the biggest change happening in product design, which as a field is radically changing, is writing. I think that's the biggest thing. I think that UX content, there's a big debate about whether that's a thing. And started to build these teams at Slack HubSpot, other places, started building out these writer teams to get all of the brand and tone and voice and button text and everything right. That's correct in that that is a real discipline. However, I think that is a major part of the product designer's job going forward. Because, you know, 10 years ago it was asking the designer in Sketch, probably back in the day, or Photoshop or whatever to design a date picker. No one's going to design a date picker right now. Right. You're going to use a component library, have a design system that's a solved problem, or like, you shouldn't be Doing. Doing software if. If you're not doing that. And so it frees up a lot of career bandwidth for designers. And I think they're going to need to adapt, so I think they're going to need to get really good at content. You know, micro copy flows, you know, moving over time. That's a weak spot for design, I think, traditionally is kind of throughout time. And this is. The consumer folks are really good at this. So I think they're gonna have to get really good at interaction design as well. In terms of coding, I don't know. I mean, I don't know if anybody's gonna have to code.

Outside of the world of AI. What is the most extraordinary product you have ever encountered?

Okay, the most extraordinary product, honestly, is the AGA stove.

Really? Tell us more.

I mean, look, it may be a good example because it's, like, completely functionless. It is just a hunk of cast iron with a pilot light that keeps it hot. That's it. There are no moving parts at all in it. But what it does, the benefit to the user is create a sense of hearth in the home. And it has little features to it where if you have wet snow boots from, you know, your kids playing in puddles or whatever, it's meant for you to put those on the top of the stove. There's a place for that. It heats the home. You know, this idea that everybody kind of grab. However you lay your house out, everybody gravitates toward the kitchen. Well, the Aga is always on. It's hot, you know, and it's immediately accessible. It has four ovens that are always on. And so you think about things differently. And you cook oatmeal over 24 hours, and you cook a chicken over 16 hours, and you make a sandwich and then you melt the cheese on it for a guest. You know, it's really kind of fun and cool. It's extremely safe for kids. So my kids are actually killer cooks and can make themselves, you know, whole meals. They cook meals for their grandparents and stuff at 10, 11 years old.

So.

And I like the example because there's nothing to it.

Yeah, yeah. Very cool. All right, last question. It's a Mount Rushmore question, and you can take it in one of two ways. Number one, who is on your Mount Rushmore of Product People, or number two, who is on your Mount RushMore of Founders?

It's a tough one because you have to walk the line of sycophancy, you know, And I think for me, the answer is going to be the same. You know, the founders that are on any kind of Mount Rushmore. I'm not really in any place to make a Mount Rushmore at this point at all. But certainly Steve Jobs.

Yep.

He's complicated. I have an opportunity through a mutual friend of ours to be learning more about him and kind of how he interacted and what the experience was like for those around him. It's not a leadership style I really want to emulate, but, you know, the results, pretty impressive. And the engagement, I think, is really impressive. The trust of knowing what's best for the user. It's a little over my line. I still need to talk to people to figure out whether they like something or not, but Steve Jobs is up there. I. I'd put Paul English up there for similar reasons. I would, I would, because I think Paul. Boston guy, cool. You know, Paul left a long shadow. I'm not friends with Paul or anything. I've met him, I've hung out with him. He probably has no idea who I am, but he will after he listens to. Yeah, well, I hope so. Hey, Paul, I hear you're a great, great dude. The one time we hung out, you said some really brilliant stuff.

The.

The recruiting and the customer focus. Yeah, I think that left a really long shadow. I hope he knows that. You know, the story of the really loud, annoying phone in the middle of. Of the room, I mean, our culture is some version of that. It's really just the extension, you know, down from. From that and the diaspora of that kind of value system. So there's that. And then also what. The way he recruited and the way he talks about recruiting, I think is really understudied. You know, the idea that if you have the candidate, you have the right person, that's your only job, and you need to be in person with them with an offer letter within hours, you know, not weeks. And I think that's another advantage that we can have culturally over larger companies is moving very quickly with amazing people. So he's up there. And then I'll throw in Rick Rubin. I mean, he's probably founder of. He probably has some production company or something. I don't know. But he's a really interesting guy because he's a Steve Jobs with a completely different vibe and a completely different level of humility, which is, I think, is interesting. So Rick Rubin has produced, you know, probably half the records we grew up liking and listening to. And, you know, and he's in the studio to the question about designers knowing how to code. I mean, this is the Greatest music producer maybe of all time, has no idea what any of the knobs or dials do, doesn't know a single chord on the piano, and trusts himself and his taste completely and totally. There are no focus groups or anything like that. So I'd put him up there. I'd put those three guys up there.

We got room for one more?

Sarah Blakely.

Really?

Yeah. Okay, 100%. I was just telling my daughter about this because my 10 year old daughter, she was dropping some science on me, man. She was saying, what if we took maps in that Claude thing you were showing me? And, you know, and she starts riffing on it. I almost texted you. So I was like, you should get in on this one early. But I was telling her about Sarah Blakely and the idea. I mean, very humble, very approachable, really inbound kind of leader with a really positive message. But she just did it, man. She just did it. And she had a belief, you know, women's undergarments should not be designed by men who knew nothing about it. Like that is.

Okay, great.

You are a billionaire, you know, and she's done a lot of good with it. So I'd put her up there as well. That's right. There are four on the mountain, Right? She's up there, too.

Awesome. Christopher, thank you for coming on the show.

All right, thanks for having me. Good to see you. Sa.