How to seal a deal when the proof of concept goes wrong

Channel partners know their portfolios inside out; they specialise in devising technology solutions to real-world business problems. A proof of concept (POC) can showcase value to the customer – but what happens if the demonstration backfires?

Even if all goes well, a prospect might lose interest. What then?

Andy Brown, director of technical services for Advanced Solutions at distie Tech Data, suggests the fix is often understanding the true cause of disappointment. Typically a POC is either to prove the technology or to overcome an objection within the sales cycle.

"It's more difficult for us to stand something up to prove a performance, especially in a demo or testdev kind of environment," he says. "Many outside factors affect performance. So it may be measured more in terms of the commitment we can make."

A vendor or partner that has done their homework at the start is much less likely to need to tackle a hesitant prospect. This means taking a measured approach that includes outlining the POC and agreeing success criteria with partners, distributors and vendors as well as the end customer, he says.

Where possible, key achievable metrics with a timeframe should be included; it's harder to argue with a spreadsheet.

Investigate, ask more questions

After that, if a customer still has cold feet, ask for more information; a little sleuthing and lateral thinking can help mitigate further objections.

"The outcome ought to be at that stage defined within the POC: 'We've hit all of the objectives and successfully created resource outcomes. So what's in the way of you placing the order for that particular solution?'" says Brown.

"Re-convene the stakeholders that formed the original agreement. Say, 'look, the goalposts have moved'. Then try and work with the customer to understand why there's still that hesitancy."

The outcome might require more investment or certain changes. Outline the right levels of scale for each of the solutions involved, he says, and have good negotiators and pre-sales people to manage partner-customer expectations as well as marshal resources to suit.

"Typically, they would be somebody more senior within my technical teams, either a solutions architect or at consultative level, who's almost orchestrating the resources and owning the opportunity with the partner," says Brown.

The progress of the POC itself can encourage stakeholders to alter the project. During the process someone can see other aspects of the solution that they would like to incorporate – and the partner will also be looking to represent himself or herself as a trusted adviser.

"So the requirement hasn't shrunk, and it's not that the customer is nervous, or has cold feet. It can actually mushroom into a bigger opportunity, because the customer can see additional benefits through the POC process and its iterations – because it's typically two or three phases of redesign and testing until the customer has that confidence," says Brown.

The POC opportunity cost

US venture capitalists Sapphire Ventures surveyed 109 CIOs on startup POC practices in its CIO Innovation Index 2020. Ninety percent of respondents always or typically conduct POCs before adopting an emerging technology in particular – and most POCs with startups are not paid for.

Only 14% of respondents reported that most POCs resulted in an implementation – with production more likely if the POC process took less than three months, according to Sapphire – so the stakes can be high to get POCs right.

Roberto Hortal Munoz, head of innovation at RM Results, part of education-focused VAR RM, reiterates that POCs must address the right customer problem. Perhaps the problem has not been completely solved – or it wasn't even the right problem in the first place.

"Every now and then we may end up doing a proof of concept where we learn the customer is not as enthusiastic as they should be. The next step is to ask them why. 'Why' is such a powerful question," he says.

Solving for a deal is about getting much deeper into the conversation, listening closely to the customer and drawing them out to talk about any uncertainty or unexposed issues. So, once again, a solution requires people skills.

"I ask them to tell us how they experience things. Also of course there's a clear distinction between the end user, and the purchaser, and all of these scenarios. Sometimes, in our case, the school might not understand the value of a solution," Munoz suggests. "Sometimes what you think is not where the problem lies."

Making a connection

Working to solve problems for teachers affords an example. Marking papers can be made easier with digital technology – but when there are thousands of papers to mark, the task might also need to be enjoyable to some extent.

A solution that doesn't consider the connected and social aspects of the problem might be elegant from a technical perspective but not make the customer happy, suggests Munoz.

A technology solution might not connect with the reasons the teacher marks the papers, which typically is because of care for students and their futures.

"So what we need to do is help them actually solve an associated problem: How to take less time doing the things they enjoy less. For example, photocopying," Munoz says. "Or you might find that only 27% of teachers are confident using the technology."