You won the POC. So why did you lose the deal?
A few years ago, I would have considered a successful POC a win.
The customer had a list of things they wanted to validate. We agreed on success criteria. We did the work. The technology did what we said it would do.
Success.
Except sometimes, a few weeks later, the opportunity was lost.
I’ve seen this enough times that I started questioning what we actually mean when we say we “won” a POC.
Because if the customer validates your technology and then buys from somebody else, delays the project or simply does nothing, what exactly did you win?
I don’t think the problem is the POC.
I think the problem is that sometimes we, as Sales Engineers, treat the POC as if passing it were the objective.
It isn’t.
What is the customer actually trying to decide?
Let me use a simple example.
Imagine I’m working on an opportunity where the customer has two ways of integrating our product.
Option one is relatively easy. They can integrate quickly, with less development effort, but they give up some control over the user experience.
Option two gives them much more control and customisation, but it’s going to take longer and require more engineering resources.
As an SE, I can explain both options.
I can build a demo.
I can help them test both integrations.
I can answer every technical question they have.
And we could get to the end of that process having done an excellent technical job without answering the question that actually matters.
Which trade-off makes sense for this customer?
That’s where things get interesting.
Because now I need context.
Why does getting this into production quickly matter? Is there a deadline? What happens if they miss it? Who cares about the additional development effort? Is complete control over the UX genuinely important, or is it just something the technical team would prefer to have?
And there’s another question I’ve become increasingly interested in:
Who needs to be involved in that decision?
Suddenly we’re not talking about integration methods anymore.
We’re talking about a decision.
The technical conversation hasn’t disappeared. I still need to know the product. I still need to understand the architecture and explain the trade-offs properly.
But knowing what’s happening around the technical conversation changes what I do with that knowledge.
That’s the difference I’m interested in.
A POC can answer the wrong question perfectly
This is where I think success criteria can sometimes give us a false sense of security.
We define them carefully. Everyone agrees. Then we work our way through the list.
Can the platform handle this use case? Yes.
Does the integration work? Yes.
Does it meet this particular security requirement? Yes.
POC passed.
Great.
Now what?
That’s the question I think we need to ask much earlier.
If every success criterion is met, what becomes possible that wasn’t possible before the POC?
If the answer is that the customer can now make a specific decision, great. The POC has done its job.
But if the answer is basically “we proved that the product works”, I’d want to understand what is still missing.
Maybe technical feasibility really was the only thing preventing the customer from moving forward. That happens.
But maybe it wasn’t.
Maybe the person who controls the budget still isn’t convinced that solving the problem is worth the investment.
Maybe another team has concerns about implementation.
Maybe our contact loves the solution but has no idea how to get the project approved.
Maybe we’re proving something the customer already believed while ignoring something they don’t.
That’s why I’m becoming much more interested in the question behind the success criteria than in the criteria themselves.
Why does the customer need this evidence?
I don’t think the SE should own the deal
This is where the conversation can go wrong.
The AE owns the deal. I believe that.
I’m not suggesting that Sales Engineers should start running forecast calls, negotiating commercials or trying to become Account Executives with better technical skills.
That’s not the point.
But I don’t think “the AE owns the deal” means “the SE only needs to understand the technical requirements.”
Because I can’t make good decisions about my part of the opportunity if I don’t understand what the opportunity needs.
Go back to the integration example.
If the main concern is time to market, that’s relevant to me.
If the customer is struggling to justify the engineering effort internally, that’s relevant to me.
If the decision is going to be made by somebody I’ve never spoken to, based on criteria I don’t understand, I’d quite like to know that before spending three weeks on a POC.
I don’t need to own those things.
But they absolutely affect the technical work I choose to do.
This has changed the way I think about Presales
For a long time, I thought getting better at Presales meant getting better at the things SEs do.
Better discovery.
Better demos.
Better POCs.
More technical knowledge.
And obviously all of that matters. I’m not arguing otherwise.
But I think there’s a layer above the activities that we don’t talk about enough.
Why this discovery?
Why this demo?
Why this POC?
Why now?
What needs to be different after I’ve done it?
I’ve started using a very simple question for this:
What does this deal need from me right now?
I like it because the answer isn’t predetermined.
Sometimes the deal does need a POC.
Sometimes it needs a very specific demo.
Sometimes I need to shut up and understand the problem better.
And sometimes the most useful thing I can do has very little to do with showing more technology.
That question is becoming the basis of something I’m calling Working the Deal.
I’m still developing the idea, so I don’t want to pretend it’s a finished methodology. It isn’t.
At the moment, it’s much simpler than that.
It’s the idea that Sales Engineers should understand enough about the deal to know why they’re doing the technical work they’re doing.
Technical work with commercial intent.
So, did we win the POC?
Maybe.
But I think I’ve been asking the wrong question.
I don’t really care whether we won the POC anymore.
I want to know what changed because of it.
Did we remove something that was stopping the customer from moving forward?
Did they learn something they needed to know?
Did we create evidence that helps someone make or defend a decision?
Or did we just prove that our technology works?
Because those are not the same thing.
And if we get to the end of a successful POC without knowing the difference, losing the deal probably shouldn’t surprise us.