Saturday, May 26, 2007

Proof of Concept

If everything is going well, and the customer likes the product you are selling, they will probably make you come in and show them that the product does what they want. We usually call this a PoC (Proof of Concept) but it could also be anything from a demonstration to a full pilot of the product in their production system. Ideally you don't go that far!!!

A well-run PoC should have the Sales Engineer contact the customer's technical evaluation team ahead of time, and find out how the product should fit into the customer's system. From this early discussion, a series of steps should be developed that would make up the PoC. As an SE, you should drive the process here to ensure that the tests play to the product's strengths, and shelter any weaknesses you are aware of. If possible, and if acceptable, the PoC should include discussion on the final architecture, and this can even take place of some of those tests.

A colleague of mine recently complained that his customers wanted him to come on site and they would run some tests. They wouldn't tell him ahead of time what they wanted to test, or how they wanted to use the product or any other detail. This is a recipe for disaster. Depending on the customer requirements, your lab can help you prepare for the PoC with custom tools, builds, special reports, or you can even just sit down and work out how to best run all the tests. It is waste of your company's time and resources if you go into a sales situation without being able to prepare for their requirements.

The worst result of doing a PoC, is that it eliminates you from the sale, or you have to go in again to do another, because you weren't able to address the customer's main questions.
The other thing is, if you just have a workshop or planning session with a good demo system, you might be able to avoid doing a PoC altogether.

The other thing is, unless the customer is paying for the software, paying for a report, you should take your software off all their machines as you leave. Unsupported evaluation means that inexperienced users will explore your product and not learn anything about how it is supposed to be used.

Finally, the PoC is a sales tool. It can sometimes be strategic in being the first vendor to do it, and at other times you should refuse to PoC unless the customer prove that the are actually going to buy. You always should be doing the PoC to satisfy the business buyer, not just to show the product to interested technicians. It might be the business buyer's requirement for the technician to like the product, but it might not be as well (especially if the tool eliminates jobs...)

So make sure you plan your PoCs carefully, and only do them if it makes sense to you. A customer asking you to PoC should be sounding interested in your product. Otherwise, they might just be ticking a box to say they checked out X other solutions.

2 comments:

common man said...

Great Suggestions...thanks.

Kevin said...

How do you incentive customers to begin a PoC when you know that once they see the performance and benefits (reduced costs, etc.) of the software they will be compelled to buy?