Navigating the Risks of POCs: Practical Tips from Experience

BEST PRACTICES DOCUMENT

POCs (Proofs of Concept) are frequently required, particularly at the early stages of a SaaS B2B startup with an Enterprise focus. To build confidence that you can solve a particular requirement you need to PROVE it. Failure to execute them successfully can represent a major setback, particularly when the lead is strategic.

The general recommendation is TRY TO AVOID them. Even if paid, they are risky, extend the sales cycle, and can be extremely expensive as they demand scarce resources from your team.

But we do not live in a perfect world, so we will assume that you have done your best to convey your compromise to deliver, but the prospect needs proof to move forward.

So let's start by classifying POCs into two groups

Trial of the solution with the prospect contextual data. In this case, the prospect wants to test drive the solution with familiar data. He is getting a flavour of the experience in a more familiar context, but also he is testing your ability to customise it to his reality.

Trial with the addition of features HE needs and is not in the product yet. During the evaluation process gaps were identified, and he expects to see the platform with the solution to these gaps already "working".

The first alternative is ok. If you know your prospect’s business you should be able to customise it with a marginal effort. Still, there is a certain set of good practices you should follow to maximize the chances of success and mitigate risks. We'll elaborate on this later on.

The second alternative is the one you have to think very thoroughly before committing. Coding features for a POC can be a very disruptive path. You might be developing features in a hurry, which quite likely were not a priority in your roadmap (if they were at all), and re-directing very expensive and scarce resources of your product and dev teams. Chances of poor experience, messing up with the rest of the platform, and potential frustration of the teams involved are high. Try to avoid committing development in a POC. Instead work hard on maquettes that show and validate the solution that is expected, and commit contractually to develop them at a certain date.

We have made these mistakes at my company, and seen it happen in many others. Alternative 2 is very risky, expensive, and can be a frustrating experience for all stakeholders.

Now, some general good practices for any POC.

At quantar, we use a template and a process for POCs that include:

Scope. Clear and well-documented scope. What needs to be proven?

Acceptance criteria. What is considered success?

Teams. Who is the sponsor and who leads the project on both sides?

Timeframe in a work plan, where both parties participate in milestones

Cost. Avoid doing POCs for free. The main reason is that if a prospect is not willing to pay for it, his commitment and time allocation is at risk.

Written. Take the time to define and write all these aspects in detail using the template as a base.

Simplicity. Keep it as simple as possible. Isolate the environment to a very simple use case. The longer and more complex the POC is, the higher the risk of things going south (long preparation risks momentum on the buyer decision, evaluation team might get lost if it is too complex, your time is devoured)

Account for effort. Keep a record of the actual time spent. Learn from each case. There is a tendency to underestimate the complexity of setting up a POC. The aftermath review of each case will provide useful insights to learn more about the next one.

In my experience, most of the POCs that fail are due to a lack of commitment and appropriate understanding of the prospect team during the process. Do not underestimate the lack of knowledge and will of your counterpart during a POC. if you have signed a POC with a key lead, take the client by the hand during his evaluation process. It's an all-hands-in-deck situation. Fluid and regular communication with the prospect team is crucial.

Finally, remember. A SaaS company sells products. Only "takes orders" when they enrich the platform for other users. Managing the roadmap involves taking careful decisions, and when done in a rush they can jeopardize the scale-up process of your company in the future. We will talk about roadmap management in more blogs, as it is one of the cornerstones of a successful scale-up journey.

Good luck with your POCs. You will need a little bit of that as well.