The Proof of Concept

Continuing in the theme of pre-sales presentations, I thought I'd spend some time discussing the Proof of Concept (POC). The Proof of Concept is essentially required to bring enterprise sales to closure, but they can be risky.

Here are some pointers on doing a successful POC.

First and foremost, understand that the success or failure of a proof of concept hinges on two things:

• Technical aptitude and sales ability (skills)
• Control of Scope (management/risk mitigation)

The area that you can influence the most (aside from keeping your chops current) is risk mitigation. The method to do this is to control scope. You want to do the minimum proof necessary to demonstrate capabilities.

"Well, could you make it do..." is the most dangerous question ever during the middle of a POC.

Some of the questions you need to ask before the POC starts:

• What is it that we're trying to prove?
  

  You should have an elevator speech ready, and should repeat it often. This is what we're trying to prove, and this is what we have proven. This should be something definitive or measurable: "We're proving that we can do X transactions per unit time with this test corpus" or "We're proving that we can web-enable this business transaction"

• What are the standards of success?
• What are the next steps upon success?
  

  This is a "give to get" proposition: if we can prove the solution works, what is the next step in the sales process.

Some additional tips:

• Be visual.

  While at WRQ (Attachmate), I did numerous Proofs of Concept with their integration tool, Verastream. In every case, I highlighted the "behind the scenes" workings by showing the actual mainframe transactions-- this never fails to communicate that the demonstration is real, and integrated.

• Teach.

  If you can educate your customer about the product or service you're trying to sell, you just won a leg up. Customers buy solutions they understand and can approach.