One of the fundamental phases of selling technical solutions is the Proof of Concept (POC), an evaluation process that brings together buyers and sellers for a series of tests to validate potential solutions. However, what often starts off as a simple process can quickly unravel into a web of complexity and confusion. POCs aren’t anything new, so you might be wondering why everyone is so bad at managing them. Companies have been selling and helping buyers evaluate products for several decades; shouldn’t we have this all figured out by now?

Instead of evolving to match the modern buyer experience, most vendor organizations have stalled out or just completely given up, leaving a broken and disjointed experience that buyers are forced to live with each time they need to purchase solutions.

How We Broke Pre-Sales

We have seen an explosion of both technology and data in the past decade. Information about products, which was once tightly controlled by the vendor, is now available all over the internet. From blogs, to private communities, to review sites, buyers have a plethora of choices when it comes to investigating new solutions. Buyers have changed, but it seems that sellers are still stuck in the past. From complex internal sales processes to rigid POC motions, sellers are still very inwardly focused when it comes to engaging with buyers.

This has not only created resentment towards sales teams but also completely destroyed the buyer experience, forcing buyers to skirt all sales engagement unless they absolutely have no other choice. Can you really blame them? In a world where generic demos are the norm and POCs so often spiral out of control, it’s hard to think of any buyer wanting to commit people and time on something that can drag on for months.

We’d like to believe that not all hope is lost just yet, but before we set out to fix this broader problem we need to clearly define what exactly is broken. The challenges with pre-sales can be broken down into three key problem areas: naming problem, process, and collaboration. Let’s start with the naming problem first.

The Naming Problem: What is This Thing Called?

Shakespeare wasn’t too far off when he asked, “What’s in a name?” Regardless of what it is called, the purpose of evaluating a solution is to determine if it will accomplish the needs of the customer and for the potential buyer to get a feel for what the solution will be like to use. Today, the following terms are often used interchangeably, and even when delineated the definitions basically categorize the degree of tailored support and project management that will be supplied to the buyer:

• Trial

• Proof of Concept (POC)

• Proof of Value (POV)

• Pilot

• Technical Evaluation

The problem with this is that we have too many names for the evaluation process, and they each could mean something different to different people. Is a POC not providing value as well? Do we not also deploy and configure technology in a POV to see how things work? Aren’t Trials reserved only for SaaS-based solutions? As an industry, if we cannot agree on a singular term – or at least a clear set of differentiated terms – how on earth can we expect buyers to understand what we mean when we start throwing these disparate terms around?

While the name itself shouldn’t matter, expectations and outcomes should be very clear. When you are talking to a buyer about possibly starting a POC, do they know what that means? Will custom data sources be evaluated, or only demo data? Each of the industry-defined terms comes with its own set of assumptions. To prevent confusion, call your evaluation process what you’d like, but quickly follow up with what your expectations are and what outcomes your buyers can expect at the end of the journey. Emphasize the experience, and clarify if buyers will be able to come to a decision during that experience.

Side Note: While our belief is that the name ultimately doesn’t matter, it would be significantly easier if there were a single term used across the industry. For the purposes of this article “POC” is the simplest choice to discuss the technical evaluation process and everything that goes into it, but always use the term your customers most resonate with and accurately reflects the scope of work.

Let’s move on to the process problem.

The Process Problem: The POC Black Hole

Almost every POC begins with a single “kickoff call”, an arbitrary event on everyone’s calendar where buyer and seller huddle together to figure out what will be tested. Buyers have a rough idea of what they want to accomplish, but often have a hard time articulating their needs and considering elements of the bigger picture that they could gain along the way. Meanwhile, sellers are looking to move sales opportunities to the next stage in their CRM while trying to agree to the smallest amount of requirements possible to get through technical testing. Neither party is really on the same page or trying to achieve the same outcome, so the two parties are oftentimes already not off to a great start.

As the scope of the POC begins to take shape, a variety of tools are used to try and capture notes, various stakeholders, and the scope of the evaluation. This is often done in an inconsistent manner, decreasing efficiency and making repeatability impossible. Because there is no repeatable process, things tend to get missed during the scoping of the engagement. Stakeholders are left out, use cases are forgotten, and outcomes aren’t well defined. Furthermore, the lack of consistency in scope often leads to additional test criteria or additional parties being pulled in down the road (also known as scope creep).

Another downstream effect of unclear scoping is that a POC can become reduced to a technical checklist of features. While it is important to test required functionality, if the conversation is solely focused on features alone the business value of a solution quickly gets lost. This can also lead to competitive solutions being brought in simply to compare features and price; ironically, this usually doesn’t end well for either party.

If you’ve ever been involved in enterprise-level POCs, the lack of effective communication externally and internally is one of the biggest reasons why the POC itself can end up taking months to complete. The average POC in the enterprise segment can take anywhere from 9 - 12 months. Navigating what is essentially a POC “black hole” is complicated already in mid-sized deals, but becomes a near-impossible task when it comes to enterprise scale and complexity.

The final problem lies in transitioning a buyer from running a POC to onboarding them as a full-blown customer.

The Collaboration Problem: Getting Lost After the Sale

As a seller, one of the hardest tasks is asking a customer to renew their contract with you. It seems like this would be an easy thing: after all, they are already a customer, right? The problem lies in that most sellers believe their job is done once the sale closes. The contract is signed, the customer intends to use your solution, and everything is right in the world. But who hands over all of the information to the Customer Success team? What about the professional services folks that are to be engaged to get your solution deployed? The problem with stopping once the sale is done is that you create a “break” in the customer journey. If no one is there to continue the journey with your new customer, the experience becomes a mess. If this happens, chances are that this dissatisfied customer is not going to renew with you once the initial contract runs its course.

Successful renewals happen from the moment you finish a POC, get the verbal agreement to close a deal, and move towards a close. The documentation, handover process, and seamless execution between pre-sales and post-sales is so vital and cannot be understated. Sadly, too many organizations drop the ball when it comes to this level of planning and execution. Handwritten notes from the POC, important customer conversations, and deployment steps already taken are often excluded during the collaboration and handover process.

As some players both on the buyer and seller side fade into the background during the onboarding process, new players also enter the picture. These new players are often the key stakeholders that will be the operators of your solution and require more – not less – clarity and guidance on how to deploy and implement what they bought. This critical breakdown in collaboration between the pre-sales team and the post-sales team – both on the seller and buyer side – creates a bad experience all around, setting the stage for an uphill climb towards a renewal.

Finding a Path Forward

So far we’ve been focusing on the three core challenges with solution selling today. Now that we have a deeper understanding of the challenges we face, it’s time to define the best path forward. We start by reframing the goal of a POC to be: “a shared experience between buyers and sellers driving towards a mutually-agreed set of outcomes”. With this definition in place, how do we execute to make this a reality?

We can achieve this by defining five principles that all POCs should embody to ensure a successful outcome.

I - There Should Always Be a Success Plan

Nearly every successful POC over the past decade was rooted in a success plan that clearly outlines the who, what, where, when, and why: bringing all of these components together is the first step. Mutual participation and agreement between the buyer and seller is what underpins the creation, and ultimately the success of, the POC plan. A strong success plan will include stakeholders required from both teams, a timeline, outcomes the buyer is looking to achieve, specific use cases to test that map to each outcome, and technical requirements/components for the POC itself. Make sure to document any terms or nomenclature to ensure clarity on both sides throughout the POC process.

II - There Should Always Be Three Stages

Today, every single POC is run as a single phase inside seller CRM systems. However, POCs aren’t a single long phase. In reality, there are actually three independent phases that require definitions and measurements for each: staging, executing, and confirming.

The first phase is “staging”, where both parties prepare for the POC. Staging includes success planning, requirements gathering, discovery of current technologies in play, security requirements, and deployment of any technology in accordance with buyer governance standards. Staging can sometimes take a few weeks in big organizations with change windows and distributed teams.

The second phase is “executing”, where pre-sales teams lead buyers through the execution of each required use case. While some buyers will test and execute on their own, more often than not their workloads will require real-time sessions to collaborate and execute alongside the pre-sales team.

The third and final phase is “confirming”, where the technical evaluation is complete and the pre-sales team brings everyone together for a final readout of the data, the results, and the outcomes achieved. The ultimate goal for the seller is to confirm that, by hitting all required outcomes and success criteria, they are cleared to move forward towards a purchase.

Measuring the time in each phase will help sellers understand where the delays occur most as well as isolate the actual execution timeline.

III - Raise Risks Early (on Both Sides)

Not all POCs will have the same level of risk, but when risks are identified they should be called out as soon as possible. This includes risks on both the buyer’s side as well as the seller’s internal factors as well. Risks can be as simple as team members being out of office for two weeks, or can be more far-reaching and complicated (such as complex requirements like technical resources that need to be provisioned). Whether you evaluate risks manually or through tooling, know what they look like, how to raise the alarm, and how to suggest solutions.

IV - Business Outcomes First, Technology Second

Members of the pre-sales team are often seen as technical experts, but they are much more than that. From trusted advisors, to building business cases, to presenting in front of executives - pres-sales can flex both business and technical muscles as needed. Just remember: when closing out a POC and reporting to all stakeholders, make sure to focus on the business outcomes first and then on how technology enabled the win. Never the other way around!

V - Document a Clear Onboarding Plan

Creating a seamless experience from pre-sales to post-sales should be a top priority for organizations, and this starts with a clear, documented onboarding plan: what happened during the POC, what wasn't implemented, what was left untested, and how can you ensure a smooth handover from one team to another – these are all key things to write down. Measuring onboarding – and ultimately adoption – is something that has to be considered and captured during the POC in order to be successful after the sale.

Driving Towards Success with Opine

Discover how Opine can help you chart a better path forward for your pre-sales team and make an impact on your revenue goals today.