Proof of Concept

The Proof of Concept (POC) 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 quite an 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.

Major POC traps

The 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 yet defined well enough to prove that it works.

Many clients still ask to “play around” with your solution. Try to avoid this, as the client might be overwhelmed and confused after the “playing period,” especially with complex solutions.

If the client needs to learn more about your offering, you can offer demos, webinars and discussions about use cases and needs.

The Economic Buyer is not aware of the project

Especially in larger companies, make sure you meet the EB to get their 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.

Not all parties are invited to the POC

The POC is designed to be the last, ultimate proof point of the “technical” concept. If not all the departments needed are involved, you might end up running multiple POCs or, even worse, letting the competition run their own POC with other departments.

Make sure you understand who needs to be invited. The EB and Champion might help.

Poor preparation before the POC

The client did not set up the environment, and you waste valuable POC days on setup. Not all attendees have time to take part, or they move in and out during the POC, which means they might miss important parts.

• Make sure you have a complete list of attendees and ensure they have the time.
• Sometimes it is better to run a two-day POC with all attendees than a four-week POC with only some of them.

Use cases are not documented before the POC

A POC should have clearly documented use cases to be shown and checked off as positive on 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. Fewer use cases with more depth are better than the other way around!
• Try to influence the use cases in a way that makes your solution or offering shine!

Salespeople do not participate

Many POCs are run without the salespeople showing up. This is not good for many reasons. First, you cannot get a feel for how the customer’s players accept the solution, and you cannot build bridges with them and build them up as Champions. And last but not least, you are missing an opportunity to understand the “real” hard facts of what is going on. People lower in the chain tend to be more honest!

No Echo Back meeting on the POC findings is organized for management

This is a great opportunity to see your customer in action. The POC attendees present back to their management on what they learned in the POC. This allows you to spot your technical champions and their counterparts in management, whom you as a salesperson can then engage with, if you haven’t already.

Qualifiers and milestones in this stage

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

• C — Who are you competing against? What are your competitors’ strengths and weaknesses? What is your strategy to beat them?
• Why Do Anything? — See the 3 Why’s for more information.
• POC — See the explanation above.