Invest Like the Best with Patrick O'Shaughnessy
· Shyam Sankar
And you have an unstable equilibrium where you're trying to align these vectors in a way that you're gonna go upwind. If either side dominates, you don't really have a business. And that's why that seam between them, you actually need a dictator-like figure to manage and decide. And many of the outcomes, particularly – I think this model is super valuable when you think about your customers as existing of some sort of power law in terms of how useful the next marketing thing they're gonna be asking for is in terms of the overall development of the product. If it's a Gaussian, you should just survey all your customers and average it out and figure out what to build. That's like a traditional product development process. If on the other hand, you think some percentage of my customers are living in the future. Yes, only they or only a handful of people have this problem today, but I can assess that this is actually a really valuable thing to solve that no one else has solved. We should solve it now and effectively have a monopoly on the capability to do that. We'll be five years ahead of everyone else if we lean into this problem. You can only surface that in this sort of forward deployed engineering way. The other thing about forward deployed engineers that's worth saying, in the Thielian sense, is the importance of secrets. Peter talks about the importance of secrets. If you're gonna do something really impactful, there has to be something true about the world that you believe other people disagree with you on. Warp Speed is born out of one of those secrets. For the better part of 15 years, our software has been used to make things in the world. The one thing you could not tell anyone before COVID is that their manufacturing software doesn't work. People would point at their ERP system and be like, "Look how great it is. I spent $5 billion, $10 billion doing it." But as a forward deployed engineer, when I would go to the final assembly line on the factory floor, everyone's using Excel. There's a contradiction here that no one is somehow forced to reconcile with, which is really what they're saying is this software is so ill fit for what I'm trying to do, I hit the eject button, I pull the data out to Excel and I'm like hand rolling my own solution. That should be an obvious sign that something's not working.
· Patrick O'Shaughnessy
[00:00:00] S0: What are the limitations of it, in the sense of if you have X Y or Z, you shouldn't try this model or you need this to try this model. One thought would be the product needs to be expensive because it sounds like an expensive process to deploy people on site, highly trained, expensive people and so on. So you need to be selling a very expensive product. But if you were giving advice about use or don't use this concept of forward deployed engineering in your software business, how would you frame it up to other entrepreneurs?
· Shyam Sankar
[00:00:00] S1: I would say this, you have to believe that you're gonna be able to capture meaningful value for the problems you're solving. So your problems you're solving are really big and therefore imply there's a lot of value behind them. And if you can solve them in a deep way, you'll be able to capture that. A lot of the problems we're solving, like to get at bat, you weren't gonna get paid a lot up front. You're actually gonna invest a huge amount into the customer to go do that. But you would do that because you believe that actually in the end, we'll be able to capture the value, a portion of the value we're creating. Our economics will be downstream of our customers' economics. The other part is that your ambition extends beyond a linear box. We always struggled when we came into the commercial world where you had the Gartners of the world and they have this sort of box. This is my enterprise architecture. I've broken it up into all these boxes. What box do you fit in? The answer for us is, well, we don't fit in any box. We fit in all the boxes. It's some sort of heterodox thing. You're solving for all the problems in the seams. Like, you're basically solving for the fact – that architecture diagram was made by some mid-level product marketing manager. It's never been used or validated in anger. It's never actually solved a problem in the real world, but the cargo cult of the IT buyer just keeps believing they should buy it. I think if you fit into that, doing forward deployment engineering would be crazy. Why would you do that? But if you're like us and you don't fit into it, you need some way of just scraping and clawing, to deliver enough value that the institution has to confront. But even though it's heterodox, even though it's heresy to my enterprise architecture, it works.
· Patrick O'Shaughnessy
[00:00:00] S0: It probably took until I read Jeremy's profile of you and of Palantir that I really understood how Gotham and Foundry, and the product and the business worked. It's interesting how Palantir is somewhat inaccessible from the outside, unless you read a fairly detailed description of what is literally going on in the product. And I think the early years of Palantir were especially exploratory, trying to figure all this out with all your efforts with Alex and the team. Could you just explain what Palantir is? It's such a basic, stupid question. But again, until I read a detailed account, I actually probably couldn't have done so. And so I'd really be curious how you like to frame it or explain it.
· Shyam Sankar
[00:00:00] S1: This is actually the hardest question in the world for me. We have built an enterprise operating system where our core thesis is what makes this stuff really valuable is decisions, not data. It goes to John Boyd's OODA loop. What we're really providing is an operating system that allows you to bring all of your enterprise data together. It solves for the impedance mismatch between – look, all this data I've collected, it was collected and stored in a way that makes sense to the underlying transactional system or makes sense to some part of my institution, but doesn't actually represent how the humans of my institution think about the problems that we're facing. So that we represent in what we call the ontology, which is not just a model of the data, it's also a model of the actions. We call that the kinetics. If you're going to make a decision, you might be allocating inventory. How do you do that? So this ontology layer almost becomes like an API layer for the business. It makes the business programmable. And that changes the rate at which you can compound on top of it. So now you have this abstraction layer that you can use to build applications that manage your value chain, from the hand of your supplier to the hand of your customer. You can call it a value chain. You can also call that a decision chain. Your whole business almost – if you just squint at it, it's just a series of decisions you're making. Every one of those decisions, you want to have an OODA loop. I want to make the best possible decision I can have today. More importantly, I want the first derivative to be good. I want to learn tomorrow how to make a better decision than the one I had today.
· Patrick O'Shaughnessy
[00:00:00] S0: Can you give an example of a customer where you showed up, and maybe describe the circumstance of their data or their systems or something. Then what you did, what the process is of establishing and building the ontology, which is I think a very good, appropriate, but fancy word for mapping reality onto a system versus jamming reality into a preexisting system. And then what sort of transformation that enabled at that customer that would have been impossible with the former system? Just bring it to life with like a simple example.