I had a really interesting conversation with one of our engineers last month. It was like, hey, we've got this customer. They pay us six grand a year. They give us tons of feedback. Are we over-focusing on them? And I was like, we're under-focusing on them.
The fact that they're pointing out these little bugs that we're missing or little places we can do better, nothing about what they're saying is specific to them. Like, I would pay them six grand a year for this. I'd pay them 60 grand a year for this. Like, we should lean into this and go really hard and make sure we're...
getting to the bottom of the well of how we can make them successful, because I'm sure if we make these guys successful, we'll make the next group successful. Welcome back to Wild Hearts. I'm your host, Mason Yates. I'm on the investment team at Blackbird Ventures. Customer support is one of the most obvious opportunities for AI. There is a jungle of well-funded upstarts and legacy solutions fighting for a piece of this huge market. And yet...
Steve Hines, the co-founder and CEO of Lorikeet, breaks down the principles, frameworks, and product ideas that fill him with the belief that mean they will win. I'm not going to steal his thunder in the intro, but what I will do is rant off one of the most ridiculous career highlight reels of all time. And frankly, because he's just too humble to do so. He started his career at BCG.
was a baker scholar at hbs so the top five percent at harvard self-taught himself python built trading algorithms on the side during his mba managed investment researchers at bridgewater associates ray dalio's hedge fund and wrote production and prototype code at Bridgewater. Completed MBA internships at Quiller and Buzzfeed. BizOps at Stripe with Claire Hughes-Johnson, the COO.
moved to PM under David Singleton, the CTO managing 70 engineers, was in the top 1% of stripes for performance and potential to most recently leading Watershed's core product in San Francisco. A reference said he has that interesting balance of being a killer and a lovely guy. He's intense, hardworking, and able to cut through the noise. In this episode, you'll capture his approach to building a product that customer support teams are.
and will fall in love with or as you'll soon see he'll correct me on that one soon let's dive in i would love to know about the highs and lows of 2024. How do you feel about the year? I mean, 2024 was obviously a good year. We went from not having a product to having a product that is winning and competing in deals we don't have a right to.
One of the interesting things about Lorikeet is we just had our heads down, really focused on some of the early customers and building for them, and then started to get into these more competitive deals with folks out of Silicon Valley who've raised hundreds of millions of dollars. and found that the product was better and we were winning and we were like, oh, crap. And so those were the highs. And then I think the lows were the flip side where we had a couple of deals where we were like,
the shortlisted solution internally. And then a VC called the CEO and said, you should use these other guys. who we just poured a bunch of capital down the throat of. Wow. And we got boxed out. We actually had one of the people running the evaluation emailing me for talking points to go argue with the CEO about...
why he shouldn't impose another vendor on them top down and we lost we lost like you know she didn't win the argument but the fact that she was willing to go have a big argument with the ceo about it yeah showed us we were onto something but it was a signal that okay like we got to load up tanks
we've got to give ourselves the runway to really go for it here because the product is doing something special. And if we're seen as like a bunch of randoms in Australia, we're going to be screwed. And so that's... that sort of got us to where we are now. And I think that's the high and the low. That's a perfect segue. So to take a step back, you're operating in one of the most competitive markets in AI. And as you alluded to, you're up against some...
pretty well-funded competitors, and yet it appears that you do have the most special product. If we rewind to when you were forming the idea of what is now Lorikeet, how did you see yourself within that context? Jamie and I raised the money initially actually to kind of work on what I'd call like a meta productivity tool for ops teams or an operating system for ops teams. I've worked with a lot of different ops teams at Stripe and saw sort of...
actually like surprisingly similar dysfunctions, and then moved from Stripe to a climate unicorn called Watershed and saw exactly the same ops problems. And it made this light bulb of like, oh, there's like a commonality here. And the commonality is around information flow.
to leadership and llms can be really good at that because llms can go talk to people and collect information infinitely scalably and there's something cool there like a sales team runs out of salesforce what does an ops team run out of We found relatively quickly that that idea was a great way to get people praising you for being a product visionary and a pretty bad way to make money selling software because if you build a product that doesn't tie to changing an existing...
business metric, it will be very hard to charge more than $20 per user per month for it. And when your TAM is constrained, like ops teams in startups, it's hard to build a big business that way. And so because we spent so much time with ops teams and the modal ops team is support, we were like, hang on, like, their problem is not a meta problem. Their problem is actually just doing the work. And we think the AI can do the work. And so let's go stare at that. And we had just a...
chalk and cheese change in reception from customers and design partners once we sort of started exploring that space and decided to chase that pool. And this is October 2023. So obviously the idea of using AI and customer support.
was was in the bloodstream but you know the mega rounds um you know the big name founders sort of coming out of self all hadn't happened even at the time though if we'd done this through like a very cold top-down pen and paper market entry exercise, we probably would have said,
seems like a red ocean why go do it but we didn't we were just like we really like trying to figure out how to solve ops problems we really think we can do a good job we're seeing massive organic pool let's just keep chasing this and that's sort of how we got into it you mentioned something there which was really interesting The first one though that stands out is the relationship between the contract value and being tied to a business metric. Can you talk a bit more about the journey of going?
Well, we have all of these commonalities across. Stripe is world-renowned to have some of the best operating principles and operating machines in the world, and they still have these problems. Just walk us through a bit more in detail around that journey of figuring out that actually we can't charge that much for this. Most operational teams at...
brand name companies and obviously you know i had this experience but i validated it by talking to a lot of other people from all the fancy unicorns you could imagine because they're all very willing to talk to you and you're an interesting product idea most operations teams can't actually give you a list of all the operations they're responsible for
They do not actually have a catalogue of all the work they do. If you ask them to apportion how much time they spend on different tasks, they can't with any degree of accuracy. Therefore, they cannot just by definition.
really targeted improve it in a targeted way they can't go to a product team and tell them what product initiatives would make the biggest or the smallest difference to the operational load etc etc so in theory we were like okay look you've got an ops team of 10 people if just having this
usability allows you to make them 10% more efficient. You've saved an FTE worth of salary, which is 100 to 200K. So you should be willing to pay 10 to 20K for the product. The problem is there's so many... should-bes and ifs in that statement, that when we're talking to design partners about, and thankfully one thing we did was ask design partners to pay a good five-feeder chunk of change.
to work with us, they'd be like, okay, cool. So what metrics should I tell the CFO this will move? And I'm like, I don't know, man. Like, it's going to help you figure that out. And you probably think you're going to get there. That's why I'm here. We're going to figure that part out together.
Outside of support, everyone's operations are totally different. I mean, people's support operations are different too, but at least they have common metrics. But you go outside of support. The way one billing team works is totally different to another billing team, to a trust and safety team. etc. And so ever getting to the point where you can walk in straight away and say to someone, here's the ROI of the product, it's going to be really hard.
And these aren't teams that can easily command big budgets. And if it's a category that doesn't exist before, you're doing category creation, which makes it harder. And so that's where we were like, this isn't it. And to give you an example of the type of change we saw, we were working really closely with Eucalyptus.
A couple of their teams were adopted because we were shipping product to find this out, by the way. This wasn't a desktop exercise. The teams were using the stuff we were seeing and they were giving us some feedback. One day, we floated to Estelle, who was leading the patient support team, like, hey, maybe we should just be solving the support ticket. And she literally dropped what she was doing and was like,
That's way more interesting. I'm going to clear my calendar for this quarter to work on this with you. And we were like, oh, that's what cool feels like. And then that afternoon, I called up. Mira, who we were lining up to be a design partner where we were really struggling to get the business case for them to pay some cash, called Jack, the co-founder, and was like, I'm really sorry. We've got to pivot, and I'm sorry we won't get the chance to work together on this.
lovely guy was like of course like i understand i'm a founder um out of interest what's the new thing and i explained it to him because oh that's way more interesting can we be a design partner for that and i was like okay like this you know yeah we were barking up the wrong tree here and you know if we were if we were fueling our tanks in that period by like
compliments and phone calls with cool people at cool startups, I think we'd probably still be digging that hole. But because we were kind of like, yeah, okay. Thanks to the compliments, but when we pay $20,000 to be a design partner, we managed to smoke that out relatively quickly. Before we jump into the current product, I have to ask, what are some of the most common problems that are operations related?
Yeah, yeah. So the thing that ops teams struggle with is there is so much work to do that pulling your head up and even writing down what the work is, like writing a playbook. feels like too much when people are overloaded. It's very common in ops teams that the manager is like one of the early ICs who's really good. And they're just like, okay, cool. Now everyone reports to you.
that person doesn't really have firsthand experience leading before. They're often still doing like 75% of an IC job plus a manager job. So their capacity to like go around and talk to the team about what's going on is really limited.
And therefore, the ability to have this strategic agenda is low. So then they sort of get these moments of cries, oh, eng team, we've got to change this thing. Eng team's like, okay. Sometimes they say yes, then they change it. Nothing happens. Ops team's still on fire. Did that even land? Oh, I don't know. We're on to the next thing.
It's all such a mess. And one of the things I noticed at Watershed, we were measuring people's carbon footprints and I was responsible for that product. There was an ops team that did a lot of the work to munch the customer's data and work with the customers on the nuance of it.
In the surgery measurement periods, I was sitting down with the ICs just being like, what's working or not working in the product? And I'd come away from these one-on-ones being like, holy shit, there's so many ideas here. Someone's in tears because they spent the weekend debugging this thing that you could solve with a for loop.
just really brutal stuff and it's not bubbling up just because everyone is so flat out trying to keep up that's kind of the crux of it this this just core problem that in ops there is so much work to do that the ability to get above the work and figure out how to change it is really hard. And it takes like a really exceptional leader to do that because the gravity is all against you. And so how long did it take you to shift into support? Jamie.
joined me full time on the 15th of August. And we like called the shot to pivot on the 19th of October. So eight weeks. Okay. That's a useful benchmark for people to think this is how quickly we move. Yeah, in that eight weeks, before Jamie had wrapped up at Google, I'd shipped the V0 of the product myself. Jamie and I came on and iterated, built a few more features. So maybe, yeah, 10 weeks. But I think the key thing is the conversations and the shipping were happening at the same time.
So we weren't just relying on what people were saying to us. We were like, how is the team at Eucalyptus using this? Are they using this in a way that looks like a product that is going to get high organic adoption and success? And we just weren't seeing it. It had this problem that because it was meta...
It was just extra work for the people to do and the people are already really busy. So like, yes, it's like eating their spinach and I'll get like the managers that you were loving it, but like getting the ICs to organically and enthusiastically adopt it was hard. And that was sort of.
also one of the things we were seeing that led us quite quickly to figure out we need to do something different. And so was it like, oftentimes there's this sort of midpoint of success where like people are using it, but you're not seeing the pull that you described with Laura Keith's newest version. And I'm just curious to hear more about how obvious was it? It was obvious to us because we were holding a high bar. We were looking at number of conversations with this AI coach we had per day.
A number of times people were reading each other's daily summaries and call-outs, the agenda that we were boiling up to the managers, the engagement with that. There were some ICs on the team that were super users, but it wasn't one of those things that was quickly clicking and getting broad adoption. One of the interesting things that was a clue is actually a couple of the ICs who were using it the most were using it to draft support tickets.
interesting yeah so it was supposed to be there to like coach them on how to escalate issues and how to spot patterns and actually they were just being like hey help me do the work and so you know you sort of get those clues um but i think one of the things i feel
grateful for in the process is it illuminated to me how easy it would be to trick yourself into building something mediocre if you were going in looking for confirmation bias and instead you're almost like looking for the market to disprove what you're doing. And I'm very glad we did that. Yeah. Yeah. Wow. So you made the pivot, switched it after eight weeks. Walk us through how those conversations had evolved. Share a few more like directional clues that.
actually we're on the right path and basically if you were to back solve from where my mind is at which is how did we arrive at the special product i'm curious about the journey that uncovered that uniqueness yeah i mean Clues. Friday the 19th, we called the shot to pivot. Saturday, I was at the farmer's markets at Carriageworks with a friend who's a founder. There with our kids, asking me about support. And he was like,
yeah, like, we're pretty interested in this. I'm like, do you want to be a design partner? He's like, yeah, sure. And then, you know, had to catch up with a former Stripe colleague who's now at a company in the U.S. Sequoia had just funded. Hey, he's like, yeah. And all of a sudden, he had like six design partners. It actually turned out.
talk more about it turned out to be too many and we ended up firing most of them um but just kind of it went from just like anyone was willing to jump in and it seemed it seemed very obvious like the value prop was very clear and that sort of meant you know it was it was going to roll from there
In terms of what did we do that built a different product, I've tried to back solve this. It's a little bit hard to know because I don't know what other people did. But the observation I would make is, number one, Jamie, my co-founder. had been doing LLM research at Google for several years before he joined me. And we together had this ambition that we want to do something interesting. And he literally said, I don't want to build chat with my fucking help center.
you know retrieval augmented generation was a known architecture pattern at the time everyone knew that you could use it to solve support tickets and we were just like we don't want to put hours of our lives or years of our lives into like commercializing this commodity architecture off the shelf
And more than that, though, we were embedded with Eucalyptus's patient support team watching them work. And none of what they were doing was summarizing FAQs. So, you know, if RAG as an architecture is basically like search across the knowledge base, find the answer and summarize it.
It just didn't match the reality of the users. That was not their problem. Their problem was that when you're in a complex environment, solving a support ticket is actually about gathering data from a bunch of sources, following a multi-step decisioning process that involves judgment.
and then coming to a conclusion and kind of sharing that conclusion or sharing the next steps to the customer. And so we focus on how to build that and how to build it with the level of precision and performance you need in a sensitive area like healthcare.
That decision to go after the hard problem and really think about it for first principles is what set the product up to outperform. And I actually think, as I've reflected on it, it's more about product building culture than about tactics. And part of the reason for that is... In the last couple of months, we now have a RAG solution that kind of complements the more complex stuff we do. In the last couple of months, we've had a few pretty high-profile head-to-heads and have actually...
Yes, we've shown them we can do complex stuff. Other people can't. We've also won really comfortably on the rag stuff. I'm like, we don't know why, because we feel like we built it in a way that seemed obvious to us as we understand the problem. But I think what's going on is if you build this culture of like, we're really going to stare at it and think for ourselves about what the user's problem is and how to make it good, then you build some repeatability in building winning products.
our competitors are in a slightly different position to us. But if I'm being 20% shady, to some extent, they're just sitting with the solutions architects of OpenAI and building the shit they tell them to. And effectively going from this technology, which is retrieval, augmented generation or agentic reasoning, and then commercializing it. And that's a very fast path to market. But does it set you up to be this engine that solves the right problem on repeat? I'm not sure.
So on the topic of culture over tactics, can you share how you have implemented that culture and how it stays top of mind for the team? Like, it's one thing to say, hey, this is our charter. Like, this is what we believe. And like, these are the opposing beliefs.
Like there is a degree of being reminded that actually really matters. And I'm just curious what the cadence looks like. Or is it just in everything you do? I'm trying to think of a way to answer this that's useful and doesn't just sound like I'm patting myself on the back. I think it's an innate way that we operate that probably...
has bled out by osmosis i i don't think we have too many confected like rituals but we do have this like you know embedded thing from the beginning like every engineer is talking to customers all the time engineers own the future they ship
product or design or anyone else's services to them to help them shift the right thing. And so that idea of being very close to the user and really thinking about what they need has been embedded in everything we do. So it's not quite as much like rituals of...
adopt a customer or anything like that or tactics I've used before in other situations. It's just like we try to be really, really, really close to it. One thing we have that has been high leverage is I wrote a doc a year or so ago called the General Stack Rank. which is a universal stack rank we use to prioritize, which is first, we must maintain the performance of our critical systems and address any outages or incidents.
Second, we have to make sure all the features we've already shipped are working or unshipped them. Third, we need to keep any commitments we've made to customers, big or small. Fourth, we ship new features. And fifth, we make life easier for ourselves. We use that shorthand all the time, and it has meant at times you're with a tight engineering team.
everyone's actually only working on steps one and two. If we have promises to keep to customers, we're not shipping any new features until they're kept. Likewise, if we have bugs and broken functionality in the products we've already shipped, we're going to unship it or fix it. Are we 100% keeping to that perfectly all the time? No, but geez, it's a good forcing function. And I actually also think it forces that user centricity because...
you're just really focused on other people you currently have being successful before you go off on flights of fancy. Because the easiest thing to do in the world in product is come up with shit to build. The hard thing to do is actually make it work. Why is that the right approach?
in a market that's moving this quickly if you focus really hard so strategy wise i think the drum i always bang First priority, single best thing we can do for sales, everything is make our current customers incredibly successful because what you learn from doing that is what works and what doesn't.
That makes every sales conversation more effective and more credible. It gives you the case studies to help you win sales deals. It gives you the references from customers to help you win sales deals. And therefore, it helps you grow. And by staying very close to your customers...
It helps you learn what problems you need to fix. I had a really interesting conversation with one of our engineers last month. It was like, hey, I've got this customer. They pay us six grand a year. They give us tons of feedback. Are we over-focusing on them? And I was like, we're under-focusing on them.
The fact that they're pointing out these little bugs that we're missing or little places we can do better, nothing about what they're saying is specific to them. I would pay them $6,000 a year for this. I'd pay them $60,000 a year for this. We should lean into this and go really hard and make sure we're...
getting to the bottom of the well of how we can make them successful because i'm sure if we make these guys successful we'll make the next people successful um and that pattern has really proved repeatable like What you can figure out how to do with one customer, you can go take on to the next one. You can sprawl your product surface and sometimes it helps you in sales because...
You can answer yes to every question. But honestly, what helps you in sales is like results and references. And then the ability to say, this thing you're looking for, don't really focus on it.
There's a way we could help you do it. We'd be open to focusing on it more in partnership with you, but it's not a place we focus. We focus here instead. And that's kind of more credible than just saying yes to everything. I really love that. How do you measure customer love? How do you know that you're on the right path? I actually think about customer engagement more than customer love. What's the difference?
The customer example I gave before, we were kind of joking internally, like they have really high standards and they have a kind of fight effect. And I think like last week, one of them paid us a really heartfelt compliment. Like the whole team was cheering because I think they've never said anything nice to us.
But they talk to us every single day about stuff we can do together and feedback and ideas. And that's way more valuable to me than people sending us a box of flowers once a month or something. Because you don't give feedback to...
a team whose product you don't care about and that you don't rely on. Think about the products you churn from. You might send them like a breakup note when you churn, but mainly you just go quiet because the reason you're churning is not that useful to you. So yeah, I mean, customer love. Great. Makes you feel warm and fuzzy. But customer engagement, like at one of our customers, like five FTEs working full-time in Lorapea every day. It's the tool. It's their tool.
They're probably spending as much time in Larrakeet as any other tool on their computer. And along the way, giving us a lot of feedback. And we get on well with them and stuff. But that's much more meaningful than praise. Yeah, I mean, I think we're totally aligned. The secret to growth is retention. And that speaks to your entire philosophy of making sure our current customers are stoked and engaged. Not in love, they're engaged.
And it gives you this flywheel, which is like, how do you build good products? You show things to customers, get their feedback and listen to it. When you're already talking to them every day, that's 10x easier. In a previous role, I produced this kind of controversial two-by-two, which was analytics actions where the person or someone on my company's team logged in. versus when the actions were performed by the customer.
And we had this huge cohort of customers who basically never logged in and everything happening in the app was being done for them by our team. Dangerous shit and very hard to get feedback and hard to get direction. And so we've done some things intentionally to never get into that position. One of them is...
We have no admin tool. There are only two ways you can do something for a Lurikeet customer if you're a Lurikeet employee. Manually edit the database or go and do it in the app. And obviously database. access is very heavily controlled and regulated. But the point of that is...
there's no internal tools that are a shortcut. It's like build it in the app so the customer can do it themselves or don't build it at all and eat the pain. And that's been really valuable to continuing to make it like a high engagement product that's usable by the customer. What is the single decisive insight?
For Laura Key. Very little high quality support consists of summarizing FAQ documents. And what is the business impact as a result? If you stack every support ticket a company gets from least to most complex, you put handle time. or effort to solve on the y-axis, it's power law shaped. As in, your 5% of most complex tickets might take 10 times as long to solve as your median ticket. If your product, if your support AI product, climb further up that curve,
you unlock more and more value for the customer. So going beyond just summarizing FAQs and being able to solve a 50th, 70th, 80th, 90th percentile complexity problem just unlocks more and more value. One of the shakeouts that's going to come in 2025 in customer support... is everyone who's rolled out one of these FAQ summary tools is going to start having tough conversations with the CFO. The CFO will be like, hey, I saw the all-hands announcement that we're automating 40% of our support.
But I see that the support team has not reduced by 40% what gives. And what they're going to find out is the easiest 40% of your support tickets are like 10%. of the effort and you've actually accidentally agreed a price for the vendor that assumed that they were like immediate effort and that you know there's going to be a bit of a shakeout like you know
A lot of teams don't think about these distributions. They think about average handle time, and it sort of leads to some analytical mistakes. And so an ability to climb further up the complexity curve is really key to unlocking ROI. Why is 2025 the year of enterprise for AI? Stochastic systems like LLMs are very adoptable in like consumer or startup contexts because people will roll the dice.
and not rely on it. Figuring out how to get these technologies to do something consistent and powerful enough for enterprise is difficult and it's taken time, but now that the proof points are there. everyone is rushing in. I saw some interesting research that the portion of companies experimenting with AI solutions in support.
significantly outpaces what support leaders predicted a year ago. So there's this sort of acceleration. And I think it's because people are seeing that it's coming because they're seeing that it started to be proved out. I think the other element of it is, especially some of the big boys in this space.
have been they've done some very effective marketing that is probably like a little bit out over the skis of where the product is but it's created this air of inevitability in the market that they can go sell into and then there's this interesting sort of shake out of like are they going to get the results they want like i think people have gone past experiment budgets they now want to go do this um but they'll have to be kind of careful to do it in a way that's effective
One of the pushbacks that you often hear is, well, why won't Zendesk do this? Or I won't Intercom do this? They've been planning for this moment. Walk us through some of the disadvantages that they have. Well, they are doing it. They're pouring a ton of money into it. I had a funny conversation with a startup here. They like what they're seeing. They're interested in moving over to us. And the head of support said,
Look, one pushback I'm getting internally is Intercom have announced they're going to spend $100 million on AI. They're spending $100 million on AI. How are you going to keep up? And I was like, yeah, why do you reckon the product's not better then? You know, there's a great Patrick Collisonism that it's remarkably hard to turn billions of dollars into quality software, and this is really proving it.
software is leverage on ideas. The thing that matters is ideas, not money. And startups wouldn't exist if that weren't true. But I think more importantly, if you think about talent dynamics, if you're a talented... AI product builder, you have no shortage of raising money to build AI products. I mean, there are still more competitors to us coming out of YC in the current batch, let alone previous batch. People are still raising VC money to come into this market, right? Yeah.
How much of that high-quality talent is joining a PE-backed, you know, formerly public conglomerate that's 15 years old? Some of them maybe. I don't know. It doesn't seem like that good of a bet. I'd say the second thing is some of the legacy players have this millstone around their neck, which is they sell exclusively to support teams who are afraid of complexity. And they've got themselves into the habit of talking down to their customers.
So if you look at their marketing, it's all like set up in minutes, zero effort. You don't even have to talk to engineering. It doesn't matter if they won't return your phone calls. It's going to be great. It's all magical. That's bullshit. I've never met a customer who actually thinks that's true.
90% deflection in two minutes. They all know. They come onto the call being like, I know these things aren't true, but they're sort of forced to make it because they sell to this old world where support is sitting in the corner. and engineering won't send them a birthday card. What we're seeing is that very commonly, the product teams or the founders, the technical founders are involved heavily in the evaluation.
and rollout because when you make talking to your customers scalable and effective with AI, it becomes much more like a product problem. So support get pulled into the fold. And you actually want to build a product for builders that people who can tinker and play around with and get integrations going can get more and more value out of and not be afraid of the fact that like...
I say to people, I'm like, yeah, we can give you something that works out of the box. You're going to get way more value if you can get like two hours or two days of engineering time. And like, I'll talk to the engineers and help them scope it. I'll pitch to the CTO and talk to the technical language. I'll help you with this, but you're going to get much more value out of it. And I think we can do that.
But some of the legacy players who've made all their hay selling to the support teams will kind of alienate their existing customers because it starts feeling like it's a threat to their jobs and to their role. It's something that I deeply think about, the opportunity for AI. across enterprises and how counter positioning works. Maybe it just comes down to product taste. They obviously have the data advantage. They have the brand advantage. They have...
the scale advantages or disadvantages as you nicely flipped it. But what I'm hearing is a talent, be like counter positioning on product is, is big whereby you have the advantage of. redesigning the product from the ground up, circling around the bottom of the stack being LLMs. Is that fair? What am I missing? I think the other thing that's worked in our favor that I've spoken to customers about.
is because we started focusing on the most complex cases and we continually work with customers with incredibly high standards for the quality of support and the precision and sensitivity. we just keep having to solve really hard problems and keep having to make the product better in that dimension. And that's an interesting approach for two reasons. Like one is a lot of the folks that we're kind of pulling off the legacy players are pulling off their AI.
I'm just like, look, the problems you're having with this solution, we solve day in day out. You are not an edge case to us. You are the bread and butter. We think really hard about this. That's why we're solving it now. We're going to get better at it. The folks you're talking to.
mainly sell to simple SaaS and e-commerce players. You will always be an edge case. Are you confident they're going to prioritize your edge case requests and needs because you're not that big? And they're kind of like, yeah, well, obviously not. But then the second part of that is...
If you do the hard stuff really well and you have a solution of choice for the people with the highest standards, helping people who are less demanding is still very doable and you can go do that and have credibility. I think our gap to some of the competition for a simpler SaaS business is smaller, but it's still there. And because the product is efficient, we can also compete.
on price, on service, on speed, on execution, on the kind of advice that we can give them based on the experience we have. And so it's kind of fruitful, but it's interesting that if you go after the hardest thing first... Give yourself a lot more work to do, but then you can start to kind of compound the results down. And one of the things that's been pleasing for me is...
I think sometimes when I look at health tech in particular, fintech, some of the needs these customers have, I don't know there's another solution on the market that meets them. But then we're starting to talk more to kind of... simpler SaaS businesses or e-commerce businesses. It seems like the product's super competitive there. So I'm quite optimistic about this like roll downhill strategy. Right. Tell me more about the roll down the hill strategy. And maybe perhaps like start with...
Why did it make sense for you to specialize in healthcare and fintech to begin with? And then how that sort of opened the door to the more traditional, typical SaaS? Well, I don't want to overfit too much. I don't know if it made sense at the beginning. What I do know is...
Those were the markets that were least well served by what was on the market in 2023. So it was a good wedge. And, you know, for instance, our second customer was a fintech who were really early beta user of Intercom Fin, and it did not perform for them.
And Intercom couldn't address the feedback. And so great, their loss is our opportunity. But the second big part of it is, you know, it's again, it's a Patrick Collisonism, but it's easier to do a hard thing than an easy thing. If you as a startup say, we're going after customer support. for the hardest customer support problems for the most demanding companies, you attract a set of ambitious people who want to go crush something.
If you say like we're cashing in on a temporary speed to market advantage using open AI solutions architecture team as our product brain, you attract a different type of. of people who aren't necessarily bad, by the way, but it's a different type of people and they'll have their own strengths and weaknesses. But we're trying to do this unreasonably difficult thing and we're going after a really interesting opportunity is a magnet for the right type of talent, I think.
What are the other Patrick-isms you laid on? Everyone now says they use us first. I think Stripe was one of the early ones to really hammer that. And one of the things I worked on at Stripe, it ended up being kind of part of the org I was leading, but it was originally just... My only focus was the infrastructure we used to bill our users. And one of the calls I made was that if we found we billed the user incorrectly and we'd overbilled them, we would return the money.
If we had underbilled them, we'd let them keep it. Bank error in their favor, like it's our bad. If we had a contractual term we negotiated in the heat of battle three years earlier that had an ambiguous interpretation.
If the customer's interpretation was reasonable, we'd honor it, even if it was unfavorable or not what was intended, because that's on us to have a clear contract. And I had the full backing of the leadership team at Stripe to do that. We had very seasoned sales execs saying, I've never seen this.
I've never seen a company that returns money to their users if they've overbilled them. And I mean, I'd never seen it either because I'd never worked at another tech company and this seemed like the right thing to do given we wanted to be users first. And I think... A lot of the Stripe OGs would like to hear that. They'd like to hear that no other company does this because doing that sort of like really users first stuff creates all these good incentives.
So one thing I was trying to solve for was how do I create an incentive for us to get our pricing right and have high precision? Well, one of the ways is to make it really painful for us to be wrong by having this asymmetric response function.
But the backing of the company to be really users first like that is what's required to make that happen. Because you can imagine plenty of other places, but the finance team would just be like, sorry, product manager. That's how things work, dude. And that just never came up. So while we're on the topic of...
Patrick isms, you obviously spent a huge amount of time in the US. What do you think is like one difference on the downside that Australians have versus US, specifically looking at like operators here? Yeah. I mean, one thing that really jumped out at me when I kind of came back into the market here is the way startup people look for jobs in San Francisco is they ask everyone they know.
peers, VCs, who are the best founders, who are the best companies at the moment, either in general or in some specific space they're interested in. And then they just do whatever they can to get a job at that company.
So it's all about figuring out who they think is going to win, like who has an unfair chance at winning relative to their current chances of winning. And how do I get hired there? And, you know, I went from... you know, a leadership position and kind of an org of like a hundred or so people at Stripe to an IC role at Watershed.
and it built a team back up from there. But I was super happy to do it, took a substantial pay cut as well because I really believed in the opportunities that the company had and the chance of winning and I wanted to be part of it. We had a couple of people at Watershed join our BizOps team who'd been...
PM leaders at other brand name companies. They didn't just jump from leader to IC, they left PM because they wanted to get into the company. You see a lot of people going to somewhere like OpenAI in whatever role they can get into. And that's just like, it's in the bloodstream. That's what people are solving for. And I think the reason is everyone there gets that.
Getting into one of these fantastic companies early is just career rocket fuel and or financial rocket fuel. And what I observe in this market a little bit is I don't think people are not internalized how important the equity is. And you get the equity by getting your foot into the door.
good company and so therefore you see these sort of like doom loopy behaviors uh like oh well i had a two-year run where i managed two interns at a hot company i'm now targeting head-on roles and that's kind of doom loopy behavior because A lot of good companies are not going to interview. I spoke to a candidate this week who'd had a head of sales role at a company here. And I said, look, just to be candid, I actually didn't reach out. They came in to us. I was like, I'd seen your CV.
intentionally didn't reach out because i couldn't possibly give you a head of sales role you know based on the experience you have um it turns out they were kind of okay with it but um that pattern can be really um can be really actually destructive and the reason it's a doom loop is
If people care a lot about things like salary, title, visible career progression, then they don't care as much about equity. So they don't get offered as much equity. So they don't win as much when the company wins. So therefore, the companies don't offer equity. You get this loop.
where the thing that matters gets deprioritized consistently. And, you know, kind of a hot take, I think the best example of this is the number of incredibly talented people in Australia who go into chief of staff roles. Chief of staff roles seem really cool and prestigious. Because what you get to do is like hang out with the founders a lot. But what early stage companies need is people who own and do things, not people who do janitorial work for the founders, even if the title sounds good.
So actually, my spicy take would be most people looking for chief of staff roles in startups in Australia today should instead be looking for whatever operating role they can find. Go be a customer support rep. You're very smart and talented. You'll be the head of customer support in six months.
And then you'll be owning a P&L and leading a team. And this kind of this cheaper soft thing is like value destructive because the company is also worse off having one of their most talented people in a role that doesn't own anything. And so I think that's the kind of thing that you just see way less of you.
It's just not, small companies with cheaper staffs, just way less of a thing in SF. People taking steps down in title and role, way more of them. It literally feels like every single lawyer slash investment banker is like only gunning for a cheaper staff role here.
I've met some really talented people from top professional services firms as we were hiring. One of the things I've filtered on is, are they obsessed with getting into early-stage startups? Or is early-stage startups one of the things on the list of generically prestigious roles they're looking at?
And so you meet someone and I'm like, oh, what are you thinking of next? You've had a great run. You've become really highly recommended. And they're like, well, I might join a startup. I might do VC. I might do private equity. Or I might go in-house strategy. And I was like, yeah. Those are all really prestigious roles to go to from the things, for sure. But it kind of sounds like that's your main filter at the moment.
Whereas I'll meet other people who are like, yeah, I've been a wonderful person who's been at Bain for five years and just spent the whole time trying to hack ways at Bain to do startup stuff.
took a project with like a random utility company so that he could work in SF. And that's what you want. That's what you're really looking for. People who just want to get in and do the startup thing because of... what it means to join a great company and build a great thing not because you know you get this fancy title and get to read like the board deck before other people i think it's the shit about the board deck you had an epic hot take on shooter staffs what is another hot take on talent
One thing I think I learned firsthand that I've tried to implement at Loracool is I actually don't think most of the things you do that are aimed towards team building and morale improvement actually build teams or improve morale. I think they are. maybe sufficient conditions. They're definitely not necessary conditions. I think the things that builds morale is winning and the thing that builds strong teams is solving hard problems together.
And I've worked with a team earlier in my career that I kind of came into that had very low morale. There was a lot of discussion around, should we make sure all the engineers are only ever working on projects in pairs? Should we make sure that...
The pairs are junior and senior and both in the same office and not in different offices and should we change the Monday morning meeting agenda to be blah. And I was just looking at what was going on and I was like, I don't think this will move the needle at all.
We could choose whatever the optimal setting is on those things. I don't think it will make a difference. What we ended up doing was we got the team shipping by getting everyone out of their way, like stop inundating engineers with feedback every time they change a pixel. let them ship and let the customers give us feedback about what's actually good from that shipping.
We started winning because we were getting feedback and we were making a difference and we were getting praise. And then the morale improved. And that process of digging in and solving problems together bonded the team tightly. And so one of the ways that we've kind of done that at Larky, as I mentioned, like... We don't do an off-site where we go to Bali and sink piss. We went to the Southern Highlands and coded and then played board games and coded some more at night.
And we worked on interesting, ambitious stuff together, and it helped bring the team together. We just had our US-based team out in Australia for two and a half weeks. And one of the things I said to everyone at the start was, coffee chats, dinners, they're great. Actually, the best way to get to know each other is choose a hard problem that affects our users and go work on it together. And that will bond you. You can kind of walk around the block here in Surrey Hills. It's very pretty.
and fine, but actually just go solve some hard problems together to bond. And likewise, go get some wins together to build morale. And I think that's just so important. And again, I think sometimes if you're like a... a hr hammer you go try and hit all the hr nails and actually a lot of the stuff that makes things work well is actually just a strong team which is not to say
something silly like HR doesn't matter. One of our key operating principles is to be truly excellent to each other. That's non-negotiable. But beyond that, I don't think there's any number of board game nights that actually make up for winning together and solving hard problems together. I read that you're in the top 1% of Stripe's performance and potential. What did you get right at Stripe? I think I had a strange fit at Stripe relative to a lot of other people in that.
I ended up in this internal platform product infrastructure role that was very much about trying to serve customers, but intermediated a lot by sales and other product teams. If you think about the skills needed in that role, the internal consensus building, bringing everyone along, making sure everyone feels happy, I was really crappy at. Figuring out what we should do and charging unreasonably hard at it and being willing to put Moses out of joint along the way, I was spiky at.
And that was a spiky package in that role because it meant that I was just really, really, really trying to do what I thought was the right thing and willing to not have everyone be happy with it. And one of my rules in my PMO was that we are not... happiness maximizing we are correct outcome for the company maximizing and that's really important in a platform role because the easiest thing to do in a platform
is you have 10 requests from 10 orgs. You find a way to say yes to each org's top priority or one of each org's asks. Therefore, everyone got something from you this quarter. Therefore, everyone's happy. Usually that's totally wrong. You should actually be choosing one or two high leverage things for the company and saying no to most people.
And we just tried really hard to hold the line on that sort of thing. And I was lucky to have, you know, leaders kind of back me in doing that. And so I think it's probably just that, like, I just really, really tried to think about what was best for the company and shoot for it and sort of be willing to let the chips fall where they may.
And probably some of that comes from, honestly, you're a white dude in your 30s. People give you more credit than they should. And if you get fired, you'll get another job. At that point, I had an MBA. I had some fancy... companies on my resume, like I was going to be employable, I could afford to take risks. And also just like, I didn't want to live the other way. It just didn't seem fun to me. There was a funny story where I ended up leading this quite big project.
getting our infrastructure ready to go public. And the impetus was that when I was managing our billing and cost calculation teams, this request came down from finance, which was like, Patrick wants real-time gross margin. And I was like... okay why i was like well patrick wants it he wants gross margin in real time and i was like yeah like what what would he do differently when he has that compared to the data he has available today like we'll have it in real time and i was like okay i'm not
spending more time on this until someone explains to me why, or I go sit down with Patrick and hear it from him. because that's a waste of time and I don't think it will actually be that useful relative to what we're doing today. And that sort of frictiony colleague that try to do the right thing, I think organizations try and reward.
Are you good at sales? No. I have seen people who are good at sales. The first AE at Watershed, at one point, he had personally closed a third of our revenue when we were deep into the eight figures of revenue. It's an imbalanced sales productivity org. No, I mean, the other sellers were also productive. This guy is just an incredible outlier, but really incredible seller. He'd been President Obama's envoy to the Libyan civil war.
Literally, he'd worked on Middle Eastern Peace and then he came and tried software. He could sell. He could sell. When I try and benchmark myself, I think there's a lot of sales hygiene I do really poorly. I wish I was better at tracking the follow-ups. I wish I had really crisp emails out. I wish I was nurturing prospects. What I can do is talk about the product and talk about the space.
kind of covers it. But I think the conventional read that I think I fall into is found as a pretty bad at qualifying, pretty bad at deal management, pretty bad at closing, but very good at middling, like good at the demo and the trust building. And that's basically where I am. Interesting.
Share what the go-to-market started as and what it has evolved to. The motion has been pretty similar, which is sales-led. When you're installing a piece of software that goes across the whole company and talks to your users. there's always going to be some matter of evaluation, discussion, etc. So it lends itself to being sales-led. It also has, it touches a lot of customer data, there's security, so it's going to be a sales-led version.
We've tweaked exactly what the cycle is, but it's relatively simple. You qualify, you do a bit of a demo, you go and do some kind of proof of concept or pilot, you hopefully move forward into production. The sales and lead generation function is me in the last 2 months.
I've had a couple of people from the BizOps team starting to help with bits and pieces of it just to get a little bit more leverage. We're about to kind of start growing the go-to-market org, but it's been pretty lean. I kind of got a bit of a leg up.
working with quite a good kind of sales coaching organization who specialize in kind of helping technical founders learn how to sell. That's probably where I learned I wasn't good because I've been involved into it. Well, I'd like been involved in doing a lot of...
I've been involved in doing a lot of demos when I was at Watershed. The sales team loved pulling me in and were really nice to me. And I was like, oh no, guys, I think it's my job. I'm happy to come and talk about the product. I like talking to users. And off the back of that, I was like, yeah, I'm not bad. The sales team always patting me on the back.
And I think these coaches helped set me right. I probably came in thinking I was a 6 out of 10. I think I was a 2 out of 10. They probably helped me get back up to 6. But, you know, it's been kind of... it's been kind of okay. And now I'm actually quite excited about bringing in some of the priorities because as you get into bigger opportunities with big companies, just the ability to manage the process really well.
The project management, the multi-threading is really important. And I'm still keen to stay super involved in talking to the market because I learn a lot. It helps us build a better product. I like talking to it. customers, but having some help to really structure the thing is going to be critical and probably help us perform way better than we currently are. At the beginning, you said we didn't have the right to win those deals and we did.
I'm sensing a huge level of humbleness, but I'm curious whether that was actually true or not. A friend of mine is in a product leadership role at a publicly traded company in the US.
She got me a demo with someone who was like three rungs down the reporting chain from her. We did the demo and I heard through the back channel that they were like, oh, this is actually better than... what we've just seen from this company with a celebrity ceo that's raised hundreds of millions of dollars from you know a top tier vc let's get them a demo with like the internal head of ai so we did the demo with the internal head of ai heard the back channel came out like that's
That's better than what we saw from such and such. So then we got a demo with the CTO and did the same thing. And he kind of shook a hand in the room and said, let's go to a pilot together. And I made a joke like, well, I guess one thing we've got going for us is, you know.
Celebrity CEO's company, you're probably dealing with some account executive and at least like Jamie and I are here. And they were like, no, no, no. Celebrity CEO is running this deal. He's mates with our CEO. And I was like, okay. Really surprised me having these issues. Yeah, that's what I mean, like, don't deserve to win. Like, I mean, it's like, sure, like the product performed and we kind of fought our way through, but like...
As I said, I'm not very good at sales. I know who this guy is. He was kind of famous. He was the CEO of a company with sales in their name. So that's the sort of thing where I'm like, we don't deserve it. that deal on the totality of everything. And obviously, they've been good partners in being clear about some of the reservations.
You're a bunch of random people who've raised very little money in Australia. Are you viable? And, you know, we've worked and brought on great partners like Blackbird to kind of address that sort of thing. The other observation that I made from your highs and lows was that all of them were customer orientated. Have you always been customer obsessed? No, it's probably actually a no zealot like a convert. And what I mean is, at age 31, I had my first real job in tech.
And I'd previously been doing currency research and trading at a hedge fund. So did I know about what you focus on? And just got very lucky that I worked with this wonderful PM at Stripe, who I think was employee number 30 or something.
and just ham it into me it's like just just only focus on the user if you just really that's the thing you just keep coming back to um everything will sort itself out just like really focus on them like talk to them come down come down in mexico city and like spend a week talking people come to south power and talk to people really get inside their mind and understand them really deeply.
And that's a little bit that kind of knows a lot like a convo. Like I just, I had to learn it intentionally. And so therefore I kind of built the grooves for that just to be the focus. And then there are disciplining functions. Like I don't think I noticed that when you asked that question, but I know definitely in the past I've had. No, it was subconscious.
It's just what came out. Yeah, but it's subconscious because I think I know at times I have had conscious mental cues, like talk about the customer, answer in terms of the customer. And so you can kind of train yourself into it. And that's what I mean by kind of nose out like a convert. Do you love speaking to customers?
I didn't know this about myself until I went to business school and did a bunch of like bullshit psychometric tests, but I'm actually like, I'm actually very introverted. And when I mean, I didn't know this, I'd like, when I was at uni, I would like. go to a party and then spend like two days in my room watching tv like not realize why and it turns out because like i just like completely depleted myself
When I learned what that was, things kind of clicked. And so the reason I say that is like, I'm not someone who gets a lot of energy from being with a lot of people, but I get a ton of energy from talking to customers because it has always felt from the first time I did it. That's right. Like this immense privilege for people to be like giving you their time to talk about their problems and kind of put some faith in your ability to solve them. And it's like the most interesting puzzle because.
you're solving really understanding like a business problem and understanding like a people and social problem and then trying to map that into technical capabilities and solutions. And I think it's a very energizing and interesting thing. So I just love it. If I look at my calendar and I know I have a bunch of calls, sales calls or customer calls, it's going to be pretty good, even if I retire at the end of the day.
And that's kind of different to all the other people that you kind of speak to when you're doing this kind of thing. Well, as an interesting exercise, would you be open to at a high level opening your calendar and sharing an overview of how your week went? I start my day about half past five. That gives me overlap with U.S. East Coast and West Coast. So I had a 5.30, 5.45-ish meeting every day this week. 6.30 to 8, I get my kids off to school.
My wife also works a lot on the U.S. time zone. And then back-to-back for the rest of the days, I'm actually doing some calendar analysis this week to get on top of it. The biggest category was calls for current customers. The second biggest category was sales calls. And then a handful of recruiting calls because we're doing a lot of that at the moment.
go to the gym and lift weights to the personal trainer kind of three days a week at about midday for about two hours. So to have this like weird early start, take a chunk out of the day to like reset and exercise. And then those days I try and walk my afternoon.
So that this is one of the things I found. It's by blocking my calendar and not allowing any meetings. I actually have more time for the team because I can have ad hoc conversations with people. They can come up to me. We can go grab coffee. And then if instead I let the meetings fill up, you sort of end up with like your whole day. sort of pre-dictated before it starts and that loses a lot of flexibility then you know try and be home
A bit before six, have dinner, bath, bed with the kids. And then we usually have another round of calls between eight and nine with Europe kind of before I go to bed. And a couple of days this week, I have those. Sometimes I get lucky and I don't. And I just use that to kind of clear out the inbox.
I'm kind of lucky as a founder to be able to just control my schedule. So I have this like quite strange schedule, like chunk out of the day to go work out, but also start quite early, chunk out of the day to do the dinner bath bed thing and then work a little bit late. And then, you know.
depending on the circumstances just with what's happening with our kids, we'll pick up a bit of work on the weekend when I get a chance to. You say I'm quite lucky that I get to start my calendar. I think a lot of founders are more reactive than proactive on their calendar scheduling. I mean, it feels very reactive. I lucked on to something recently with this, like...
blocking out after midday. It started one day a week, then two, now up to three. I'd love actually to get it to every day. In some ways, it's letting me be reactive, but it's reactive to what matters, if that makes sense.
the other thing the other kind of just very tactical hack that i've got good mileage out of is i have um actually a bunch of different meeting links with different customized availability and they're all saved as snippets in superhuman and so you know for instance sales meetings
max availability you know if i send you that link it's or if you go to our website and book a demo you know you can book me at 5 30 in the morning um we actually had a sales prospect we visited within our customer visitors in the office yesterday and he was like yeah when i booked the initial demo I saw that the link had times at 5.30 and 10 p.m. And I was like, oh, great. I'm going to be talking to the founder. So there's that link. And then there are other ones where like...
someone wants advice on something or there's like some way I can kind of pay it forward. Like I want to make time for that. But like actually now I have about three hours a week for that available.
um you can book up to five weeks in advance if there's not a slot anytime soon i mean if someone wants to push back i could accommodate them but just generally those ones will like naturally sort of bottleneck themselves out so having that range of booking links is actually um actually like i think a bit of a secret to manage the calendar because that way you can sort of politely give people different levels of priority by what link you send them like maybe it would be worthwhile sharing
Where AI is at in, you used the words precision earlier, and the relationship between the market of AI that's moving underneath you as a tailwind. and how your product strengthens as a result. So one of the observations we've made about the direction in which the capabilities are evolving, I've actually seen one of our competitors make as well on LinkedIn, which is...
It's developing a lot in its ability to reason from first principles. And actually in an operational context or a support context, you don't necessarily want that. Like put aside AI, if you had an incredibly intelligent support agent. And the way they solved each ticket was to reason from first principles about how they should solve the ticket. You would kind of tap them on the shoulder and be like, okay, but like, can we just write down what the order policy is?
and then do it the same way every time. And even if they're reasoning and first principles from the returns policy or from the order policy, you would still be like, okay, but why don't we try and get consistent execution? And by the way, with your super intelligence, if you think of a better way of doing it... Let's propagate that. Let's not have a better way to be emergent. Let's improve the process overall.
And so actually what we need is a lot of instruction following. So like once we've given the system instructions, we want it to follow them very well. Our architecture lets us achieve more of that than a lot of other folks. And then the place where we can use improved reasoning is actually around improving training.
system. So we do a lot of work to be able to take our customers' existing policy docs and turn them into a format that LLMs can act on more effectively and better reasoning models help us do that. So we can definitely benefit from that. The cost of inference continuing to fall is an ongoing benefit to us.
But a lot of the developments in intelligence are slightly orthogonal to us. So they've got much better at being a research assistant. I don't know they've actually got that much better at being a support agent. Sort of a random one. Where do you get the 10 times better than the status quo thinking when you're constantly...
reacting to customer feedback and making your current customers successful? One of the things I've continually emphasized to the team, and we actually went away to the Southern Highlands in August to do...
to a hack week. I don't believe in offsites. We can do whatever team building. We just go build some cool shit together. The push there was, what are the opportunities to do something radically better that is in the direction of the feedback we're getting from our customers? Because you know your customers... Unless you happen to have a suite of customers who are also product visionaries in your area, your customers are not going to give you necessarily...
or it's not going to consistently give you groundbreaking ideas. They'll give you very good feedback about whether you're on the right track and whether things are working, and they'll tell you a lot about their problems. Customers know their own problems very well. So you can listen to what they're asking for. And when you have quick wins, go get them. But you also want to step back and be like, what is a lot better? To give you an example, we're talking at the moment about...
How do we tighten up that testing and backtesting story so that you can make a change to configuration and really quickly get an answer about whether it's better? No customer so far has said to us, the way you should solve this is by having other agents that simulate being a customer and run thousands of conversations in the background to give you a result. I think that's a pretty promising area for us to go do some R&D. No customer's had that idea.
The problem they're trying to solve is very consistent with that solution. And so actually just intentionally pulling up and saying, where's the opportunity to spend a bit longer to do something that could be radically better is worth it. And then obviously you need to be able to spike those radically better ideas.
fast enough to validate if they're going to work not go chase them as sort of white elephants um but i think that's it is like really intentionally being like where can we jump ahead of what we're hearing from the customers what are some hot takes in ai or
those that relate especially to customer support. Our hottest take, and it's hot because it's costless deals, is that co-piloting is not a good solution for customer support AI. When you're... doing something that's like extremely cognitively taxing and you want some sort of like partnership to move things forward that you can closely review which is like writing code copilots are great i use code and copilots all the time i have no um
in principle, rejection to copilots. In the support sense, I actually don't think they stack up.
the support system is a good copilot, it should also be a good autopilot. If the draft responses it's suggesting to the human agents are good, the human agents should be able to use them and send them, at which point, why have the human agent in the loop? If the copilot is not good, I actually think it is a worse outcome than nothing because making the human agents play spot the error from LLMs who confidently hallucinate is like, it's like dystopian as a job.
My job is to try not to get tricked by the AI my company makes me use because it's now my job to fact check this system. But by the way, when the company rolled it out, they thought it would make me 30% more efficient. So I now have to go 30% faster while reading a whole extra message for support ticket and trying to spot where it was wrong.
It's horrific. I think the reason it has traction in the market is people are scared of AI. Every single sales conversation I've ever had, when we talk about implementation, they ask, can we do a copilot solution?
and um so far we've had almost no one ever go live we can do it we've had almost no one ever go live with it because we just do testing beforehand and i say to them i'm like yeah You can co-pilot this on 1,000 tickets over the next week and then painstakingly go and see whether your human agents use the suggested responses, or we can use our testing for it to run 1,000 tickets today.
and then sit down with you and go through the results and get to the same conclusion much faster and without kind of traumatizing agents. So that's the hottest take we have because some people have been very offended by me saying this to them because they've come in really dead set on a co-pilot.
being upfront about what i think of it um but i kind of think we're right and i think we're better off shooting for the horizon that we're going to get to because this like cognitive dissonance will shake out and i don't think the copilot thing is a stable equilibrium that's a really interesting one I'll give you one other AI hot take. A lot of the discussion about, hey, if it's easier to build software, now distribution matters more, I think is like hopium.
from people who don't build stuff. And I think the hard part of building software continues to be figuring out the right problem to solve and figuring out a cool way to solve it, not writing the code. It has been pretty easy to ship. prototypes to get validation for some time it's maybe a little bit easier now i don't think the main constraint has been the shipping the constraint has been the ideas and um this like only distribution that is now thing i just like
has never really resonated to me. When you get down to the nitty-gritty of actually building products, it feels like, no, no, actually, products make a pretty big difference. And that's not to say distribution doesn't matter. I think it's more that distribution has always mattered an incredible amount.
I'm not sure that that has changed with better kind of AI coding tools. Why is it a hopium, which is the first time I've heard that word? Well, because if you're someone, as I was at one point, who can't build software... You have two options in your life, learn or compensate in some other way. And I think there's a lot of people who for a variety of reasons who got scared out of learning. And so they would really hope for it to be true that it no longer matters.
whether you can build software because that would be great for the choices they've made um and would make them feel a lot better it's kind of telling to me that like no one who builds software is a big proponent of the idea that like ability to build software doesn't matter anymore and it's all about distribution like the people you hear it from tend to be people who like don't build software um and that's why i think of it as sort of okay okay i dig it man thank you so much for your time
That was incredible. Thanks for having me. I enjoyed it and hopefully had some interesting takes or something at least that will be useful to other people. Absolutely. There is heaps. Thank you so much for joining us on this latest episode of Wild Hearts. If you want to learn from other ambitious people that are building, designing and creating the world that we want to live in, then please hit the follow or subscribe button.
it would mean the world to us here on the Wild Hearts team. We have an insane producer, Melia Rayner. an incredible editor, Annie Jones from Welcome to Day One. And our marketing and content support is provided by Jonathan Blakely. And we couldn't do it without them. If you're searching for investment, please, my DMs are open. Find me on LinkedIn. I'd love to help. And so with that, we'll see you next week, Wild Hearts.