An often-discussed topic between vendors and potential customers is the Proof of Concept (POC) versus Proof of Value (PoV). More times than not, the customer refers to it as a PoC, while the vendor team suggests a PoV. From my vantage point, here are my two cents on the matter.

The vendors are trying to get away with making more money by using a marketing term, right? wrong. PoCs and PoVs should be seen as entirely different entities. One way to tell them apart is that a PoC proves the solution works, while a PoV stands for Proof of Value, proving it will work for you specifically. This POV takes into account things like justifiability and measurability of value realization.

First of all, these days, customers shouldn’t waste time trying to prove if commodity off-the-shelf (COTS) software works for them.

However for complex software solutions, from a technical capabilities point of view, before the customer invests more time into this process and before lifting a finger in testing the solution, the vendor should already be able to provide means of proof that show the software is effective; examples of such include reference customers, industry analyst reports, Venture Capital funding investments, white papers, press reviews, etc. If you’re unsure that the software will function as advertised, based on the analysis of these artifacts, it might not be worth your money to purchase it.

Now, let’s move on to a Proof of Value exercise. I’ll share my insights as an Application Delivery vendor on what intelligent customers do when testing an Application Delivery solution (Software Load Balancer). When you cough up thousands or even millions of dollars as a large enterprise customer in Finance Services, retail, telco, etc., you expect positive results that reflect your investment. This is called the PoV (proof of value). That’s why it’s important to ensure the PoV aligns with your company’s goals before committing. Otherwise, what’s the point? To do this effectively and across technologies without platform bias - examples could include anything from better performance, less downtime in Production, more velocity and speed of deployment, and course saving money in some capacity.

In my example, the focus should now be on addressing precise requirements (and pain points), such as

• Outages were significantly reduced to meet SLAs. i.e., Less than ten 4XX/5XX errors per hour and less than 1 min downtime per day, meeting SLA targets of tier 1 customers
• Unified control plane with the ability to manage configurations and retrieve metrics across deployments in Azure and AWS clouds and on-premise VMware
• Reduction of over 40% in Cloud compute costs attributed to minimizing the use of Cloud Load Balancers and using container deployments instead of costly Virtual Machines
• 40% cost savings moving from the incumbent solution

The points detailed above all revolve around one thing - value. Yes, while a list of your tool’s features is important (100+ line items, those often seen in an RFP document, like “ Your tool must also support RHEL8 Linux” ), it’s may not yield actual value to the customer’s business.

The PoV should answer two key questions: first, where do we expect to see the value? And second, how will we track and measure that value - not just during the PoV stage but after purchase and implementation too?

The next time you think about a new technology solution, discern if you want to do a POC (will it even work?) or need an in-depth POV study (would it provide real value to my company?). The gap between the ‘C’ and the ‘V’ is more than another way for technology vendors to market their solutions.