Technical Go-To-Market · Chapter 3 of 6
Proofs of concept that end
The POC that never concludes is the characteristic failure of this job. It is preventable in writing.
A proof of concept without written success criteria does not end — it gradually stops, having consumed weeks of your time and the customer's, and produced no decision.
The contract to agree before building anything
- What specifically will be proven. Two or three criteria, measurable, agreed by the person who can actually say yes.
- What data will be used, and who provides it by when. Data arriving late is the single largest cause of POC slippage.
- How long it runs, with an end date.
- What happens if it succeeds. If the answer is ‘we will discuss next steps’, you are running an unpaid pilot rather than a sales motion.
- Who does what. A POC where you do everything proves that you can operate the product, which is not the question.
Running it
Scope to the one workflow that matters and cut everything else by name. Use their real data and expect it to be worse than described — that is normal, and how you handle it is part of what is being evaluated. Show progress weekly rather than revealing at the end, because a surprise at the end is a risk to them and a POC with no visible progress gets quietly deprioritised.
The failure that is actually a success
Sometimes the POC demonstrates that the product is wrong for them. Saying so plainly, early, is the right call: it saves everyone weeks, and in my experience those customers come back for a different use case far more often than the ones who were pushed through a bad fit.
It is also the story most worth having in an interview, because almost nobody brings one.
Running a proof of concept that concludes
Most proofs of concept fail in a specific way: they do not fail, and they do not succeed. They drift, the champion moves on, and eight weeks of engineering time produce no decision. The fix is entirely in the setup.
- Write down the success criteria before starting, and get them agreed in writing. Specific, measurable, and few — three is plenty. If you cannot get agreement on what success looks like, you have learned something more valuable than the proof of concept would have told you.
- Put an end date on it, and treat it as real. An open-ended trial becomes free consulting, and free consulting has no natural end.
- Agree what happens on success — before you start. ‘Then we will discuss next steps’ is not an outcome; ‘then we move to a paid pilot with these teams’ is.
- Use their data and their environment. A proof of concept on sample data in your environment proves nothing anyone doubted, and the real objections only appear when real data does.
- Name the person on their side who owns it. A proof of concept with no owner on the customer side is a project you are running alone and will lose quietly.
The hardest discipline: be willing to conclude that it failed.
A proof of concept that cannot fail is not a test — it is a demonstration with extra steps, and sophisticated buyers recognise it immediately.
Concluding honestly that the fit is poor buys credibility that outlasts the deal. Customers move companies, talk to each other, and remember who told them the truth when it cost something.
The commercial version is not martyrdom: ‘this is not a fit for the use case we tested, and here is the one where it would be’ keeps the relationship and often keeps a smaller deal.
And watch for the drift pattern: success criteria that quietly expand mid-trial are the customer telling you it is not working. Treat a scope change as a signal to have the honest conversation, not as a reason to extend.
Check yourself