Proof of Value

POC – Proof of Concept

The Proof of Concept is when the customer would like to have an on-premise proof of the proposed solution to make sure it works as they expect.

It can be a quite intensive and expensive exercise, so you want to make sure you take full advantage of this step.

If you’re planning a POC, there are many traps that you might fall into. These are some of the major ones.

1. • POC is confused with a Demo
   • The proof of concept is just that, you are proving that your concept works on premise with the client. In early stages the “concept” or the desired outcome is not defined yet enough to prove it working. Many clients still ask to “play around” with your solution. Try to avoid this, as especially with complex solutions they client might be overwhelmed and confused after the “playing period”
   • If the client needs to learn more about your offering you can offer Demos, Webinars and discussions about use cases and needs.
2. • The Economic Buyer is not aware of the project
   • Especially in larger companies, make sure you meet the EB to get his sponsorship to run the POC. After all it is a huge investment from your company and you want to make sure there is a chance to close a deal in the end.
3. • Not all parties are invited to the POC
   • The POC is designed to be last ultimate proof point of the “technical” concept. Not all departments needed are involved. You might end up making multiple POCs or even worse, let competition run their own POC with other departments. Make sure you understand who needs to be invited. The EB and Champion might help.
4. • Poor preparation before the POC
   • The client did not setup the environment and you spend days wasting valuable POC days to setup. Not all attendees have time to take part, or they move in and out during the POC, making it possible that they miss important parts.
   • Make sure you have a complete list of attendees and ensure they have the time.
   • Sometimes it is better to make a two-day POC with all attendees than a four-week with only some of them.
5. • Uses cases are not documented before the POC
   • A POC should have clearly documented use cases to be shown and checked positive in the list, so you can talk about a successful POC.
   • – Make sure you and your technical counterpart spend time with the POC attendees to define what success looks like with documented use cases. LESS use cases with more depth is better then the other way around!
   • – Try to influence the use cases in way that your solution or offering shines!
6. • Sales people do not participate
   • Many POCs are run without the sales people showing up. This is not good for many reasons: First you cannot get the feel for the acceptance of the customer’s players, you cannot bridge with them and build them as champions. And last but for not least, you are missing an opportunity to understand the “real” hard facts of what is going on. People lower in the chain intend to be more honest!
7. • No echo back meeting on POC findings to management is organized
   • This is a great opportunity to see your customer in action. The POC attendees are presenting back to their management on what they learned on the POC. This will allow you to learn spot your technical champions and their counterparts in management, which you as sales person can then engage with, if you haven’t already.

In the POC Stage, you will find the following qualifiers and milestones by default:

C – Who are you competing against? What are your competitiors strengths and weaknesses? What is your strategy to beat them?

Why Do Anything?

See The 3 Why’s section for more information

POC

See above explanation