What a Proof of Concept Should Actually Prove

The demonstration goes well. The model is accurate, the prototype is slick and the sponsor is delighted. Six months later it is still a pilot, and a year later it has quietly stopped.

This is so common it has a name: pilot purgatory. It happens because most proofs of concept answer the easiest question, whether the technology can work, and skip the ones that decide whether it ever will: whether people will use it, whether it pays, and whether the organisation can run it. This article sets out what a proof of concept should actually prove, and how to design one that ends in a clear decision.

Most pilots never scale

The best recent evidence comes from AI, where pilots have multiplied fastest.

• In a Gartner survey of organisations already using AI, on average only 48% of AI projects made it into production, and getting from prototype to production took eight months. The most common barrier was estimating and demonstrating the value of the project Gartner.
• Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, because of “poor data quality, inadequate risk controls, escalating costs or unclear business value” Gartner.
• Research by IDC for Lenovo found that for every 33 AI proofs of concept a company launched, only four reached production CIO.
• S&P Global Market Intelligence found that the share of companies abandoning most of their AI initiatives rose from 17% to 42% in a year, and that the average organisation scrapped 46% of its proofs of concept before broad adoption S&P Global.

Notice what is missing from the reasons. Very few pilots stop because the technology could not be made to work. They stop because nobody could show the value, the costs grew, the risks were not managed, or the organisation was not ready.

Most ideas should fail, cheaply

You may have read that 95% of new products fail, usually attributed to Clayton Christensen. A 2013 review in the Journal of Product Innovation Management reports that he denied saying it, and that studies of new products have generally put the failure rate at around 40% or less. The honest position is less dramatic, and more useful: success is uncertain and hard to predict in advance.

Economists studying new ventures describe their chances of success as “low, extremely skewed, and unknowable until an investment is made” Journal of Economic Perspectives. Even the most experienced experimenters are usually wrong: at Google and Bing, only about 10% to 20% of experiments produce positive results HBR.

So the job of a proof of concept is not to show that an idea works. It is to find out, as cheaply and quickly as possible, whether it does, and to make stopping a respectable outcome when it doesn’t.

Four questions, not one

IDEO popularised a simple test for new ideas: are they desirable, feasible and viable? HBR For anything that has to run inside an established organisation, add a fourth.

• Desirable. Will the people it is for actually use it, in their real work, without being made to?
• Feasible. Can the technology do the job, on your data, at the quality you need?
• Viable. Does it pay, at full volume, once checking, support and running costs are counted?
• Adoptable. Can your organisation run it: integrated with your systems, approved by security and data protection, with an owner and a budget after the pilot ends?

Most proofs of concept test only the second question. That is why they succeed as demonstrations and fail as investments.

Test the riskiest assumption first

Every idea rests on a few assumptions that, if wrong, sink it. Eric Ries called them leap-of-faith assumptions. The UK government’s Service Manual makes the same point: a crucial part of the alpha phase is “identifying your riskiest assumptions and testing them”, and you only need to build enough to test those GOV.UK.

The riskiest assumption is rarely the technology. More often it is that people will change how they work, or that the saving will survive contact with real volumes. Test that first, with the cheapest test that would convince you. The Service Manual is equally clear that stopping at the end of discovery can be the right result, because it saves time and money GOV.UK, and teams have written about why deciding not to build can be a success Home Office Digital.

A worked example

A team wants to use AI to triage incoming customer requests.

A technology-only proof of concept reports that the model classifies 90% of last year’s requests correctly. Everyone is pleased. Nothing about it says whether the organisation should invest.

A proof of concept designed to decide sets out, before it starts:

• Desirable: frontline staff accept at least 60% of the suggestions without editing them, over four weeks of real work.
• Viable: the full cost per request, including checking and fixing mistakes, stays below the current cost at expected volumes.
• Adoptable: it runs on the live case system, the data protection impact assessment is signed off, and a named budget holder will own it afterwards.
• Stop if: acceptance is below 40% after four weeks, or no budget holder has been found by week six.

At the end there is a decision, not a demonstration: scale it, change it, or stop.

Before you start a proof of concept

1. Name the decision it informs, and who will make it.
2. List your assumptions under desirable, feasible, viable and adoptable, and rank them by how risky and uncertain they are.
3. Test the riskiest first, with the cheapest test that would convince you.
4. Write down success and stop criteria before you begin, and agree them with the decision-maker.
5. Use real users, real data and the real environment, or be explicit about the gap.
6. Plan the route to production on day one: owner, budget, integration, security and procurement.
7. Fix a timebox and a date for the decision.

If you have an idea and need to know whether it will work for real, talk to us. We will help you design a proof of concept that ends in a decision.

Sources

1. Gartner (2024). Gartner survey finds generative AI is now the most frequently deployed AI solution in organizations.
2. Gartner (2024). Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025.
3. CIO (2025). 88% of AI pilots fail to reach production, but that’s not all on IT. Reporting IDC research for Lenovo.
4. S&P Global Market Intelligence (2025). AI experiences rapid adoption, but with mixed outcomes.
5. Castellion, G. and Markham, S. (2013). New product failure rates: influence of argumentum ad populum and self-interest. Journal of Product Innovation Management, 30(5).
6. Kerr, W., Nanda, R. and Rhodes-Kropf, M. (2014). Entrepreneurship as experimentation. Journal of Economic Perspectives, 28(3).
7. Kohavi, R. and Thomke, S. (2017). The surprising power of online experiments. Harvard Business Review.
8. Brown, T. (2008). Design thinking. Harvard Business Review.
9. Government Digital Service. Service Manual: how the alpha phase works and how the discovery phase works.
10. Home Office Digital (2025). Deciding not to build a new service: why stopping can be the right outcome.
11. Ries, E. (2011). The Lean Startup. Crown Business.