The POC is Dead, Long Live the POV

Thursday, 2:40 PM.

The vendor's slides are good. Transition animations, a live demo environment, a reference customer in the same vertical. The procurement lead has a rubric: seventeen criteria, weighted. Security is 20%. Integration complexity, 15%. The sales engineer answers every question cleanly.

At the back of the room, the CIO hasn't looked at the slides in twenty minutes.

She already knows the demo works. It always does. It's canned. Her question — the one she hasn't asked yet, the one that isn't on the rubric — is different: can they come into her environment, against her data, and still work? And once we buy, will they walk away, or will they stay until it does?

Nobody has offered that. Nobody has been asked.

The procurement lead scores the presentation: 91 out of 100. Recommended for pilot.

The pilot runs for twelve weeks. They kick the tires. The results are positive.

It never makes it to production.

The eulogy

The pilot wasn't a bad idea. It was a brilliant one, for the world it was designed for.

The logic was sound: before committing to a full deployment, you run a controlled evaluation. Sandbox environment, representative data, defined success criteria. The vendor proves the technology works. The buyer carries deployment risk from there. Everyone understands the terms.

This motion made sense because the software was stable. What you evaluated in Q1 was substantively the same product you'd deploy in Q3. The risk being managed was integration complexity (could this thing work in your environment?), and a time-limited pilot was a reasonable way to answer it.

The procurement cycle was built around that assumption. Months to evaluate. Months to negotiate. A contract covering years of a product that wouldn't change much.

That assumption is now wrong.

The diagnosis

The software is no longer stable. And everything downstream of that fact — the pilot structure, the procurement timeline, the contract model, the pre-sales motion — is now optimised for a problem that no longer exists.

Three things have broken simultaneously.

The velocity mismatch. The AI product you evaluate in January is a materially different product by March. The model has been updated. The agent capabilities have expanded. The benchmark you used to score it is already outdated. A twelve-week pilot doesn't tell you how the technology performs. It tells you how a previous version performed, assessed against criteria you wrote before you understood the use case properly.

The context collapse. Agent performance in a controlled environment tells you almost nothing about agent performance in your environment. Against your data. Your edge cases. Your customer language. Your legacy systems. The integration isn't a downstream problem to be solved after the evaluation — it is the evaluation. A sandbox result that doesn't survive first contact with production isn't a proof of concept. It's a proof of demo.

The risk inversion. In the old model, the vendor carried demo risk and the buyer carried deployment risk. That was the implicit contract: we'll prove it works in our environment, you figure out how to make it work in yours. Enterprise buyers are quietly — and entirely reasonably — refusing that deal. The demand now is different: come into my environment, against my specific problem, and prove it there. If it doesn't work, that's your problem too.

This isn't buyers being difficult. It's buyers being rational in a world where the technology moves faster than the procurement cycle.

The vendors who haven't noticed are still running demos. Still polishing sandboxes. Still optimising for a buying decision their customers have already stopped making.

The signal

Something is happening at the leading edge of the AI vendor landscape that's worth paying attention to. Not because of the job title, but because of what it tells you.

A role called the Forward Deployed Engineer is being called the hottest job in tech. It's being hired at OpenAI, Palantir, Ramp, Salesforce. a16z wrote about it in June 2025 as the defining go-to-market motion for AI companies serious about enterprise. The role sits at the intersection of engineering, sales, and customer success. It exists because the old hand-off model broke.

The FDE's job, in plain terms, is to go into the customer's production environment and make the thing work there. Not in a sandbox. Not against synthetic data. In your systems, against your problems, accountable for your outcomes.

The interesting thing isn't the role. It's what its existence tells you about the shift. Palantir built this model a decade ago because traditional enterprises couldn't integrate sophisticated software without embedded engineering support. What's changed is that the same is now true for every AI vendor, not just the ones working with defence agencies and intelligence services. The complexity that once required a Palantir-style deployment model is now the baseline for any serious AI implementation.

The FDE is a symptom. The disease is the gap between what vendors are selling and what enterprises are actually buying.

There's more to say about what this role means for how vendor organisations need to be structured. That's a separate piece. For now, the point is simpler: if your vendor hasn't mentioned anything that sounds like this, ask why.

The horizon

Two futures are available from here.

In the first, vendors reorganise around outcome delivery. They embed engineers in customer environments. They agree on metrics before they agree on contracts. They treat the integration as their responsibility, not the customer's problem. They become hard to remove. Not because of contract length or switching costs, but because they own the context layer. They know your data, your edge cases, your escalation patterns. The proof of value motion creates the moat that product-led growth promised and rarely delivered at enterprise scale.

In the second, vendors keep running the old motion. Better demos. More polished sandbox environments. Faster pilots with cleaner results. They get better at optimising for a buying decision their customers have already moved past. They'll win some deals; procurement processes are slow, and inertia is real. But they'll lose the relationships that matter. And they'll be disintermediated. Not by a superior product, but by the first vendor willing to go first in production.

The uncomfortable implication for the CIO: the vendor who's willing to come into your environment and be accountable for outcomes is also the vendor building the deepest integration with your systems. That's not a risk to be managed away. It's a relationship to be chosen carefully.

Proof of value is a two-way commitment. The vendor proves they can deliver. You prove you know what you're buying.

Monday, 9:15 AM. Same room. Different vendor.

They haven't opened a slide deck. They want to talk about the three customer escalations from last quarter — the ones that took longest to resolve, the ones the team dreads. They want to know what a good outcome looks like, in a number, by when.

The CIO's team is slightly uncomfortable. Nobody has asked them to define it that precisely before.

They agree on a metric. They agree on a timeline. The vendor asks for access to the production environment.

It's a smaller ask than the previous vendor's contract. It feels larger.