Proof of Concepts: Kiss of Death?
The Proof of Concept (POC) or conference room pilot. In the four years I worked at PeopleSoft I never won a deal that included a POC. They were the kiss of death to a deal. Later, when I worked at Guidewire Software we had several deals that were won decisively by the POC. So it is possible to win deals with a great POC. Here are some guidelines that should be followed.
- Make sure you have the right product for a POC.
- Set clear boundaries for the POC
- Set realistic expectations and goals
- Make sure you have access to both technical and business people at the prospect
- Watch for competitive traps
There was a reason that POC were troublesome at PeopleSoft: the software. Although PeopleSoft was excellent software, it was difficult to install and had a steep learning curve for new users. This meant that we needed multiple experts on site to do a POC (both functional and technical) and often very specific hardware to run the applications. The other issue was that we had one version of the software from development and another version for sales. This may seem deceptive, but the sales version was a stable build of the software with a bunch of demo data loaded (and some mods like integrations and things to support smooth demo scripts). For a POC we would be expected to load the base software and it would come off looking much plainer than the demo version. All this meant that when competing against startup or niche vendors we came off looking pretty difficult to use.
Although Guidewire’s software was much better suited to POC (simpler and much easier to install), that was not the only reason we had success. The POC I participated in at Guidewire had very clear boundaries about what the prospect could and could not ask for. We called the a “test drive” and we installed the software on their site (or brought a laptop with our version loaded). Users then went through very specific scripts that showed them how to use the functionality that we had developed (often with the help of their IT staff). The key to success was having clear boundaries and goals for the POC.
This is different than boundaries. Setting expectations and goals should include creating a specific scoring sheet (if they prospect does not supply one) for what you will accomplish in the POC. Are you going to import their customer list and complete a couple transactions? Are you going to measure ease-of-use with experienced users? Making it clear what should be accomplished and the measure of success is critical. For enterprise class software (meaning software that companies pay big bucks for and is core to their business) you can’t just hand over a copy and say “Go for it”.
To pull off a successful POC you are going to need help from both the busienss and IT people at the prospect. If they can’t commit, you are not likely to do well.
If your competitor suggested a POC then you should watch out: they probably feel it is a competitive advantage for them. If you have not dealt with POC before with this competitor you should be wary and do everything possible to focus the POC on your strengths. Not many software vendors use POC consistenly in their sales cycles, so if they do, they have a reason.
POC are a lot of work but they can definitely be effective in winning deals. A prospect who gets a chance to see your product perform under close to real conditions is much more willing to believe the results.