Uncapped with Jack Altman
· Jack Altman, Bret Taylor
[00:00:00] S0: It’s interesting that you’re obviously having to be the best at something that you know is going to get commoditized. I don’t know if you ever had to experience something like that. For that to be true, you just have to be in the middle of an insane rate of change. But that means you have teams who are putting a lot of their life force for two years into something that everybody knows is just for two years. But it still matters nonetheless. [00:00:00] S1: It’s crazy. If you look at traditional enterprise software—consumer’s a little different—you think about building up this asset, your intellectual property. There’s a fancy name for it. “Look at this platform that we’re building. It took so many years to build it. It’s got all these features. Now you’re like, “I’m building this and I’m a hundred percent certain we’ll throw it away in the next 48 months.” [00:00:00] S0: It’s a sand castle.
· Jack Altman, Bret Taylor
[00:00:00] S0: It’s a sand castle. [00:00:00] S1: But I have to build it because if I don’t, I can’t serve the bank that has a big business in Hong Kong, or whatever it might be, where they need Cantonese support. That is the reality right now. I’ve been thinking a lot about this. I think it was Tobi Lütke who said something provocative. When generating the code is easy, it’s almost like the system and the prompts are actually the durable asset. Put it another way: could you terraform your software from scratch? It’s the prompts that led to it. I do think that is the software of the future in a lot of ways. How do you encode the infinite number of little product decisions that you made? So much of that is encoded in code today. If you think about a product requirements document versus the code, what percentage of the emergent product is encoded in the code? Almost 90%. A lot of the little details are in there. Software companies of the future and the products that they make are just going to take a really different shape. I’m so excited to be a part of it. I think it’s really fascinating. There’s something really interesting about AI impacting the software engineering industry almost first and most. We’re disrupting the craft of making what we’re building in real time. It’s a fascinating time. [00:00:00] S0: There’s a prevailing idea in tech that AI is moving so fast that young founders have this massive advantage. I mean this with no offense, you’re not old, but you’re also not young. [00:00:00] S1: You’re telling me I’m old. I get it.
· Bret Taylor, Jack Altman
[00:00:00] S1: You’re telling me I’m old. I get it. [00:00:00] S0: No, but you’re not the youngest founder and you have one of the most successful AI startups. It does seem like you’ve brought a lot of your previous experiences to what you’re doing, but I can tell from talking to you that you’re also just rethinking everything. I’m curious about your own experience, for yourself and for other founders. Do you think by and large young founders have the advantage? What does it take for more experienced founders to have the advantage?
· Bret Taylor
[00:00:00] S1: I’m always a big believer… I don’t know if it’s a real quote, but some venture capitalist said, “Why was this founder able to conquer this market where so many others had failed?” And they said, “He was too naive to know it couldn’t be done.” There’s a certain element of that I love because you end up with this kind of naivete that is actually a form of principled first-principles thinking. A lot of young founders have that. You just don’t know why this messy, bad product dominates the market. You think there’s a better, faster, cheaper way to do it. You don’t have any of the hard-won lessons that can end up as oversimplified analogies keeping you from actually taking that leap. Tony made DoorDash and didn’t care about Webvan’s failure or Kozmo or whatever it was called. I can’t remember all the dot-com bubble companies. But I do think, especially in enterprise software, the experience that some of our team members bring—including the old men, me and Clay—really does matter. Part of the reason we’re able to serve so much of the Fortune 100 is we can go into a bank or a healthcare payer or healthcare provider, or a revenue cycle management firm, or a big telecommunications company, and understand their business. We’re working with one large medical device company consolidating 40 of their call centers into one, and we can have a discussion about the change management of doing that. That’s not really a tech problem, but it does require understanding business. We always joke at Sierra that there’s a Venn diagram. There’s a circle of people who understand the next generation of AI and a circle of people who understand business, and we’re the company right in the middle of that, and maybe the only one. That matters. You know that infamous MIT study saying all these AI projects fail? None of ours do. That’s our value proposition. We can actually help you go live. I think the experience has benefited us.
· Jack Altman
[00:00:00] S0: I’m curious if you can point to what has created the lead you have so far. Obviously I know you’re just getting started, but at the moment you have pulled away in a big way. I’m sure there’s a lot of daily blocking and tackling. But I’m curious if there are any foundational decisions or strategic approaches that over the last couple years you look back at and think, “That was pretty essential to make this happen.”
· Bret Taylor
[00:00:00] S1: There’s two almost independent areas of investment. They’re not independent, but they’re very different. One is the product and one is our go-to-market and partnership model. They’re both really intentionally built. On the product side, we’ve tried to balance ease of use and extensibility. When you serve really large companies that have been around for 200 years, you need to work with mainframes, you need to work with a thousand different systems. You’ve done 10 acquisitions. Enterprises are messy. That’s why most enterprise software designed for larger companies tends to be quite extensible. Often that extensibility comes at a cost, which is: is it easy to get up and running? As a product designer, one of the things I’ve spent a lot of time thinking about is: we’re trying to have our cake and eat it too. Can you go live in two months and still be maximally extensible? I’m really proud of the product that we built. Some of that is born from experience of what extensibility means. We have an opinionated view of what it means and have been able to accommodate some fairly exotic deployment requests and still do it fast. That’s really unique. The second thing is our go-to-market and partnership model. We knew when we started the company that we wanted to work with the largest companies in the world. Not only, but we wanted to be able to work with the largest companies in the world and we’ve focused on that. As a consequence, we have a really unique partnership model. There’s a fashionable thing to talk about: forward-deployed engineering in Silicon Valley. We don’t call it that, and it’s a very unique model because it’s not all about technology. Most of our clients build and maintain their agents themselves. It’s pretty easy to do. But we show up and we help you be successful. We’ll just show up. We’re not going to let you fail. I think that is very different. Because we have this outcomes-based pricing model, we don’t get paid unless it works.