Invest Like the Best with Patrick O'Shaughnessy
· Shyam Sankar
[00:00:00] S1: We could start by maybe thinking about my critique of the conventional software industrial complex, which is that you're sitting, let's just say in Palo Alto and you're building this piece of software and your essential feedback loop on "Is this software valuable" is, "Can I sell it?" And if someone's willing to pay for it, it must be valuable. That's an okay feedback loop. There's a stronger feedback loop, which is "Is the software valuable? Did it deliver the outcome?" The only way you can assess that is actually in the field with the end user, on the factory floor, in the foxhole. So in our case, it wasn't gonna be enough. You have this weird division between the IT buyer and the operator. The validation is going to come from the operator. The idea was really almost to build software through backpropagation. Hey, how do you go to the person who has the problem? You're showing up with your best thesis of what you've built in the metaphorical Palo Alto, but then you are not just sending a sales engineer out there whose job is to try to ring up the sale. You're sending someone out there who is obsessed with whether it's going to generate an impact in the world or not, and is willing to continuously solve backward and is technical enough to understand the full stack. How would we take the specific and learn how to generalize it over time, in terms of the product? One way of thinking about this is, there really are two types of engineers. There are people who know how to build the right thing, and there are people who know how to build it the right way. And their dopamine hits come out of different things. The people who know how to build the right thing, they're more like MacGyver. Their high in life is, "I solved the problem." In their minds, solving the right problem is 80% of the work. On the other end, you have engineers who are more like artists in the traditional sense. "Don't you see how beautiful the thing I built is?" The architectural elegance, the scalability of it, that's what gives them the high. Nevermind that it doesn't solve a problem anyone cares about. It's art on its own. It should be appreciated. And I think about this like vector math. So the forward deployed engineers skew towards this hacker mentality. The product engineers skew towards this artist mentality.
· 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.