Skip to specification
harnessarch

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.

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.

what is the customer actually buying?A PRODUCTcustomer buys softwarethen pays the tax:train their people,build value themselvesA SOLUTIONcustomer buys the outcomeengineers + platform,delivered as one thing:the problem, solvedA SERVICEcustomer buys someone's timebespoke every time,nothing compounds,maintenance eats the P&L↑ Palantir's move: stop choosing — sell both at once, priced as the outcomehow the data is organized is an implementation detail — the buyer cares about shelf placement and throughput
Product, service — or the thing in between. The customer buys neither software nor time. They buy the outcome.

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?

In the wild

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.