Invest Like the Best with Patrick O'Shaughnessy
· 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.
· Shyam Sankar
[00:00:00] S1: Two things I just want to put down that will make this make more sense. The first is that we want to make software that makes you more different, not more similar. We think about it as alpha, not beta. The second thing is that we are a wildly inductive company. We would never show up to a customer with some preconceived notion of – this is the aerospace ontology. I'm gonna pick an aerospace example in a second here. It's rather all the values and understanding what makes your aerospace company different than all the others. How do I make you more different there? That's the differentiation you're competing on. When we first came to Airbus, Airbus was in the midst of ramping the A350. The A380 was a wonderful plane, structurally unprofitable program. So the A350 was this bet that the whole company was effectively riding on in 2015. The first time you make an airplane, you're always going to have issues. There's a learning curve to the production. And one of the most important things to figure out as quickly as possible is, what is an issue that is just a nonconformity, like "Hey, I'll give this guy some training and he'll learn how to figure it out. It's teething pain, it'll go away." And what is a recurring issue that is actually a design defect that I need to go work with my suppliers, or upstream? How quickly you can solve that becomes fundamental to the shape of the ramp and the cost of the ramp. The first thing we did is we just started sitting with users on the final assembly line in Toulouse. These are wrench turners effectively. And understanding, hey, what makes your life suck? What's hard about this? What's the challenge in working on these nonconformities? Basically, they're going through Excel. They're looking at reports in SAP, trying to figure out, how do I bucket all of these issues that are coming in? So we just helped them automate all of that. And the ontology at that point was really related to parts, sequencing of work, defect rates, everything related to quality. Once you had this immense quality asset though, you were able to pivot it to realize, okay, now I'm up the learning curve. It naturally leads to the next problem, which is production planning. So quality to production planning to then in service. Now you have the greatest data asset possible for this tail.
· Shyam Sankar, Patrick O'Shaughnessy
As this plane enters service, how do I help maximize the uptime of this asset for my customers? How am I gonna compete against the other aerospace manufacturer? That's the natural evolution that we see with most customers. You start with one problem, but of course they exist in the context of this connected decision chain. [00:00:00] S0: What's the difference between dealing with military customers and government customers, which you did for a long time, and commercial customers?