“The Proof of Concept is dead”

I heard this claim for the first time at a data conference in early 2017. I would have probably forgotten this sentence if I had not heard it again a month later from a different speaker in another meeting. This got me thinking: can the “PoC” really be about to go extinct? And if yes, what could possibly take its place?

If you have already bought or sold software or any type of digital products or services, you very likely know what a PoC is: it stands for Proof of Concept and involves a short project, usually two to four weeks in length, in which the new technology is tested free of charge (or at a lower cost) to ensure it addresses the needs of an organization. It is the equivalent of a test drive when you are shopping for a new car – which is definitely a good idea.

So why would anyone think it is about to disappear? In this article, I will present a few considerations regarding the pros and cons of PoC testing. I will argue that while its nature is changing, the PoC is not in danger of becoming extinct anytime soon.

You don’t have time to read this article now? Download it as a PDF ebook hereor for your kindle there



If you are a small startup, you may only have resources to staff a few of these at any given time, otherwise, you will be spreading too thin. For large corporations, this is less of a problem and PoCs may be an essential component of the selling strategy.


As previously discussed, PoCs take time. But there is no guarantee that after investing this time the customer will purchase the product. So all that work may have been for “nothing”. Some vendors attempt to minimize this risk by including must-buy clauses upon obtaining successful PoC results. You must buy the car if you loved driving it – is not an intuitive line of reasoning, especially when the vendor initiated contact with the customer. I have seen many PoC discussions failing because of this approach.



On the supplier side, you will find out if the product works in a different (“real-world”) environment, or which must-have features must be prioritized in the development pipeline, etc. On the customer side, you will get to validate a new piece of technology, which could make your operations more efficient (i.e. save you some time) or offer a competitive advantage.

My experience with Proof of Concept projects is that a number of outcomes are possible, as for example:

◊ The product or service worked: it was purchased at the end of the PoC, and the two parties “lived happily ever after”. This is rare, but it does happen every now and then.

◊ The product or service worked but a sales contract did not materialize due to price, timeline, or implementation and maintenance considerations. This is frustrating, and in some instances can feel like you have just test driven a great car but you cannot take it home with you.

◊ The product has somewhat worked, but one or few critical features are missing. The action with the supplier is to build in the functionalities you need. If it happens that other customers have the same requirements as you do, then you are in luck and chances are the product will evolve soon.

◊ The product did not meet any of your needs. While this feels very much like failure, there is a silver lining: you have learned what does not work, and at the very least you would have increased your knowledge of the technology ecosystem. This knowledge can come in handy for future business discussions in which similar technology solutions are proposed.


During a PoC, the customer gets to know the supplier better and vice-versa. This is very useful especially when there is potential for a long-term business partnership. If you want to start somewhere, it might as well be with a PoC! You will get to see how seriously the supplier takes your feedback, how quickly they work to fix bugs and other unexpected issues, or how well they stick to project’s deadlines. Of course, the reverse is also true.

Beyond the customer-supplier relations, a PoC may contribute to forging relationships within the customer’s own organization. Sometimes a product is too expensive for a single department to buy, and a few teams may decide to join forces, try the product together and eventually split the costs if testing is successful. In addition, a PoC may offer an opportunity to bridge the gap (chasm!) between the early adopters and the more pragmatic or conservative decision makers in the company.


On the supplier side, we have already mentioned the risk involved with PoCs activities. For the consumer side, things are changing as well. More and more we are getting used to buying things without trying them out first (just think of your last Amazon or online purchase). For this to happen, two things are necessary. First, the “return policy” must be consumer-friendly – i.e. the contract should not carry substantial penalties. Second, the product must come with “great reviews” since it greatly helps if people we know and trust have tried it and liked it.

Another trend to consider is that the life cycle of most products is becoming increasingly shorter. New products and upgrades are released more frequently than ever before, and a reduction in the sales cycle is desired as not to fall out of sync. Fortunately, recent progress in technology has made it significantly easier to deploy products and services widely: for a SaaS offer the overhead is minimal.

When it comes to the technology itself, open source software poses certain challenges to the traditional notion of PoC. Taking this to the extreme, if 95% of your software were available for free on the web, then how would your business model be impacted? How much effort would it take for someone else to rebuild your product through reverse engineering?


Despite the changes mentioned above, the PoC is far from being dead. While the time required to conduct PoCs has dropped, the product variety has increased in almost every industry. In today’s marketplace innovation is critical to surviving. It has become routine for companies to run multiple pilot tests at a time. This creates new opportunities and there are a number of businesses in tech or consulting whose sole purpose is to help companies conduct successful PoCs. In these cases the Proof of Concept is not disappearing: it is simply shifting its place in the distribution chain, and the risk associated with it transfers to intermediaries.
From my experience, you always learn something useful from a PoC; even if the benefits are not immediately tangible, they will likely materialize farther down the road.