Selling the Outcome
Not a product, not a service — the thing in between. You loan the customer engineers who learn their business and build them a working solution on your platform. What the customer buys is neither software nor someone's time. It's the outcome — which is only sold once it has a baseline, an agreed number, and the four months of earning trust that the build does not cover.
Imagine pitching Foundry honestly: "We've centralized your data and made proper nouns out of it — instead of table one, table two, table three, you have one source of truth for warehouses." Any industry leader would give the same answer: cool — what does that do for my actual business? If you're selling just technology, that's where the pitch falls short. And if you're selling just services, nothing compounds. Palantir's answer was to stop choosing.
Neither product nor service
In the FDE model, the customer is not buying a piece of software, and they are not buying someone's time. They're buying the outcome. You send really smart people who go understand the nature of the customer's business, build them a solution on top of your platform, and what the customer gets — the thing they actually signed for — is the result.
The lens matters because of what the buyer cares about. A leader in consumer packaged goods cares about placement on shelves and sales throughput. They don't care how the data is organized — and nor should they. That's an implementation detail. Selling the outcome aligns the contract with the only layer of the stack the buyer can evaluate.
A design partnership, scaled up
Early-stage startups already know this motion by another name. When you don't know what your product is and your customers don't know what they're buying, you run a design partnership: work closely, learn the problem, spend your own time and technology, hand over a really good solution. That's how most B2B startups find product-market fit — and then they graduate out of it.
Palantir's core assertion was: who said design partnerships were only for the beginning? Why not run that motion at enterprise scale, permanently, as the go-to-market itself?
What the word has to mean before it can be sold
"Outcome" is the easiest word in this pillar to say and the easiest to fake. Pauline Brunet, who leads forward deployed engineering globally at Cursor, states the test as a single sentence a customer has to be able to answer before the work starts: "If I automate this process from start to finish and it now takes 20 minutes instead of 3 hours, which is current baseline, is that sufficient for you?"
Three things are load-bearing in that sentence, and only the first is obvious.
- A baseline. Three hours is a measured present state, not a feeling about one. Without it the closing report has nothing to subtract from.
- A number the customer accepts in advance. Twenty minutes is agreed before anyone builds, which converts the end of the engagement from a negotiation into an arithmetic check.
- A named process. Not a department, not a capability — one workflow with a start and a finish.
Her closing move is the same sentence run backwards: "Did we get close? If not, why not? What can we do about it?" An outcome sale is the only kind of sale where the vendor volunteers the measurement that could embarrass them.
Scope stays directional, on purpose
The obvious way to protect an outcome contract is to specify it exhaustively. Brunet does the opposite, and the reason is an honest admission about what a vendor knows on day one: "I do not know the customer processes. I haven't really seen their data. I haven't seen their systems… and so I'm a little bit on the hook if it takes more than 6 weeks or less."
So the commitment is phased and directional — phase one and two, six weeks, these agents, these KPIs — rather than a fixed list of deliverables. The second reason is the better one: "we're going to learn a lot, and they're going to maybe want to pivot once we learn something." A specification tight enough to be safe is also tight enough to force delivery of the thing you agreed to before either party understood the problem.
The counterweight to loose scope is participation. Her rule is that the customer is in every step — scoping, designing, building, human-in-the-loop validation, reading the baseline against the result, and owning the ROI number at the end. Stated as a failure mode: "if you're doing it alone in their office in a little cubicle, we have a problem."
Three levers, and only three
Two practitioners at unrelated companies, in talks four months apart, reduce every enterprise outcome to the same short list. Brunet: "Am I increasing revenue? Am I decreasing costs? Or am I mitigating risks? That's it. Every company, as complex as they are, that's what they care about." Vasuman Moza, whose firm runs department-wide agent deployments, closes on the identical triple — revenue uplift, cost savings, risk mitigation.
The convergence is worth more than either statement alone, and it is useful in a specific way: it is a completeness check on a proposed engagement. A project that cannot be pinned to at least one of the three is not badly measured, it is unbought.
Brunet was told an agent was costing a customer $2,000 a day. She asked what it was doing: choosing which engineer to send out to fix broken equipment. "Hey, that sounds like you're actually reducing costs to send the right person to go fix this equipment. Would that not be worth $2,000 a day?" — "Absolutely, but I never measured it this way."
Nothing about the deployment changed. The cost was real, the value was real and already being delivered, and the only broken part was that one had a number attached and the other did not. An outcome that nobody framed reads at renewal as a bill.
Delivery is not the same as staying
If the outcome is the product, when is it delivered? Colin Jarvis, who leads forward deployed engineering at OpenAI, answers from the other side of the contract, and the answer is earlier than the sales framing suggests: "we see our FDE team very much as like a zero to one team. Like we're going to come in, break the back of the like difficult novel problems that are at the root of what you want to do, but then we want to move on."
What the customer keeps is deliberately two things, not one. There is the software and its demonstrable ROI. And there is the method — "you orchestrate whatever your end-to-end workflow is. You wrap evals around it. You put guardrails to protect the things you can't really control that are going to happen at runtime. And then you basically just build up an eval set and then test the consistency of this application and you learn how to like make applications you can trust."
That second handover is the one that decides whether the engagement ends. Handing over a working system creates a dependency; handing over the practice that produced it does not.
The gap between working and trusted
Jarvis's first enterprise deployment is the clearest available picture of what an outcome costs beyond the build. Morgan Stanley wanted its wealth-management research in the hands of every advisor — "they don't do like a kind of edge case like over to the side of the company. They pick something with genuinely high stakes."
The engineering was fast. "Probably like within 6 to 8 weeks we had the pipeline. We had some guardrails. We had the retrieval, we tuned the search enough that we were getting decent results." Then: "it took a further like 4 months of like doing pilots, collecting evals, and iterating to get to the point where the advisors actually trusted it to kind of put it in to like actually use it in anger." The reported end state is about 98% advisor adoption and a threefold increase in how much the research got used.
Read the ratio rather than the totals. Roughly two months of building, roughly four months of earning the right to be used — and the contract was for the second one. A vendor who prices the build has priced a third of the job, which is the arithmetic behind every pilot that worked and never shipped.
The tell that you're buying an outcome, not a product: the statement of work names a business result ("reduce claims processing from 12 days to 2"), not a feature list. Palantir contracts read this way; so do the modern agent-deployment deals at the AI labs — the customer buys "invoices reconciled automatically," and which primitives got assembled to do it is the vendor's business.