Humans will tolerate any amount of chronic pain to avoid any type of self afflicted acute pain. The way that translates into business is that people would rather be wrong slowly than be right and have to make a painful U turn.

That's Des Traynor. He co founded intercom back in 2011 and grew it to one of the biggest customer communication platforms in the world with over 300 million in revenue. But in late 2022 growth was slowing down dangerously. This is when Intercom made one of the boldest pivots, betting the entire company on an AI agent called Fine. Today, less than three years after launch, Fin is approaching 100 million in revenue and resolves over a million customer conversations every week.

For us it was painful. Like Ohnn challenged me to go and set up a team Fin, rob a load of engineers, isolate them from the rest of the org, make a whole Fin product, get a different sales team to sell Fin standalone. Every single one of those changes is painful and you're pissing somebody off and you're taking somebody away from their favorite manager and you're changing forecasts. But that's the kind of cost of entry.

From this episode, you can expect to learn the exact steps to turn your company into an AI first business and why you need to stop building software like a factory and start building like

a lab to run a company that can withstand changes. Like there's basically three parts true AI. There's false certainty where you make a prediction and you hope it's true. There's existential dread where we all show up for work every day and ask what does it all mean?

And then I think actually one of the things I want to start with is your PhD, but specifically what you did and why you decided to stop. Because in the history of Intercom, when I was doing the research, you guys took a lot of unconventional turns. It's not a really linear path at all. So I want to kind of get into your thinking about how you made those decisions. Tell me about your PhD research and why you decided to stop.

So I was a good student in university and like the dot com boom hadn't really hit Ireland as strong. You know, obviously I graduated in 03, so the crash had happened. But like the idea of like going straight into a startup or whatever wasn't on the table. Right. So what did the smartest kids do? They all went and did PhDs. At the time there was a lot of like funding or scholarships available, so I was like kind of looking to do something and it is a bit of like audience Capture. It's like, what do we. If I want to be a smart kid, I better do the things smart kids do, you know. Right. So at the time I was pursuing a PhD and what usually when you graduate there's like, you know, know all the professors and lecturers would have like, here's the research areas and here's the funding we have. What do you want to research? And computer science education came up and I was definitely like bemused at in my own class. Like I think. And you know, my research found this to be true University, the bottom say 60% of the class can't really code, right? Like they can't really do the job. And at the time I probably have better fresher thinking on this today. But at the time I remember thinking, wow, like how is it like that we've been here four years and like there's people who can't like, you know, I don't mean they can't literally go, they could do hello world, but they certainly couldn't like solve a real problem in any real way. Right? You know, like write something to a file or whatever, right. And like, and it was a substantial joke, maybe it wasn't quite 60, but it was like too many. And I remember thinking, geez, well what is medicine like? You know, what is law like? I mean can you, can you imagine producing like, you know, the majority of the people who graduated out of the medical degrees can't actually do anything. You know, it kind of just seemed so foreign to me. So I was just kind of fascinated by that. Like why is it we are seemingly tolerant of this and maybe it was just Dr. University, but it really wasn't. So my research was into like, why is it we are so bad at educating or teaching people how to program, write code specifically. And at the time the thinking was oh, it's too much like maths and we should have maths as a mandatory requirement. And there was a few other kind of path theories that I was exploring. But ultimately where I zoned in was actually it's the feedback mechanism which is how you assess if somebody can program is what was broken. And I kind of zoned in very sort of specifically on can we automate a way to get students real time feedback basically as to whether or not they're actually getting the concept. This is obviously needless to say 22 years ago. It was before AI, right. It's only really funny fact. It's only really over the last three years I've realized all my work is new, totally out of date For a good. Hung in for a good.

It wasn't for a while.

Yeah, yeah, exactly. Maybe hung in for a good like 15 years. But. So what I were focused on was automated assessment, which is basically, it was as simple as this. There's a thing called Bloom's taxonomy of educational objectives which basically says the order in which you understand things at the very, very basic level is something like recall, like, you know, can you recite numbers or whatever? That type of thing at the very, very top is synthesis, which is like, can you create new objects from existing stuff? In the middle you've got comprehension and analysis and other bits and pieces. What I realized was all of our assessment techniques in computer science, not just in my university. When you put in Trinity and UCD and a lot of places, they basically said write some code to do something. And then they had this kind of template based marking where you'd say like +3 if your brackets lined up, plus 2 if you named your variable as well, plus 3 if you had a for loop declaration. So you could actually pass the exam without the program working, if it looked like it worked. That's ridiculous. Yeah, it is, right? Like, so when I produced this like this automated way of assessing the same thing, it would just generate a very small piece of code with like very easy to do maths. It would like maybe create one or two variables, add them together or multiply them and then output a result. And it would ask you, and there might be like an if else block or something. And it would ask you, hey, when all this code's finished running, what does it say? And it could do that. You could do like 100 of those in a row, right? And if you understood code, it would take you all like 7 seconds to answer it correctly or something like that. Maybe 10 seconds, right? Pen and paper if you really needed it. What we found was this really weird. All the best students, according to the university, people who scored 100%, the top 10, say students would score perfect, often higher marks on my test because my test was slightly easier for a great student. And then all the worst of the worst of the worst, the people who didn't bother trying, I think would also. So you had this kind of bimodal agreement with this weird hollow in the middle ground where my testing had basically no middle ground, right? You either can or can't cover, like there's no way, you know, you know, you know how to add 6 and 7 but not 6 and 8, you know what I mean? Like, so as a result, anyone who could parse the code was kind of getting my results right are like, you can do it or you can't. Yeah. And there was a large group of people who I was failing. They were actually getting 40, 50, 60% because they had the optical aesthetics of what looked like an answer, if you know what I mean. But it didn't work. Yeah. And anyway, so that was, you know, and we published a couple of papers, a couple of journals, a couple of conferences, et cetera. I ultimately kind of got disillusioned for two things. One is, like, the results were really unpopular, like, in that, like, no one wants to sort of show me the incentives to be clear. Like, it wasn't like people were blocking it, but like, it was like, yeesh, you know, like the people, you know, you need universities to agree to do this. And they weren't all super enthused. Like, it got to like, write up point. And I was like, oh, I don't think I probably hadn't cracked enough material to do a proper write up. Uh, I started writing up a thesis and then I just got kind of, you know, drawn to the web 2.0 world. You know, this is the era of like, Flickr, delicious Google Maps, like all this new, you know, Ajax, JavaScript technology in the browser. Microsoft releasing 5.5, which made all that popular. There was just this kind of like, convergence of important technologies that meant that web software, that all software was getting rebuilt in the web, Right. All of a sudden, because you weren't using like the Windows UI toolkits, you could do things like UI design, you could decide that all the buttons didn't have to be gray, you know, and then all of a sudden, usability became an issue because people were like, designing in all sorts of different areas. You remember the early days of like, CD ROMs and shit like that, where, like, people pop in and like the, you know, the design of the early websites was ridiculous. Creative, but ridiculous. But I think what we saw was like, you know, the usability industry kind of got a second burst around web. 2 because you could do anything, people were doing anything, and a lot of anything isn't useful. And that was really interesting to me. And that's. So I started writing and thinking and talking and blogging about that. And that was what led me kind of to walk out of the university one day and never come back.

It's just because the opportunity was so much more interesting to work on this new technology.

I found it way more stimulating. Yeah, yeah, okay.

Interesting. And you make that decision, you're not instantly jumping into A new job or you know, you're still blogging. How does that transition look like?

I'd started blogging and I got pinged by at the time like a popular consultancy in Ireland who was known for being good at what they do or whatever. And I replied to a few emails, they asked me to do it, they said, hey, can we get you to do a little bit of analysis on a site we're building? So I gave my talk, my take on it and then they kind of offered me a job and I was like, oh no, I've got this PhD thing to do. Then they said how about one day a week? And I was like, okay, I'll try that. And then before, you know, like one day it's just. Yeah, it was clearly more. It was like as if I had one day a week of extremely interesting work and then four days a week of grinding in latex trying to write out like various different bits of code. So anyway that was like. And then I went from the consultancy somewhere like about maybe just under a year later own, who's the CEO of Intercom mailed me to say he was starting a consultancy and what I wanted to start it with him. That was called Contrast. So we did that Contrast. We obviously had a very popular design blog. We did a lot of work for clients, we built a lot of side projects but ultimately the whole thing became Intercom on a long enough timeframe. Yeah.

Can you tell me about the start of Intercom and the Ruby on Rails project you guys had? Because it's a non obvious. It sounds so obvious now that you should be able to talk to your customers really easily but back then it was really difficult and you guys found this out the hard way. Can you tell me about that origin story? And then sort of we can pull through line through the rest of the conversation to today because I think there's lots of new changes happening as well.

So we, you know, our heroes at the time were 37 signals, still are. Their whole thing was consult until you can make enough money to free get yourself free time and decide you spend that time on the side building a product that you charge for in a recurring revenue style. SaaS was really just taken off and with that recurring revenue you free yourself from the shackles of consultancy and lo and behold you've become a software company. So that seemed like the plan and we had like we. Our strongest. Our most revenue generating product was an exception tracker primarily for Ruby on Rails and later on we added PHP editors to it. But it was basically like a Way to say find exceptions in live web software. Again, all these problems were new because of the web, right? But web software would throw exceptions. So we had to just catch those exceptions and like alert the developers or send them a text or whatever it might be. So that was exceptional and we built that. One of the challenges we have Exceptional was like, you know, own as CEO or whatever or like, you know, he was like the leader of Contrast and also CEO of Contrast. But also, you know, if Exceptional was a side company, he would have been CEO. I was probably like the next most like whatever the word might be, like senior in terms of what I was doing certainly with the clients. In Contrast, neither of us are like engineers by trade. We both studied computer science, but neither of us will be like passionate about this product domain. It was actually one of the other guys who kind of identified the opportunity. So as a result, like you kind of have to. You feel this. You can't do self design because you know, on the Google, what I really liked. So you end up kind of spending leaning on your customers a lot more, which means you want to talk to your customers, which means you want to send them messages. And that's where you kind of. And people often forget this. But you have to cast your mind back. The year was 2010. If I ask people how do they talk to their customers today, they'll say things like intercom. If you ask them how do you charge your customers, they'll say striped, you know, and how do you measure which customers do what? They'll say posthog. Right? None of that existed back then. There was no Mixpanel. There was like barely Google Analytics at the time. There was no like. So the actual technique you'd use to message your customers would be you would go to PayPal because that was the only way you could charge a recurring subscription, which by the way, PayPal invented not for software, but actually for magazines. So you're. So you go to PayPal, get an export of all your payers and you go to your CTO and you'd say, can you be an exporter and who's using the product? You sync up the two lists to find who's using and paying the prop for the product. You import all of that into mailchimp or Campaign Monitor or something like that, which is the only newsletter tools at the time. And you send them out an email and no one replies. And that was the state of play as it relates to like understanding what your customers want. Right? There's just no easy way to talk to them. One of the problem challenges we had with Exceptional was it was like, it was a difficult product to scale.

This episode is brought to you by Beehive, the publishing platform built for modern newsletter businesses. If you want to start, grow or monetize a newsletter, Beehive gives you everything in one place. Powerful writing tools, deep analytics, a referral program, and built in ad network and sponsorship opportunities. I've actually had Tyler on the podcast, the founder of Beehive. And when you look at how he thinks about building a company, it's very clear why some of the fastest growing media companies and creators are turning to Beehive to run their newsletters and run their businesses. So if you've ever thought about starting a newsletter, want to take yours seriously, Check out Beehive below. You can also go to mine in

the description because it was, you know, basically it was deployed in like big popular web products that would ping it like hundreds of thousands of times. So it would fall over quite a bit. And you'd like to either give people notification about committee downtime or apologize for previous downtime. And to do that you need to be able to message your customers. And then we just had that problem messaging your customers. So I think the logo for Exceptional was this little star that sat in the bottom right hand corner of the screen. And one day, I think it was Owen's original designer, a little bubble popped out of it saying, okay, I think their first message was like gigging up a blog post saying, hey, we've managed to like, you know, add a lot more servers behind this, so it should be more reliable. And all of a sudden people started engaging and I think Owen said to Kieran something at the time, like, wouldn't it be funny if this little widget thing becomes bigger than the actual thing it's sitting in? But that bubble went from being just a bubble to a bubble that would pop up and be a window, a window with a reply box. You could have a thread, you could go back and forth. And then all of a sudden it was like, well, what if we started the conversation? What if we could dynamically start the conversation, Maybe just message people on their first time logging in or their fifth time logging in. What if users could start a conversation on their side? What if they could change design in the bubble like blah, blah. And then you can sort of see how that, how that grows up to being. At the time we were calling it, User talk went on to become intercom.

I think it's interesting that you're kind of forced to talk to the customers Like a find a way to talk to them because you weren't your own customer initially.

Yeah.

Do you maybe jumping forward a little bit here, as you scaled up that product, what changed? Because I know it got a lot more complex over the years as you guys grew you.

Powerful is the word we prefer.

But yeah, powerfully complex. And you know, you guys grew you one of the fastest growing companies at the time, I think. How do you make sure. Or retrospectively or retroactively what. What went wrong in that process as the company got bigger and the product just started touching all these different surface areas? Because I can imagine it's very appealing to just keep expanding what the product can do. But that sounds also like it was a little bit dangerous because you guys were in sales marketing support.

Eventually the problem domain as it relates to startups of like, hey, wouldn't you like to know and talk to your users? Is it kind of a home run? Right. If you talk to any startup founder like, hey, what tool do you want to use to see who your users are, let you talk to them, have conversations, see what activities they're taking about, et cetera. The. Everyone's like, yeah, we want that. As a business grows, like as in as our customer base started to mature, what happens is they have different types of people who want to do different types of things. Right. And this led to early stage customers. And we still have an early stage plan for this exact reason. Intercom is a perfect sort of Swiss army knife type product. It works, does everything you want to do, but as you grow it becomes something more of a one size fits none. Or it became we've changed our product line and we've stopped some of these offerings. But what would happen is if you really wanted, like if you hire some senior marketing guru who you took DocuSign into Market Way back when they come in and they say, oh, I want Marketo. And you're like, oh no. Well, we use Intercom Intercom. It's certainly an nicer easier to use tool. But you're like, no, no, no. Marketo's got multimodal attribution reports and that's what I need. So you're like, oh Christ, I guess we better go and build multimodal attribution reports. That's the first. That type of decision is the first time where you're back building something that you don't fully understand yourself.

Because a customer says we need this because another competitor has.

Because you're no longer your customer for that particular feature. Basically your intuition is weak now, whereas it was very strong when you were a startup founder designing a tool for startup founders who wanted to see I need this. Yeah, you're like, kind of, well, when someone says to you, do, you know, it'd be cool if we could see the last 10 things the user did? You're like, yep, that makes sense. And everybody would just like, was like jigsaw pieces just fitting in. You're like, that all makes sense. Once you start moving. And it's usually when you start moving upmarket, what happens is you often aren't your exact target customer anymore. And we were basically effectively like, Intercom was a tool for seeing and talking to your users. There's so many ways that goes as you move up market. Well, you're saying talking is it sales talk, is it success talk, is it marketing talk, is it, you know, is it support talk? And you're saying, see your users? Is that like, are you doing visitor analytics? Are you doing segments? The answer is if you want to take that whole thing up market, you have to kind of do all of those things. And you have to do them from a position of deep understanding of what you're doing, augmented heavily by customer contact or whatever. And it means you end up building it. You have to solve a lot of essential complexity in each of these domains. Now, the one challenge I think that does hurt startups as they do this in general is when you talk to the VP of marketing at one of your customers who took DocuSign to market. I'm just picking that because it means you're a certain tenure of person. They're going to feature request all of the incumbent features, and if you actually follow their demands, you'll end up building the incumbent tool. And that kind of is ignoring why you were disruptive in the first place. Because if the incumbent tool is good at this, surely you would never have existed. Right? Right. So, like, there's a way in which, like, you know that, that quote from Harvey in the Dark Knight Rises where he says, like, you either die a hero or grow old enough to see yourself. Yeah. There's a risk. There's a product strategy version of that which is like, you have to work out, like, you know, where does your ICP stop? Where do you say, okay, if you're that big and that mature, with that much of a dated understanding of what's important. Right. You should go and use Marketo. Right. And that's a difficult decision to make because it sounds a lot like we're not going to build up, we're going to say no to this massive market of like upmarket or whatever. But I think like the general narrative you get from like specifically from venture capitalists where they haven't actually sat in companies is like, it's time to go up market guys. And I think what, while like what a lot of folks don't get is like the up market product strategy is extremely different to building for startups. Right. And I think like you know, everyone from like you know, YC to launch to all the incubators and all that, they're really good at teaching you how to build a great product for startups. And I think the knack is you should really, you know, there's a certain point at which you should go up market. Right. And you shouldn't go further up market than you are, et cetera. The great companies nailed this really well. Like as in stripe is still the default choice for a two person company tomorrow and they have airlines using it as well. And like it's like you can stretch the spectrum but you have to be really careful about how you do it.

Is that the framework there to knowing when you're ready to that when your company's at that size like you just said, or what sort of.

It's a combination of like, you know, you have to, it's not an obligation. You can't be a small company serving big companies. Like there are numerous of them. Right. You know, but it's really, it's, it's got to do your depth of understanding of what it is you're trying to solve and you need to not be like a child wandering into a wilderness being like, oh, I guess I'll just look to all the trees and build it and say you actually have to have experience. So when you look at it working well, usually what it is is somebody left a big mega org with a really clear idea of what it is they need and then they go and build the thing and sell it back to that big megawarg. But they left with a kind of like a proper p ord in their head of what they were going to do. Right, right. They already have that expert.

The fog of war isn't there.

Exactly. You don't need to talk to a phenomenal amount of customers and be able to pick through it and work it out. General, there are like, I'm not aware of many companies that have succeeded by tackling a problem domain they knew literally nothing about. Like without putting in the work, if you know what I mean. Like by putting in the work, I mean like you know, self design, finding early customers, blah blah, you have to do that. And it's just, it's, it's, it's extra hard then if you try to sell to megacorp from the start, if you, if you weren't previously one of the gang because you just, they're not going like, why would I go talk to you? Yeah. You two lads going to build my time tracking app? Go away. You know, it'll be that sort of thing. Right.

You've grown this huge, really successful business and I think this is going to be interesting as well to hear your thoughts and frameworks on. Given this powerful product that's selling to all of these different types of customers, how do you then go about really making a pivot? Because I know when Owen came back and it'd be helpful maybe if you gave some context for the listeners. When he came back, you guys already wanted to pivot or at least sort of restructure the company in some way, shape or form just before AI came.

Yeah.

What sort of was the think thought process behind that? And then how did AI sort of supercharge that?

Yeah, I mean, so I was head of the company for like two years as CEO. He remained on as executive chair. But there was a difficult period in technology in general which most of the listeners will remember, which was like the kind of post Covid sugar rush where and we like, you know, there's a lot of like, we were lucky in a lot of ways despite all the pain. I'm about to tell you because I know a lot of companies who struggled harder. What happened in Covid was like all the money was looking to go somewhere. It was looking for growth and it ran to the stock markets which meant software kind of just massively inflated. And then that trickled all the way down to startups being overvalued and all sorts of stuff. On top of that there was the era of web tree and NFTs and a lot of these, I would argue a justifiable problem domains, but perhaps prematurely inflated relative to their impact at the time. And what that looked like was tech went boom. Right. It was the boom times of tech and that led to like revenue growth and all sorts of like, you know, just, you know, normal stuff. Like when tech gets big, all of a sudden all the businesses, you know, will start signing more contracts, more seats, more employees, more hiring. Just every core green light on the dashboard is like blinking, saying things are young, right. And, and then one day, November 2021 maybe, it was like the year's blur at this stage. There was a Particular November where, like, it all went bang and I don't even know. I don't. Like, I haven't spent enough time digging into exactly what the trigger was when people realizing that this didn't make sense. There were certainly signs, you know, like there were like, you know, companies where the first round was a secondary and all sorts of shit. Like, yeah, yeah, it's just genuine, you know, like. Like there was a lot of obvious signs in hindsight, you know, clubhouse went from like nothing to being right in back to being like closer to nothing or whatever in the space of whatever, eight months or something like that, you know, there was a lot of that going on. The challenge we had was like we had basically blown up. And then a lot of our customers started to, like, either die fold certainly cut back on seed count. That led to, like, declining revenue growth rate. Revenue itself wasn't going down, but the growth of our revenue was coming down. It was basically approaching a standstill. And Alan returned and we were like, right, this is like the tough times attack because now tech's in a crash. It was the best time to put money into tech, as it turns out. If you ever S and P or whatever.

Why was that decision made? Why not sales or marketing?

It was the healthiest, stickiest, most vital. Revenue is the best way to put it. Okay? The sales product, like the website, live chat to talk to leads and basically book a meeting or whatever was like. It was like a popular product, but it wasn't. It was like Churnier probably had less pricing power in the long term. Okay? And then the engaged side of the house is still kind of pretty popular. I think we still have quite a good bit of differentiation, quite a good bit of revenue there. And we still, you know, we still work on that and we maintain it, but support was clearly where we are strongest. And then other bits of backdrop, like Zendesk had been kind of taken out by private equity and there was clearly just. The Runway had kind of cleared for us. I was kind of like, look, there's a big opportunity here called being brilliant at customer service. We should go and do that. Right? And that was Owen's decision. So then we went all in on that. And then, like, I honestly think it was like seven or eight weeks later, like, we got all the pings going to ChatGPT. Start playing with that. I think the first. After some initial playing, the first hard question I asked was like, how would you install the intercom SDK on a mobile app? And it gave me a perfect answer in seven seconds. And that was the kind of, the big kind of row moment where I was like, that's better than any human could do Master 2 as well. Yeah, it was perfect. It was also seven seconds, and I believe our support team would have had a macro for that. So he might have got it in 15 minutes, but you weren't going to get in seven seconds. And turns out when you're trying to convert customers, seven seconds actually matters. You know, like, one of the things people don't realize about support, which we can get onto later, is like, speed of response is really, really healthy for business. But anyway, so it was very clear that AI was going to do some amount of customer service. And if we were to truly be like the next. At the time, I was like, you know, who's going to take over from Zendesk? Well, clearly they're very good at this AI stuff. Right? So that was the decision then to say, right, well, let's see what we can build. Four weeks later, we had like, AI features in our inbox. We had things like summarize, change the tone, change the language, that type of stuff. And it was pretty cool. And we had this super viral tweet, like a million views and all that. People were like, oh, my God, this is exactly how you build AI into software. And then maybe March 2023, we launched

Fin, which explain maybe what Fin is. And then I really want to go deep on the early days of Fin and how that's changed your thought process behind how the future of pricing is, how companies should be structured. Because I think there's. I think there's so many interesting insights, especially because you already were running this huge company that made this pivot. So, yeah, you guys are one of the first, maybe, maybe the first big company to actually launch AI features.

I believe we were. Or at least, I don't know, maybe. I don't know. When Microsoft launched Copilot, the first sort of tablet community, I don't remember, but I think we were certainly celebrated like, as if we were the first. And then when we launched, so there was basically like, there's a kind of framework that, you know, with the benefit of hindsight, I've learned, which is like, you can either augment humans, you can use AI to augment humans doing the thing they're currently doing. You can do a bit of their job, or you can do all of the job. So you're either making them a bit faster at the job, taking away a percentage of the job, or just doing the full job. And generally speaking, you know, daymap from like, what's easy to do is to augment and what's very hard to do is do the full job. The inbox features was very augmentation like, it was like, hey, we'll put all this stuff here. If people use it, great. And they do. And it was really nice. And then later on it was like, well, can we do some of the job? And then can we actually do the job of full support app, right? So Fin is our AI agent that does customer service. And we launched FIN in March 2023. At the time when we launched it, it did like 25, 24% maybe total resolutions, which basically means, you know, it given, given a bucket of support conversations, 24% of them would be handled entirely end to end by the agent. The rest would be escalated to a human. And at the time that was enough for us to believe this will change the nature of customer service framework because if there was a tool that takes away 24% of anyone's job, it's going to become a manager tool pretty quickly, right? That sort of 24% assumption underpinned how we saw the landscape playing out at the time, which was that everyone who has a platform is going to need this. This is a great reason to switch to the Intercom platform. And I think that with the benefit of hindsight, we would have played that differently. But so we went all in on Fin and we built it out and then we built out a copilot and then we went harder and harder on fin, at least fin2, fin3. Today, fin processes way over, resolves way over a million conversations every week and it's like, you know, revenue growth is astounding. Sort of super popular product, 7,000 customers, you know, on growing and all core metrics are looking great.

You know, it's insane. It sounds so easy and obvious in retrospect. But why? I mean, even such a small or seemingly small decision as like calling it Fin, rebranding it and not saying, you know, this is Intercom building, just like, you know, sort of making that distinction. What were the key decisions there? Because you mentioned you might have done it a little bit differently.

When I say we should have done it differently, I think with the benefit of hindsight, I think with the information we had and the strategy we had at the time, I think we did, you know, I justified the decisions, if you know what I mean. As the market played out, I think we should have gone harder earlier and we should have. So Fin today is sold separately to Intercom. You can use Fin with Salesforce, you can use fin with Zendesk, ServiceNet, whatever, whatever your tool of choice is, you can use Fin. And it's a Fin AI. It's not like, you know, you know, there's another path where, like this, what I would call the safe path, which is where Most of the SaaS companies trying to survive AI fail is we could have called it the Intercom AI Agent for Customer service and it would be. Most people would have. Yeah, absolutely. And it would have been@intercom.com AI that would have been like, you know, on all of our narrative would have been around that. And I think like that's easier and safer and risky. It's basically because it feels short term safer. It's almost always long term riskier. What we had to do, and with the benefit of hindsight, we got there, but like we had to make Fin clearly an AI company that can clearly compete with all your AI companies. Fin's siblings or neighbors or whatever needs to be like cursor and perplexity and like, you know, like Harvey and Lagora AI first AI native entirely disruptive sort of startups. Yeah, that's what Fin is and that's what Fin needed to be for us to, for it to have the right amount of credibility. I think like if you call it like the Intercom AI agent or like and this is what all our competitors are doing. It's like the Steve Buscemi with the skateboard gif. You know, it's like, how do you do fellow bros? You know, like, like you're basically the old guy trying to look young and like serious. Yeah. And whereas Fin is a purely AI, you know, true and true, like extremely hardcore AI product. We publish a lot of research, we train our own models. Like, you know, we, we do a lot of work that is like very consistent with that of an AI lab. Yeah, yeah.

I mean, I think that's obvious when you look at the resolution rate, like you guys publish this beautiful chart as well. Just actually real time to show the changes, I think. I don't know if you said this, if you're eating, you don't nibble again. This sounds so obvious, but were there any discussions at the time internally or doubts you had that like maybe we should pull this into Intercom or you know, to your point, there's a reason people go for that sort of safe route. It's very human. I'm curious if there were any doubts at all or was it just so obvious with the use cases you were seeing in the product and the Adoption rates and how strong it was, I

think we grew, we got progressively more confident. Well, I think we took risks early on and as they paid off we just took more. I think another sort of mistake pattern here is you make one risky move and then that works out and then you say, right, that's it, risks done for me. Safe seas from here onwards. In practice it means the reason you felt it was a risk was because you had or somebody had some counter narrative. And the fact that the risk succeeded proved that narrative wrong. So you should probably turn the volume down on that narrative and keep acting out as if you're right and that's how you grow conviction. So we didn't start off with Fin AI, we got there. We didn't start off with fin for Standesk and fin for Salesforce, but we got there and even some of the moves were making. Now the Fin as the customer agent is just another example of us continuing to bet on the conviction that AI agents are the future. There will be one true customer facing agent and it will do the sales conversations, the success conversations, the marketing conversations, the support conversations, and that's the thread we're pulling now. But I think just to reiterate for your sake, your listeners, the biggest mistake here is almost always you're being too careful. And if you're reading shit, don't nibble comment. It's just like drip feeding pain is a bad way to like, you know, I think I was on, on the Cheeky Pine podcast, Mark Andreessen had this great quote where he said humans will tolerate any amount of chronic pain to avoid any type of self afflicted, self afflicted acute pain. Right? And I think the way that translates into business is that people would rather be wrong slowly than be right and have to make a painful U turn, change or shift or whatever. For us it was painful. Like Ohm challenged me to go and he told me basically go set up a team, finish rob a load of engineers, isolate them from the rest of the org, make a whole Fin product, get a different sales team to sell fin standalone, et cetera, et cetera. Every single one of those changes, they sound minor now in the gravitas of what we're sorry in the greater background of everything we had to do. But every single one of those changes is kind of painful and you're pissing somebody off and you're taking somebody away from their favorite manager and you're changing forecasts, you're doing all sorts of painful short term stuff. But that's the kind of Cost of entry. You know, the alternative is, is a really peaceful, long, slow debt, you know, like. And I just think you have to realize that you need to make big hard decisions.

Yeah, I think to add context, that too, I think you guys even gave back or you know, missed out on 50 million plus of revenue when you made that switch. When you changed the pricing models changed in usage pricing.

Yeah.

So restructure the company.

We did do that. That was separate to the fin piece and what that was was like when I own return. One of the. He had a kind of a. What's the word? Like an agenda and an action plan. One of them was like, you know, kind of restore customer trust by like by fixing our pricing. Our pricing had gotten extremely complex because we just added so many different types of products and add ons and we were selling like, you know, at so many different points in the market. A lot of it had gone to like contact sales only. And it's just if you look like there was a period where like it was genuinely like, like none of us were proud of what we were doing in terms of monetization. But it just, it always felt like you pay this cost of every incremental decisions. Surely that one's not that bad. But when you put 10 of them in a row, it just gets really messy. You can actually see there's a lot of AI companies repeating this at the moment. So one of the decisions he made was basically move everyone onto a single price plan, make that price plan fair and competitive in the market. Doing so means losing a lot of future revenue and a lot of current revenue. And the tune of that was like as you said it was in the order of 50 million or so. But like it's the sort of decision you have to make if you're serious about building a super successful company for the long term.

The Biography podcast is presented by ro, the all in one banking platform for startups. Thousands of startups like Perplexity, Product Hunt and more use ro. You get everything you need to manage your startup's cash. Fast banking setup cards with up to 2% cash back and yield that turns company cash into extra Runway. All super important in the early days of launching. But the thing founders really love about RO is their team. They are obsessed with helping founders disrupt the status quo and will go to the end of the earth to help them to do so. And exclusively for Biography podcast listeners and viewers. You'll get a fifteen hundred dollar statement credit plus a ton of exclusive perks when you manage your company's cash with ro. To learn more, visit RHO Co Biography. Terms and conditions apply. RO is a fintech, not a bank. Checking and card services are provided by Webster bank member fdic. See Rewards terms for details.

It's like it's, again, it's the long term gain you're prioritizing for here, not just a short term, the quarter. And again, were we public or whatever? These decisions are almost off the table entirely. Like no one's going to vote for that, you know what I mean? Or no one's going to be supportive of it. But I think they're the necessary parts of restructuring the business.

How have you thought about that in the age of AI, where you do make these changes? I feel like it's probably much harder now to make those long term bets. Maybe not. What sort of frameworks do you guys have now internally on trying to avoid making those same short term decisions? Avoiding pain instead of.

It's hard with AI because there's so much uncertainty. I think the best thing I can say, and we see this a lot even from our own customers, is you have to think about decisions in a few different ways. One is what time horizon are you truly optimizing for? Are you trying to be in good condition by the end of the year? You know, a lot of these AI companies, maybe they're trying to sell in the next year, in which case, yeah, they shouldn't, they shouldn't like, you know, go and open another office or do anything that makes them less attractive. There's also a case of like, how reversible is the decision? Like, how much does it tie you up over the next two or three or four years, right? How quickly can you like hot swap and like undo and all that? The reversibility of decision is a huge piece here. And then there's also like, what does your experience tell you about how things are going to play out? And it's just been funny to watch, you know, as we speak now, I always have to do this because AI, I have to timestamp this end. So we are sitting here at the end of January 2026, right? And right now it's very clear to everyone, very clear that Claude Code has won the coding agent war. Right? Less than six months ago, cursor was valued at 31 billion because they was very clear that they had won the coding agent war. Previous to that, cognition was valued at 11 billion because Devon had won the coding war. Before that it was perhaps OpenAI or something like that. And before that there was a windsurf and that Whole thing. There's another one called Augment. And if you just. You've seen the lead change hands quite a bit in this period and I suspect it will again. Like, they're all. They're not blind to each other. So everyone's seeing what Claude's doing. So I suspect there'll be people going after that next. There'll be someone doing, I don't know, a Claude native IDE or something like that, or at least certainly a multi agent native IDE with perhaps like collaborative AI engineering or void coding or whatever. I can imagine loads of different directions this will go and whoever nails that will probably overtake Claude code again. And we haven't even seen what it looks like if these companies decide to close access or not give their competitors the best models. There's so many different things to play out here and I'm just picking this as an example of. So you tell me to the tune, if I gave you a million dollars, where are you putting it in terms of who's winning the coding agent war in a year's time? Like it, you know, you might still stay cod, but like, it's a much riskier proposition than it was before. I said, that's it.

Yeah.

You know what I mean? Like, so like, I just think in general, everyone's like. I often think like, you know, when you're driving, right, how fast are you willing to go? It's a function of your own visibility, how clear the road is ahead of you, how many turns you know you have to make, how many decision points you're going to come up against, how good is your engine, how good is your fog lights, all sorts of shit like that. Right. Having a strategy in this period is the same, Right. I just don't think you can see that far ahead. So we used to do things like yearly roadmapping. That's all gone. We roadmap roughly six months at a time, but we have a checkpoint halfway through. This is still. Yeah. Which means we actually give ourselves 12 weeks before we have to adapt and react because we've got like, Fin itself is doing incredibly well, but man, is it a competitive space. I've never worked in a space where we have at least 15 other AI agents for customer service, all funded up to ludicrous degrees, as in 100x revenue, 50x revenue, all sorts of nonsense at multiple speed, flying around. Everyone's digging in the same area and they're trying to find their own particular path. And sometimes you have to adapt and react to the new news. And that means what's the point in having a one year roadmap? It doesn't serve us well. We're only going to disappoint our customers if we tell them that's coming in December. Because we need to be able to change our mind. Because the world does change.

So many different variables there that you now have to take, you know, inventory of. How does that change the way you talk to customers specifically? Because I can imagine they're asking for features that you, you don't want to build anymore or you change something or you know, a competitor has a feature. How do you educate customers? Like, I think you guys do a great job of your blog posts and publishing your research, but how do you make sure that the company you guys run is sort of built steadily enough to withstand those changes?

I think to run a company that can withstand changes, you need like, there's basically three parts true AI. There's like false certainty where you make a prediction and you just hope that it's true. There's like existential dread where we all show up for work every day and ask what does it all mean? And then there's just don't need the certainty. And to a large degree it requires a culture that is extremely resilient, is not change averse at all, has learned to roll with the punches and it's just such an important trait. If your culture was one built on some type of like parental dare, Dare. Don't worry. We'll worry about all the difficult stuff. You guys just need to do your job in your little pod and we'll shield you from the external realities. I think they're the ones who struggle the most. Because in reality it has to be okay for me to turn around to an engineer out there and say, yeah, I don't know. I actually don't know. Is that better? Will this thing ever work? We don't know. And we need to not need to know. It's like, don't scratch too much at it because we're working through a very dynamic environment. And the greatest thing AI has introduced is this layer of uncertainty into everything, including the software development lifecycle. Like, when will that feature be finished? We don't know. Right? Will it ever work? We don't know. Will it be good? We don't know. And I think if your processes for building software, or your culture for that matter, is still crying out for certainty and tight deadlines and very specific things, you're going to strangle innovation at the core. And you'll do one of two things. You'll either release shit that doesn't work, which is very common because it's like, hey, we said it was going to go up by March. So it goes up by March. And you release these agents that claim to do something, but they don't do it. And that's like half of why most of the AI stuff you find online doesn't work is because it was released on time. That's one pattern. So you either release broken software because of that, or you kind of just internally combust where you have this marketing overhang. And by that I mean you've told the world we're building this feature that has all these amazing powers and it's going to work all the time. And then you just keep pushing it out and out and out. And there's a well known phone and watch manufacturer that's, that's told everyone it's got this intelligence feature coming and it's been saying it since 2024. And we're sitting here living hot to believe January 2026, and we're still not seeing it. And like, that happens. And that's what we call a marketing overhang. The temptation when your product's late is to say even fancier shit about it. But the reality is the seductive siren like nature of AI is that you and me sit down to build, let's just say a rival to, I don't know, Harvey. Tomorrow, right after three weeks, we'll feel like we've got 80% of Harvey in the bag. What we don't realize is the other 20% is the next 15 years. And that's the phrase I say. A lot of the last mile is a marathon. You just don't know how the distance between work is 95% of the time or works 99.9 or whatever your threshold is. It could be as long as getting from 0 to 95. And in fact, often just the way the models aid code creation, it's almost designed that way, if you know what I mean. Like, if I said, hey, we're going to build a project monitor tool that's got X, Y and Z, all of that stuff is kind of already in its training set. So it's like, ding. And then we say, and now we're going to make it work really well for the fashion industry. And we're like, that's all it takes. And all of a sudden now you're into two years of product discovery, you know.

Yeah, yeah. With something that you don't have any experience in.

Absolutely. Or like. Or at the very least, you don't know if you'll be able to make the code work, you know, like.

So yeah, is sort of the way to get comfortable in that discomfort or uncertainty, Is it making smaller teams more nimble? More functions across the organization work together? Like, how do you structure teams? Aside from just having people opting into that sort of mentality, how do you structure the. The teams themselves to be flexible enough?

I think you asked earlier about how do you talk to customers about this type of thing? It's actually the same answer. You give teams areas to dig in. We call them work streams. Workstream loosely has a job to be done. So Fin Voices or Work Stream, they're trying to make fin work as well over phone as it does over text. And they have done that basically. But there's extra pieces to it now as Fin gets more powerful. Every bit of power has to be reflected in the voice product too.

I recently had the chance to interview Dylan, the founder of assembly AI, and I was blown away by how thoughtful they are about building quality scalable products. I'm using Assembly AI myself, including to transcribe this podcast. Their speech to text models are just insanely accurate. Their models go way beyond transcription. I mean, you can identify speakers, highlight key moments, and extract actionable insights from every conversation you have. Now, the cool thing about it is that it's developer friendly and it's built to scale, so it's flexible. There's pay as you go pricing, and I've seen it firsthand. Assembly AI even transcribed my previous podcasts flawlessly with one click. Now, Dylan wanted my listeners to get some perks, so they've doubled the free credits, giving you $100 to try their models. It's a great way to test out the models for transcription, speaker diarization and more. So stop what you're doing and go to AssemblyAI.combiography to see this episode's podcast transcribed and to claim your free API credits.

But that's just our area and what we don't do until we have a reasonable degree of certainty. We don't go and like demand deadlines, but we meet them every week, right? And every team every week says, here's what we learned this week. So that's the first thing you do, which is like you give teams like projects and you charter them and say like, you know, to some degree there's a risk here, like, you have to have good people. And that sounds like a truism or whatever, but let me just explain what I mean. Oftentimes people think that giving teams a deadline is what forces their productivity. And this whole Parkinson's law like work expands to 50 time available and all that. But I just don't think that attitude is not super amenable to the AI era Because anything can hit its deadline if you drop quality as a report. But making it work highly reliably and highly performant. And bear in mind that customer support is like load bearing software. It's critical infrastructure to a business. If your customers can't talk to them or they can't talk to their customers, that's a P0, that's a proper five alarm fire. It's not far off a database being like, oh well, it's 94% reliable. Yeah, it's not good enough. Right. And a lot of our competitors find this out the hard way like that they wander into what they didn't realize was actually mission critical workspace. So reliability is huge. Which means you can't force people to do things just for sake hitting a deadline. So you just have to understand the domain you're in and then separately and I don't know how deep you want to go in this, but how you build software has to change as well. You have to move from like a factory where you like, you know, a classic, you know, software team in the olden days, like what are we building? We're building file upload and we're also building expense tracking. And they'd be like okay, I think that's eight weeks and expense tracking, that's probably 12 weeks. Okay, cool. That goes into design, designs come back. We like to maybe run them past users, users, a few tweaks and then it basically hits like the factory line if you like. Right. Or like what people would, I would just say derogatory call like the feature factory. Like it just gets there. We build and we ship it, we launch it and that's that. Those are very predictable, cycle end to end. Right. You can kind of measure it roughly and get like reasonable accuracy relative to AI. With AI you're not in a lab, sorry, you're not in a factory, you're in a lab. You have to start off with what is scientifically possible that is useful in our domain. So like I'll give you a question we might scratch out at the moment. Can we read product source code to determine the feature set so that we can automatically generate documentation? Right, right. Can we do that reliably such that we could make it a part of the fin ecosystem or whatever? Right. That's an experiment that somebody needs to work on.

Scientific experiment is this Possible.

And they need to have a torture. So they need to have an evaluation set. Like, is it maybe like 10, 15 different source codes and what they deem to be the right documentation? And then they need to run that experiment and make sure, like, hey, in 15 out of 15 cases, this looks like it works. So they need to get to that performer thing. And then all they can turn around and say is like, hey, we have a capability, we have a new capability and it looks like we can do this. And then we work out. Okay, given that that's now possible, how do we productize it? Now you're a bit closer to the factory. Once we've proven the capability out, you can kind of go from the lab to the factory where we sort of say, right, we want to build something around this. What might we build? You know, design it, show it to customers, et cetera, et cetera, et cetera. But if you don't give yourself enough freedom to make sure that this thing actually works at the start, which is where all the risk is, and you put it on a tight deadline, what you're going to get is, yeah, you'll hit the target. Especially if you've got a deadline driven culture, everyone's going to hit the target regardless of whether or not it's good. And it's just, I don't know, just so much stuff in AI is not tested enough, it's not evaluated enough. And that's why, like you sign up for some random app you find on Product Hunter, Twitter or whatever, and it says, oh, we're going to take your photo and whatever, like show you different hairstyles or we're going to like take your expense data and tell you the categories of the expenses. You upload one bad photo of a receipt, the thing doesn't work all of a sudden. It's errors, messages everywhere. And like, once you put something live into the wild, you're going to like, you know, you're not doing like, you know, intercom processes, like whatever, 500 million conversations a month or something like that. Like, you know, like there's a huge update. Know, like as in, when, when you're, when you're doing a lot of conversations. Edge cases aren't edge. They're like, you know, part of it. Yeah, if Fin gets something wrong one in a hundred times, that's pretty bad. You know, that's, that's a ton of conversations. Yeah, yeah, totally. And that's why we are so scientifically rigorous about finding new capabilities, new prompts, new AI architectures that will improve the resolution rate and where we have to methodically test it before we roll it out. Like a real telltale sign you're dealing with like cowboys in this era is like if GPT 5.5 or GPT 6 drops tomorrow and everyone's like, you know, putting on the new sticker now with GPT6, what that tells you is they've done zero testing, They've just switched. Yeah. And they have a culture of zero testing because they don't realize even though the models are getting better, they can degrade for your particular use case.

Yeah. So is it really then that just turning it instead of just the factory output, just more scientific constant testing throughout the process.

You're building software through empirical observation. That's the biggest difference these days. And that is wild because we're moving out of a world of determinism. And the whole kind of, the whole value proposal after was its deterministic kind of if this, then that type of behavior and literally. Yeah. And you don't have this anymore. Like, and you have to adapt to

that and you have to. And the way to do that is not through strangling innovation sort of in the crib, but giving enough time to

giving it, letting it breathe and like letting it like making sure that you actually do have a good definition of what good is. And I think there's like, that often means you have to have decent, like what we call a torture test. So like, if me and you decided to build a FIN clone tomorrow and we put it over here and we'd like FIN over here. If the only questions we ask are like, how do I reset my password? And like, where do I log in? Turns out we're just as good as FIN in the same way. I'm just going to like, you know, basic maths as Einstein, you know, like, it's, it's very, very easy to pass a very, very easy test. Yeah. And don't mistake that with progress. And don't mistake that would be market ready. Right. So when I see it like, you know, so in support terms, Right. Like the. When you see people saying we got like 25% resolution. Right. I'm like, Claude will practically do that out of the box.

You guys are years behind.

Yeah. Like, and actually getting from 55 to 60 might take you seven months. Right. You know, and that would only be true if you might take you even longer depending on the ways in which you're building. But it's like every incremental percent is harder. And because it's harder, it usually means it's doing more valuable work because it's dealing with even more complex questions.

I think it's really interesting that

the

way you're building these products is changing. Can you talk a little bit more about the evaluation process? Because it seems like that's really important.

Right?

Like, oh, okay, we're just testing. Can this do password login? Yes. Okay, we can ship this. How do you. Or how has that changed over the last couple of months, weeks, years? How do you guys think about evals and saying, okay, now it's actually ready to be put into production?

We have like, it's an expensive thing for us to work out. Is this better than the current fin? So, right, like the things you have to look at is we have like maybe a thousand what we call like scenarios or like it's both not just what the customer said, but who the customer are and what context the customer is in. Right? So like a customer saying this is broken on the billing screen is different than a customer saying this is broken on the dashboard. Right? You know, so like, there's a lot of stuff you have to collect to make it useful. Then you've got like, what is the current fin? If you're like this? Just if you picture a spreadsheet, it's not really a spreadsheet, but what's the current fin output for this? What is the best possible output? Like, as in, like, if God zone support agent to descended from heaven and wrote down the little perfect answer, what would it be? Like? Your best approximation of that. And then what does your release candidate look like? And basically, ideally, your release candidate in most scenarios is closer to God than it is to fin, you know what I mean? And somewhere in between this God fin spectrum is like, is it a product improvement? And then you have to then look at the sum total of like, some stuff will be a regression and some stuff will be a huge improvement. And then there's a bit of taste or a judgment in like, hey, have we net net? Is this a better product? And that can be true every time we change a prompt, every time we change a subsystem model. We've been training a lot of our own models, so when we swap them in, that's another thing that triggers an evaluation. If we change the fundamental architecture. That's the thing, you know, the UI can impact this too. So you can ask like, if you have a text boxing escalation rules, you'll get a certain set of escalation rules. People are going to write in. They're going to write in what they think is an escalation rule. Now imagine you say the best way to structure an escalation rule for a prompt is blah, blah, blah, and that's your label and you provide a lot more context in the ui. That's simply gone. You'll get better input. Now you have to work out is that better input going to improve things or not. Right. The whole thing is a big organic blob where every change trickles something up or down. So you have to have pretty good testing to make sure that for starters, you shouldn't be making extremely a very, very minor. Like fixing a typo shouldn't trigger an end to end evaluation. But perhaps changing core UI for a configuration screen on the agent should. Right. So you have to have some discipline about what we'll test and what we're actually kind of more comfortable with. And then like yes, but that is the like. That's the nature of software now. It's empirical observation.

Insane that this in such a short time span, such a huge shift. How do you filter for the right people to be able to do that kind of work? Or how should companies think about themselves? Because I think customer supports a great example. Everyone's experienced bad customer support or knows what it should look like. So there's a little bit of familiarity. But for companies building different types of products, what startups or founders have you seen really instill a culture that, that works well. I saw an interview for this that you guys by February wanted to double the output, I think of the engineering team or double.

Double. Yeah, yeah.

And I think you guys gave a great like way to measure that was are the designers shipping code like every designer should be shipping code? Are there things like that that you see as common patterns in startups that are adapting successfully to this new age of software development?

There are a lot of ways that you need to adapt. One of my favorite writers of software is a guy called Joel Spolsky and he had this thing called the Joel test, which is like 12 questions that would tell you if you're running a good software or I think somebody, perhaps our chief air officer could do this, should write the AI version of that. But things that I think are not an option. This experiment, empirical observation, culture and having proper scientists who aren't people who are better than your average product engineer are running a decent, disciplined a B test, actually finding meaningful differences, that's huge. If you don't have that, you're not in a position to build good AI, you might still make progress. But you should be aware of the risk you're taking. There are areas of like, well, it doesn't really matter if you're not wrong. And sure, you can find the. Okay, cool. Like, for example, if it's like, we've got AI that generates an email for your newsletter header. Right, Sorry. Generates an image for your header. Right? Like, there's only so wrong that goes, you know, could still go wrong, but like, it's only so wrong it goes right Versus if you're closer to like, you know, like load bearing infrastructure, then yeah, you want to be pretty good. So I think that's kind of test one, if you like, then your entire like, project planning and roadmap culture has to support it too. Right? So you can't be like, saying, we have an experimental culture and then also saying this has to release on February. That's not an option. Right. You have to adapt that as well. I think you need to empower work streams to continue digging in areas to make the thing really good. There's a different org that would have been happy with 23% fin, and a different org would have been happy with 50% fin. But the reality is you have to keep digging, right? That's the competitive battleground here. People mostly care about whose agent does the most work. And today that's Fin. But only because we've made it so

you can't wrestle those laurels either.

You have to continue. Precisely. And we can talk more about that as well, because it's not even just our competitors. It's also like, the models get better at this every year too, right? So you have to kind of work out like, hey, a lot of stuff that we fought for three years to do, is that now coming out of the box? That can happen, right then, yeah. The designers should code. The designers need to own the front end. The designers should be vibe coding the roadmap. Your roadmap should be pretty detailed when you actually go to customers with it because it turns out, like, mocking up a version of a screen is now pretty cheap in the grand scheme of things. Your engineers should be well versed at finding what. Like, when we talk about 2X, a lot of people think they have this mental image of like, developers typing twice as hard or like Claude working at the same speed as Daniel. The 2x in practice is probably more like a 30 or 40 or 50% boost on the engineer most of the time, combined with certain projects where it will be like a 100x boost. So let's say like, Fin has a slack integration, Fin has a WhatsApp, and a Telegram integration if someone wants teams, and a discord and I don't know, three other. That's a very AI addressable problem with a very concrete definition of what complete and working looks like. So you could actually, literally, if you're good at AI engineering, you can say, here's what we need to get to. Here's how you test if you've gotten there. Here's an example reference implementation of how it worked for Slack or Twitter or whatever. This works for data integrations as well. Loads of different things. But like, here's a reference, here's a goal, here's a target, here's a test. And you can practically just say go these days. Now someone's gonna be like, duh, have you ever done this? No, it's not. But I mean, like, you're definitely building those things, I would argue at least 10 times faster than you were even six months ago, certainly three years ago. Right. Like, in that regard, the speed of code is just totally different. Right. But the domains where it works extremely well are like, where you can really just give it a target, that that's where it can measure itself if it's a deterministic and you can give it a reference implementation or something. Like, sometimes connecting two APIs is a great example as well. And you'd ask to go from Y2Z. Like, Fin should be able to populate HubSpot with these things. Here's the Homestead API, here's the Fin API. Go. Yeah, and it will work it out, it really will. But you just have to be good at seeing those opportunities. There's no point in going halfway through human and being like, oh, now that I think about it, you know, you

have wasted all this time.

So like, anyway, you should be shooting for a 2x in practice. We have people in attorney who say 2x is nowhere near ambitious enough. Right. On the flip side, which people are saying, like, it doesn't feel like we're 2x yet. Like, as in we might be by, like by lines of code or by pull request, but like, it doesn't. Has it really caught. So we're still figuring this out, but I think like, the thing that matters Most about the 2x thing is actually making the decision to do it is the hard part. Like, and a lot of engineering leaders, in my opinion and experience shy away from actually saying the hard thing, which is we're going to duple productivity using AI. Right. Because it sounds. Yeah, exactly. People don't, like, you need to be comfortable saying uncomfortable things in this era. In general, but for us, it's a part of performance. As in, it's literally part of your performance evaluation is your ability to use AI tools. And that's like, you're kind of like, that's not cool. Right. The cool thing is, hey, guys, it's just going to be hackathons all year. We'll have a little hobby project. And look, Jenny built a new lunch ordering app. Isn't that cool? That's the cool thing to do. Right? But in practice, if you're deeply serious about using AI to enhance your engineering and to speed it up, you actually have to say, let's go do it. And that's going to be the norm. And if people don't perform at that level, that'll be an issue because that's what management is. It's setting a standard and holding people to it. Yeah.

So I want to talk about the future of, like, being a platform that does everything as well. But walk me through one of those. Maybe walk me through what it looks like someone who's nailing it, who's actually adopting these tools really well and how you sort of go about checking that.

I think you want those people to be an extremely high leverage positions. Like, you want them to be principal engineers because you actually don't want. You don't necessarily want them on one project. You want them running around on all the projects being like, all right, let me talk to the leader and the team. Okay, I see. What I see here is there's a pattern where we're trying to do this. A lot of times, I think if we can just set up an eval for this instead of evaluating, it's somebody who can move around teams articulating where and when to apply kind of Claude, in this case, and maybe giving a steer on how they'd set up the agent or agents to work together. Like, so as an AI, we can decompose this into five different problems. Each of these is kind of independently verifiable. Right. I work on this and I break that work across two people or whatever. Right. Like, does. It's more like. It's almost more like you're a consultant, advisor type person. There are occasions where, like, hey, this thing's really messy and really nasty. We need one person to go on it. Right. Like, or one of our genius engineers, whatever. But like, a lot of the times, you know, the actual real, you know, we're hiring people who are like college graduates as well. They don't necessarily have the experience. We have people who are like, only maybe over the Last few months getting into AI engineering. So you're kind of, you're trying to give everyone corrective steers here. And if I was to make a sort of slightly higher level point, it's that it's. I don't, I think people talk orgs that I don't get this. They talk about Claude or Windsurf or Cursor or Devon, like as if they're a slightly better version of Jetbrains or something like that. It's a slightly nicer ide. And actually not that you have to reprogram how you think in your head, you have to reprogram how you think about software engineering entirely. It's very mind opening. We recently ran a FIN hackathon where everyone had to build their own version of FIN using claude. I participated and I'm not like I haven't written a line of code in 20 years, right? But I was able to go at one point I was number eight on the leaderboard. But like, what I found most interesting was I started off being like, all right, make the prompts better. All right, let's build a better re ranker. Let's build this like, show me about the rag. Let's see if we can improve the retrieval. After a while I realized I'm actually thinking about this in an old school way. I'm thinking like if I was trying to write code, I'd be digging into each of these files and seeing what I can tweak and touch or whatever. And actually what I ended up doing was saying, all right, here's what you need to do. I want you to build me a kind of a lab notebook where every time we do a new run to evaluate, I want you to store the results and store the diff and store the change and store it. If it's a regression, roll it back and if it's a progression, roll it forward. All right, so that was like setting up the lab environment was the first thing I did. That was the biggest probably leverage thing I did. The next thing I had to do then was I was like, right now I need to stop telling this thing how to solve the problem. And I just need to tell it what the problem is. So it's like, here's what we're trying to do. Like, here's the tailor's questions, here's the documentation, here's the scoreboard. I need you to go and learn everything there is to be learned about RAG AI ML. So I started feeding it out. All of our own AI teams research, our own AI research Blog our competitors stuff. Anytime anyone's boasted about doing anything clever, I was like, I want you to read this. I was just loading in a PDFOFF archive, you name it, just give me all this. And I was like, right, give me 15 ideas for what you can do. And I had 15 ideas. And I was like, all right, I want you to ship each of those sequentially. Roll back if it's. If it's a regression or a degrading result, roll it forward. Otherwise, work from 1 through 15. Don't ask me any questions, dangerously. Skip all the permissions. Go. I went home, I came back the following day and I was eight on the leaderboard. And it had worked all night. Probably cost US$200 in credits, but that's, you know, if someone asks me, how did you get there? I'm like, I don't have a clue. I actually don't know what it did. And better than that, all I have to do is teach it how to think, which is just like, I know that this feels like a tired or elaborate story, but it's. That's. The nature of software engineering has just changed. You're teaching the agent what good looks like and what the problem is and maybe what sources you think it should definitely consult to help it get new ideas. I found a PDF on archive that I copied one of the techniques that when it copied like a one point lift. Right. I don't even know what the thing was, to be clear. I literally don't know what the change was. I couldn't tell you. As a side note, I haven't even looked at the source code of this. I've never looked once at all the code that's been written. I do not know what is in that folder. I just to cloud. Yeah, but like that's. It's just such a different nature of engineering, right? Yeah. And if you don't respect that, I think you're going to end up basically like with a slightly better ide. And that's in the middle of an era of super intelligence where everyone has two extra 3x or 50x to their productivity. Right? Yeah.

It goes back to what you're saying a little bit about a lab environment instead of a production environment. You're kind of assuming you're smarter than this thing actually. You've just been giving it context, just helping. And tell me how we should be doing this.

I could go on and on about this, but like I was at one point I said, spawn more agents if you have to. And I was like, thanks, I will. And Then all of a sudden I looked and all, there you go. Yeah. And it's like again, like me even just being like, you know, I was trying to think previously, I was like, I need to like, maybe I should run this in a few different tabs because I have my list of projects. And I was like, no, actually, hang on, I should talk to this. Like, it's a director of engineering, which many people believe it, not like it's an engineer. Right. And. And like later on, I think in the future of all this, when you have like when there's a claw of design, which Figma will probably be in the fullness of time, and when there's like a, a cloud of like product management, understanding, feature requests and all that, there's a version of this where you're like, do business and you hit return and you see what happens. Right? Now that's futuristic fatal sort of shit, right? But like, yeah, we can see the pile. Yeah. Like it was in, like it certainly it's going to end up closer to that than it is to today. You know, that's the direction of travel. Yeah.

I could talk. It's insane, the progress it's making. I think the most important thing underpinning all this is you have to fundamentally rethink not just how software development works, but just how you operate within a company, how you yourself think, how you're using these tools really, not as a way for you to figure something out, but to get information and do these experiments. I think that's really important. Let's talk about becoming the platform that does. I don't want to say everything, because that's dangerous, but walk me through your vision of. With these powerful tools, what does FIN actually look like?

As we've been succeeding with this, say, customer service agent, what we've observed is that people want more and they want more and more and more. And so people were like, hey, I want FIN to handle refunds, end to end, go and find our refund policy, read it, apply it, all that sort of stuff. And like our attitude is, yep, yep, yep, yep, yep. And then, then you get questions that are just on the edge of service. Like, if somebody asks about an upgrade, why don't you upgrade them? It's the same thing, right? You're like, I guess that's true. I mean, upgrading is just an API as well, right? Like, I could just ping stripe and put them on the higher plan. And then you realize, okay, this is happening. Our customers want this and it is a customer success trigger. It's like, hey, Can I get FIN to talk to somebody if they haven't uploaded the file yet or something like that. And you start to realize like, why are they pulling all this out of fin? Well, when you talk to our customers and most people, like, they sort of say, well, I was going to go and try and buy a sales agent, like an inbound AI powered SDR type product, and I realized I'd have to then have two agents. And then what are you going to do? A218. You're going to end up recreating the worst of customer communication today, which is bad orchestration and bad handoff. So they're all talking across each other and passing things back and forth. Then you've also this amnesia problem where you know, we've all had it on the phone, like, oh, let me put you through your payments. Hello, payments. Who is this? You're like, it's been half an hour. Exactly like, and so no context gets passed. So what you realize is like, hang on, all of these customer communication problems are going to be identified, right? And the optimal solution isn't going to be a dozen different disparate agents all talking across each other, all with their own closed scope world, all with their own different goals competing with each other. That'll be an actual nightmare. The Internet would just be like a mess. And it's also not what customers want because now all of a sudden you have to have to buy 10 different agents. And every agent requires different training, different policies, different procedures for the same product context, the same tone of voice, the same brand guidelines and you have to do all that work times six, at least, right? So our vision with customer agent is shared context, shared memory, shared actions, shared integrations and then goals. And the goal of an agent will be kind of timely, context dependent. If you're a new visitor on the website asking about the enterprise plan, the goal might be get this guy talking to a enterprise sales rep. Yeah. If you're in the product for 100th time and you're on the billing screen and you say this, you know, why can't I? Whatever. Well, the context is maybe because your credit card's expired or something like that, right? So that's a difference. Your goal might be make the user happy again. If a user's seemingly lost, scrolling their mouse around, doing nothing on the like, whatever the settings screen, your goal might be, help them. So you might pop up and say, hey, like it looks like you're lost here, what can I do? And if your goal is like, you know, Johnny's on A triple premium platinum plan. And he's zero teammates and zero files uploaded and he's hovering over the cancel button. Your goal might be, you know, prevent or whatever. And if it's the first time in a product, your goal might be onboard them to a certain point. But you like, you have to like in all of these cases the agent has to know the product really well, has to be able to answer any question that can be thrown at it really well. So you're going to want the best rag, you're going to want the best product context, you're going to want. There's a lot of stuff you want to do the same. You don't want the agent to have forgotten that the person who was on the enterprise pricing page and when they signed up, you don't want to be like, sorry, who are you again? So you want to be like, now that you're on enterprise plan, let's get you set up for like role based access controls or whatever, right? So you have to have shared context, shared everything. So that's really, really important. And then it's just a case of orchestrating designing these goals like the way humans work, which is like sometimes the right thing to do is X and sometimes it's Y and I'll just do the right thing at the right time. And so that's where we see it going. And I just, I can't see any other world. Like whenever I think about other agents, I just see this lost world, this void of context. And then separately it won't be lost on any of your listeners or viewers. Like most agents out there aren't great. So like you're going to have this weird experience where you've got this fin in the corner who can answer any question but can't upgrade you. And the upgrade guy doesn't have a clue who you are or what plan you're asking on. You know, it's like, it'll just be horrible. So like, so the answer is the customer agent, the single agent that can do all customer conversation.

And is this why you guys are so well positioned? Because you already have so much contact not only on, you know, the customer experience, because you've got, you know, all this data already, but also because you know the workflows and how they integrate with product with, you know, sales, with all these other types of parts of the business.

It's definitely useful that we have all that experience. But the real for us to get to the core of why are we well positioned? I think it's like our AI is Like stronger. That's because I think this battleground will be ultimately, does the AI work or not? Everything else you can kind of hire in or hire consultants on or whatever. It's certainly useful. We know how sales always works and how marketing always works. We have a lot of customers in there already and our customers are already kind of pulling this product out of us. But I still think, like, the AI will rule the rooster. So whoever's agent actually gets most leads to sales, actually gets most customers successful builds most renewals, sells most products, whatever the agent might be. Like, there's an E commerce version of this where it's going to be a buying assistant, which is super cool as well, because again, a lot of the questions Fin gets is things like, hey, can you recommend me a couch that's easy to clean? And Fin does a really good job out of the box. Not because you've told it what couches are easy to clean, but Fin knows that, oh, polyurethylene is easy to clean fabric. So there's so many different use cases where Fin needs to be out of the box. Great. Where I just think people, when they go shopping, they're just going to want the product to do performance best.

Yeah. I mean, that's actually how it should be.

Right.

Like, you want to be paying for whatever is the best product. So it's actually an ideal world in

a lot of ways. Yeah. It'd be a difficult world for like the larger incumbents around us in the stack as well. Because I think what will happen is the majority of the valuable conversations, valuable customer context will now be in, like, it won't be on the case notes in Salesforce in the customer context. Right.

Because it's shifting so quickly. It's going to happen and they're not going to have any visibility into how they'll be.

Like, they'll be in the same way. In the same way. You know, like, if you think about the mediums of say, like WhatsApp email and printed letter to your house. Right. Every time a new medium arrives, it relegates the other one to being closer to being the source of formal record. Right. So like when you get a letter to your house, that's someone saying, no, we're actually serious about this loan. Like, whereas when you get a WhatsApp, it's probably a bit more casual. Right. And in a business culture, like most teams I know communicate through Slack or Signal or whatever. And then when you get the emails, we're going on record, are we? But similarly, I think that would be like The CRM or the help desk, like, let's say a Zendesk, wherever it will be updated after the fact with here's what happened. Or it might even be updated in real time. But the point is, no one's logging in there because it's not the primary interface. The interface is like, what's the agent saying? That's the thing you actually care about.

That's interesting. I think this transitions nicely into the Frontier Labs themselves. And you have 50, I think, or 60 people working on AI, specifically intercom. How do you see? I talked to Winston from Harvey about this, and he said you just have to be constantly out shipping them in your specific vertical. What does that look like for you guys? If at some point these agents out of the box do keep getting better, how do you think about structuring? The roadmap's a strong word, but where to focus?

Yeah, I mean, out of the box, there are skills that they'll just get naturally better at, that's for sure. And some of those skills, we've had to do a lot of work to get working in fin. And in a year's time, it might be just commodities. Right? That's fine. That's part of the game. The thing you have to be mindful of is, like, how easy is it to build a fin out of the box? So do you kind of have a sense of where power is and where the differentiating factors are? What our AI group do is the thing. I think it's called the. It's the Nth country experiment. It's a Wikipedia link, if nothing else. Well, I'll tell you what it is. Basically, when the US was trying to work out, right, like, who can build nukes and who can't. Don't worry, this will get back to the point. What they were doing was like, so obviously the US can build with nukes. Everyone knows Russia can build it. China probably can as well. Right. Somewhere down the list, on top of can build, not can buy, then who can actually make their own? Somewhere down the list it stops. Right? But where does it stop? And how do you have a correct defensive posture with a country when you don't know if they can or can't build nukes? Because they're not all going to stick ads up saying, like, you know, lads, we can build nukes. Work in progress without. So what they did, which I know was really interesting, was they hired three, like, extremely talented, but ultimately talented, but not ridiculous, outlier physicists for three years and said, we want you guys to try and Build a nuke. But we're not giving you any assets or anything, we're going to pay your salary, but you only have access to publicly available material. And when they did that, because they're like, you know, let's see how far they get. And after three and a half years I think they built average, they had the prototype of what would have been aversion of a nuclear bomb that caused massive damage or whatever. And that was. So the realization they had was basically, huh, like we should assume most countries have nuclear capabilities because most countries have tree smart people. And tree smart people given three years can do this. Right? So that's it. So none of that would have fed into policy around how they partner and rules around who's allowed to help them and all that sort of stuff. Now why so I got to do the labs. Well, our AI group will regularly interrogate like, hey, given the latest model and zero context, how far can you get? How close can you get to fin performance? And they'll get yay far and they'll report back. And it helps us understand what's available out of the box. What's available out of the box to a couple of smart YC hackers and where we are and what's the difference and what are the vectors of differentiation that still matter? Where do we think we've done harder work, gone further than most will go to get results? Where are we getting our interesting gains that the ones we don't like to talk about? So it's a good experiment and there's a version of that you have to do and I'm guessing like Harvey are going to have to do something similar, which is like, okay, like given a shitload of law cases and a legal question, how far does GPT get? Like naked out of the box? And then if we build a little AI architecture, maybe a bit of rag, a bit of retrieval, all that sort of stuff, can we, can we get further and how far? And at some set, like, you know, you start to get nervous when it gets closer to where your base model is. And then you start thinking, right, there's a good chance like some sort of commoditization might happen here. So your options are push further, get further away from it or not, right? Like I think that's the thing you have to be mindful of.

You have to be. It reminds me a little bit, I'm going to butcher the story, but Amazon did something early on as well where they had separate teams trying to see compete with us with less information, with less resources, just see how far you can get. We're out of time. Where should people go if they want to work at Fin or work at Intercom or try the product out? Where should people go or check out some of your writing which is also very good.

Yeah, we didn't get to it but yeah. So Fin AI is where our site is. Our company's called Intercom. Intercom.comcareers is where if you want to come work with me and all the guy here we're based we hire R D people in Dublin, London, Berlin and we hire a sales marketing support in Chicago, San Francisco and Sydney. Fin AI research and ideas. Fin AI are probably like if you found this conversation interesting that's the areas you'll probably find most value. Yeah.

Awesome.

And I'm des trainer everywhere if you're looking for me. Including the writing. Yes, exactly. Awesome. Cool. That's it. Cool. Thanks so much.