Proof of Concept Best Practices

This work by Marcelo Bernardes (@marcelobern) was originally posted on LinkedIn.

Are you seeing an increased demand for proofs of concept (POCs) from your potential customers? You are not alone. More customers want to know how the proposed components will fit in their overall solution, and they want to understand how the overall solution will address their business needs. POCs may be part of a competitive bid or RFP process, an internal compliance requirement, etc. Whatever the reason may be, developments like cloud computing seem to be leading customers to expect POCs to be an innate ability of all their vendors.

I had the opportunity to build and lead the team responsible for successfully delivering POCs to multiple Fortune100 companies. Over time, we were able to identify a set of best practices, the core principles of which, I would like to share with you:

• Set proper customer expectations. I cannot stress this point enough. As obvious as it might be, having a consensus between the various customer representatives, your own sales team, and the team involved in setting up the POC is critical. A key part of expectation setting is the agreement of what will be covered during the customer visit. I recommend the use of an informal document, like a list of test cases. Partner with the sales team and let the customer know the POC team is flexible and wants to be prepared to address the customer needs. The right way to address the customer needs is to know what is expected, prepare for it, and flawlessly showcase the proposed solution.
• Dry-run everything that will be shown to the customer. And I mean everything. Do not assume that a basic feature set works just because it always worked. Proof of concept environments are very dynamic. It could be that someone decided to change the POC environment slightly for another customer that stopped by last week, or that the latest code release changed how that five year old feature works. Do not leave it to chance, test everything early, giving the POC team plenty of time to take corrective action. It just takes avoiding a disaster during that "cannot lose" customer visit for all the dry-run efforts to be paid off a thousand times over.
• Engage the sales team. This is a hard one to get right. Most sales teams (even the technical sales members) are likely busy with other accounts and they just want to stop by on the day of the customer visit. Even though the expectation setting process should have captured the customer needs appropriately, a sales team close to the customer should be able to let the POC team know which planned presentation flow will appeal to the customer, and how to improve the planned POC presentation flow. We had great opportunities to fine tune the POC flow just by having the sales team show up some days earlier. The very best POC experiences were those where the sales team was so involved, they delivered the POC completely on their own (with the POC team supporting them in the background). What an effective way to show customers the sales team understood their needs and can deliver the right solution!

Even though a proof of concept will not win a deal when a solution fails to meet the customer needs, it should never be the reason a deal was lost.

Did these (or other) best practices seal a deal for you? Please feel free to share your POC experience with us in the comment box below.

And if you would like to be automatically notified when I publish new articles, just follow me.

Read next: Cloud integration will change Pro Services, are you ready?

This work by Marcelo Bernardes (@marcelobern) is licensed under a Creative Commons Attribution 4.0 International License.

(Image courtesy of Stuart Miles - FreeDigitalPhotos.net; Post updated Apr/6/2014)