By now this is a known, universal cause for frustration – both for customers looking for IT solutions and for vendors looking to demonstrate their solutions. Producing a successful proof of concept has become a matter of interpretation, with too many misunderstandings on both sides sometimes even leading to contract break off.
In fact, more often than not, these failed POCs are the consequence of numerous colliding interests: while the vendor’s goal is validating the solution in the customer’s real world environment, with as little time and effort as possible, the customer’s goal can be varied – from checking the usability of the product, to checking its compatibility with existing databases or servers, to comparing build vs. buy investments, etc.
The fact that everyone’s right from their own perspective doesn’t make it any easier. But, it does, however, outline a common goal to be achieved by the POC process: allow both customer and vendor to confirm that the solution in question is in-line with the customer’s expectations before a full-blown implementation.
What’s the problem?
So, before exhausting yourselves with yet another endless POC process, let’s analyze the most common problems in failed POCs to help you avoid their iteration:
- Undefined objectives for POC’s success
- “What was that…?”Customer’s requirements are not fully understood by the vendor
- Not using the real dataVendors only use sample data for the POC, reluctant to spend the time and effort required to use real data
- “Oh, and by the way, I also want to…”Customers usually realize what they want only after they start using the product and vendors are often reluctant to allow refining and adjustments on-the-go.
- “Look at me!”POCs show-off “killer” features, instead of customizing the product to solve the customer’s problem
- “I’m so pretty”Vendors often see POCs as a validation for their wonderful product rather than an evaluative tool for improving the product
The Best Proof of Concept Starts in the Cloud
The truth is, these are all understandable difficulties considering POCs traditionally took many months to develop, with any new requirement or misunderstanding of objectives or request to use real world use case – posing yet an additional effort on the vendor’s part. But, those days are long gone with the expansion of the cloud to IT solution development.
Here’s why –
The cloud enables a win-win situation: the customer gets to experience your product first hand in a real-world environment, on their terms, with their real data, and you get to provide their every changing need easily and effortlessly, in no time. There’s no hardware to ship, no software to install and no IT to support, and you get to really prove how your product solves your customer’s specific business problem.
Solving Traditional POC Problems with the Cloud
- Define clear objectives and requirements upfront. But leave room for changes along the way.
The first rule you’ll see when strolling down the web for POC’s best practices is defining customer’s requirements beforehand. And it’s true… to some extent. But, we think the best approach here is to leave room for changing requirements: you need to demonstrate your product in an environment that allows you to adjust them easily and quickly, in order to match exactly what your customers want, as well as define their expectations better for the final delivery. Today – meeting ad hoc requirements is the #1 POC virtue.
- Let them use it, play with it and even break it – nothing happens to the data!
With user-friendly, complex, isolated environments, the right cloud platform enables you to invite your customers to test your product, and even break it – without ever effecting the real data.
- Give your customers some credit – don’t blind sight them with empty visualizations
Nice-to-look-at visualizations and other gimmick features are cool, but they’re not the point. Use a cloud platform that allows you to address your customer’s specific problems, and offer customized dashboards to answer their needs. After all, we’re talking about solving your customer’s problem, not showing-off your product.
- Watch, learn and improve.
When building complex environments is easy, and adjusting requirements is a standard process requiring minimum or reasonable efforts on your part, POCs become less of a nuisance, and more of an opportunity to gather valuable feedback on your product; use it to improve it.
The cloud has introduced new ways to deal with traditional problems that for years have caused POC failures. It has changed the way vendors have traditionally perceived POCs, making developing, sharing and “breaking” of safe, user-friendly environments – quick and easy.
Now, you and your customers can truly enjoy and benefit from the real value of successful POCs – empowering the enterprise and providing value to every customer, while giving vendors feedback and information about their own product.
Discover how Cisco was able to compress their sales cycle from 12-16 weeks to 3-14 days.
Resources:
DeLuna, J. (2014, November 12). Core Fundamentals in any Proof of Concept/Capability.
George, M. (2014, August 28). 6 Steps to Make your Software Proof of Concept a Success.
Hewlett Packard. (2015, May 20). Anatomy of a successful Proof of Concept. Hewlett Packard.
Lazarikos, D. (2005, October 26). How to pull off a successful proof of concept.
Pentakalos, Ph.D., O. (2008, January). Proof-of-Concept Design. Microsoft.
SISENSE. (n.d.). 5 Tips for a Successful Proof of Concept for Business Analytics Solutions.
