Use your POC to negotiate commitment, not just prove that your solution works. Before the pilot starts, agree on what should happen if the pilot is successful.
Why?
Too many successful pilots never become deals. The pilot ends, then procurement, legal, supplier onboarding, budget approvals, and internal politics begin. Months later, you’re still discussing next steps despite having already proven value.
How?
Use the POC Commitment Ladder. Start with your highest ask and negotiate your way down until your customer commits to something meaningful.
- Automatic conversion into a commercial agreement
- Negotiate the final contract during the POC
- Executive readout with decision makers
- Agree on a decision deadline
- Start supplier onboarding early
- Secure a reference commitment
- Ask for a paid pilot
A bonus benefit: every commitment your customer refuses is a discovery opportunity. Ask why, uncover the concerns, and address them during the POC instead of discovering them after you’ve already invested months of time and resources.
Why Successful POCs Still Fail
One thing I've observed over the years is that a successful proof of concept (POC) and a successful deal are not the same thing.
I’ve seen plenty of startups run great POCs. The pilot goes well. Your customer gets value. The users are happy. The feedback is positive. Everyone agrees the solution works.
Then the pilot ends.
Suddenly the conversation moves to procurement, legal, supplier onboarding, security reviews, budget approvals, and stakeholders who haven’t been involved so far. Weeks turn into months, momentum disappears, and a project that looked like a certain win becomes surprisingly difficult to close.
The frustrating part is that the pilot itself often wasn’t the problem.
The pilot did exactly what it was supposed to do.
It proved that the solution works.
What it didn’t do was create a clear path towards a buying decision.
That’s why I think startups should look at POCs a little differently.
A POC shouldn’t only answer the question, „Does this solution work?“
It should also answer the question, „What happens if this is successful?“
For me, this comes down to a simple give-and-get principle.
A POC requires commitment from your side. Your team invests time, resources, effort, and sometimes even money. So I think it’s perfectly reasonable to ask for something in return.
And no, that doesn’t necessarily mean charging for the pilot.
There are often much more valuable things you can negotiate.
That’s where the POC Commitment Ladder comes in.
The idea is simple.
You start with your biggest ask. If your customer isn’t comfortable with it, you move down to the next level. Then the next. And so on until you find a commitment that works for both sides.
Think of it as a negotiation framework.
Start at the top and negotiate your way down.
One thing I particularly like about this approach is that every rejected commitment tells you something.
If your customer says no, don’t immediately move on.
Ask why.
What’s missing?
What concerns them?
What would need to happen during the pilot for them to feel comfortable?
Very often, those answers are more valuable than the commitment itself because they reveal risks while there is still time to address them. It’s much easier to deal with those concerns during the pilot than to discover them after you’ve already invested months of effort.
One of the biggest mistakes I see in software sales is treating a proof of concept (POC) as a purely technical exercise. The goal becomes proving that the software works. The problem is that technical validation alone rarely gets a deal signed.
So let’s walk through the ladder.
Level 1: Automatic Conversion After a Successful POC
Use the pilot to pre-negotiate the purchase decision.
My biggest ask was always some form of automatic conversion.
The idea was simple. If the agreed success criteria were achieved, the pilot would automatically convert into a small annual subscription.
The reason was straightforward.
I’ve seen too many successful pilots lose momentum between pilot completion and contract signature. By agreeing upfront what success should lead to, you remove a lot of uncertainty.
Many people immediately think this only benefits the vendor.
I don’t think that’s true.
It actually creates clarity for both sides.
Your customer knows exactly what happens if the pilot is successful. There is no need to restart commercial discussions from scratch. Everybody knows the next step before the pilot even begins.
To reduce the customer’s risk, we often included a termination clause. We would tell the customer that if they weren’t happy with the outcomes during the first few months, they could simply terminate with a short email.
The customer wasn’t taking on a huge amount of risk.
What we were really asking for was commitment.
If the pilot delivered what both sides expected, there was already agreement around what should happen next.
Sometimes this worked surprisingly well.
Some large enterprises basically looked at us as if we had lost our minds.
Fair enough.
When that happened, we simply asked why.
Sometimes it was company policy. Sometimes legal wouldn’t allow it. Sometimes procurement had rules against it.
Whatever the reason, we learned something useful and moved to the next level.
Level 2: Negotiate the Contract During the POC
Don’t wait until the pilot is over to start commercial discussions.
If customers weren’t comfortable with automatic conversion, the next ask was usually to negotiate the final agreement while the POC was still running.
One thing you’ll probably notice throughout this ladder is that I’m obsessed with parallelisation.
I hate doing things sequentially if they can be done in parallel.
I’ve never understood why teams spend three months proving value in a pilot and only then start discussing contracts, legal reviews, pricing, procurement requirements, or security approvals.
That means the pilot ends and the real sales cycle begins.
A much better approach is to use the pilot period to work through all of those topics in parallel.
That way, when the pilot finishes, you don’t have to start from scratch. You can move almost directly into final negotiations and signature.
This approach worked surprisingly well because customers usually saw the logic behind it.
Level 3: Executive Readout After the POC
Make sure the people controlling the budget see the results.
Many pilots create excitement within technical teams but never reach the people who actually control the budget.
The users are happy.
Your champion is happy.
The technical team is happy.
But the people who can approve the purchase never really see the results.
So we often asked for a 30-minute management presentation if the pilot was successful.
The agreement was simple.
If the pilot achieved the agreed outcomes, we would present the results together with our champion to the relevant stakeholders and decision makers.
I liked this approach because champions don’t always tell the story the way you would. They naturally focus on different things and may not position the business impact as clearly as you can.
By being in the room, we could help shape the narrative, explain the broader impact, and show how the success of a small pilot could potentially scale across the organisation.
In many situations, this ended up being more valuable than automatic conversion because it helped us expand the opportunity.
Level 4: Agree on a Post-POC Decision Deadline
Avoid endless discussions after the pilot ends.
If an executive presentation wasn’t possible, the next step was agreeing on a decision process.
Nothing complicated.
Simply agreeing that within 30 or 60 days after the pilot ends, there would be a formal go or no-go decision.
I’ve seen too many successful pilots drift into endless discussions where nobody really wants to say yes or no.
A decision deadline creates clarity.
It gives everybody a timeline and prevents the pilot from turning into an open-ended evaluation exercise.
Most companies spend a lot of time defining POC success criteria and very little time defining what happens after a successful POC. In my experience, both conversations are equally important.
Level 5: Start Supplier Onboarding Early
Run operational processes in parallel.
This one follows the same thinking as Level 2.
I hate waiting for one thing to finish before starting another if both can happen at the same time.
I’ve never understood why teams finish a POC first and only then start supplier onboarding.
Why wait?
Vendor registration alone can take weeks. Sometimes months. Security questionnaires, procurement reviews, compliance checks, and supplier registration all take time.
So a relatively small ask was simply:
„While we’re running the pilot, can we at least start supplier onboarding?“
Even if nothing else is ready yet, this alone can save a surprising amount of time later.
In an ideal world you’ve already negotiated the contract in parallel as described in Level 2.
At the very least, supplier onboarding should be achievable.
Level 6: Turn Success into a Reference
Create value beyond the deal itself.
If the customer wasn’t comfortable making a commercial commitment, we would often ask whether they would be willing to act as a reference if the pilot was successful.
That could mean a reference call, a small case study, a joint presentation, a quote, or simply being willing to speak with similar customers about their experience.
Especially for startups, that can be incredibly valuable.
A strong customer reference often helps future opportunities move faster because similar buyers can learn from somebody who has already gone through the process.
Level 7: Ask for a Paid Pilot
Create financial commitment.
This is probably the least important step on the ladder for me.
Of course, you can charge for the pilot.
Many companies do.
And it’s true that customers sometimes take projects more seriously when they have invested money themselves.
But personally, I often found the other commitments more valuable.
I’ve even done deals where we effectively credited the pilot cost against the annual subscription afterwards.
For me, the bigger question was always what happens after the pilot.
That’s where the real value sits.
Don’t Let A Successful POC Restart The Sales Cycle
Whenever I hear somebody say, „The pilot went great, but nothing happened afterwards,“ my first question is usually:
„What did you agree would happen if the pilot was successful?“
Many teams spend a lot of time defining technical success criteria but very little time defining what commercial success should look like.
That’s a mistake.
A POC should not only prove that your solution works.
It should help move the deal forward.
An automatic conversion can work.
If that doesn’t land, move to the next level.
Know what your ideal outcome looks like and negotiate your way down from there.
In our case, we often landed around the executive readout level, which turned out to be a very good place to be. In several situations, it created more value than automatic conversion because it allowed us to speak directly with the people controlling the budget and sometimes even expand the opportunity.
The main takeaway is simple.
If you’re running a POC, ask for something in return.
Get some form of commitment.
And if your customer isn’t willing to commit to anything at all, pay attention.
That doesn’t automatically mean the opportunity is bad.
But it may mean your customer isn’t as far along in their buying journey as you think.
And in some situations, that may be a sign that a POC is still too big of a step for where they are today.
FAQ
- What is a POC?
A proof of concept (POC) is a structured evaluation that helps your customer determine whether your solution can solve a specific problem before making a purchase decision. - Why do successful POCs fail?
Many successful POCs prove technical value but fail to address procurement, legal reviews, supplier onboarding, budget approval, and executive sponsorship. - What should happen after a successful POC?
Ideally, the next steps are already agreed before the POC begins. That could include contract negotiations, executive reviews, supplier onboarding, or a commercial agreement. - How long should a software POC last?
Most software POCs run between 30 and 90 days, depending on the complexity of the project and the number of stakeholders involved.
