Feb 8, 2012 4:00:56 AM
Conducting Successful Proof of Concept Engagements

Very often as sales engineers we are tasked to help the customer with assistance during a proof of concept engagement, however, these types of projects can present different types of challenges. Ultimately, every SE’s goal should be to help the customer gain a high level of comfort with the solution, meet their requirements, educate them and if possible, discuss the considerations for the real deployment. Given the limited time and resources involved in a proof of concept, how we can delight our customers and meet their needs?

In my experience, a successful engagement of this nature begins with understanding the customer’s definition of a PoC; believe it or not, expectations vary greatly between solution providers and end customers. A “PoC” could be as simple as an extended demonstration of the solution that is held at the provider’s facilities, or a production pilot that aside from demonstrating the feasibility of the solution, has to meet production-grade requirements such as the integration with operation components. The former, in my opinion, does not meet the dictionary definition of a PoC, but the latter, since it can evolve to be a production-grade installation, becomes a challenging proposition, especially for a company that sells integration services. All this variability, coupled with the fact that each technology presents different degrees of challenge and that a PoC is an audition not only for the solution set, but also for the service provider, stresses the need to communicate effectively and document expectations early. Aside from not understanding or setting the proper expectations, some of the common PoC engagement pitfalls are:

a) Not having a proper readiness review
Every solution has a set of pre-requisites that need to be discussed with the customer to make sure that their environment and their people are ready. With change–control being introduced to test environments, a pre-call to assess the readiness of the customer ensures maximum productivity at the start of the PoC engagement.

b) No agreement on success criteria
Every concept or requirement to be evaluated should have a clear success and failure definition; and as a stretch goal, it should include considerations for production deployments. Clarity is imperative and it may require the SE to educate the end customer, especially if the capability is new to them.

c) Not getting the right people involved
It’s very important for the SE to try to understand the governance model of the customer, this is because some changes and decisions may not be made on time during the engagement or the PoC results may get push back if a key stakeholder is not involved in the evaluation process.

PoC engagements can be challenging, but can also be a great way to show the customer the level of expertise that your company brings to the table. Here are my tips to successful PoCs:

  • Before the engagement: understand the customer’s expectations, plan ahead, and identify any hard or long-lead dependencies of your technologies.
  • During the engagement: find opportunities to educate the customer and to establish realistic expectations about your product or solution, the customer will appreciate your candidness and they will feel confident about what to expect once the real deployment arrives.
  • After the PoC: follow-up. Touch base with the customer to get valuable feedback that can be used to improve yourself, your solution or your company.