GE 26: Proof of concepts

A proof of concept allows a customer to try your product before fully committing to buying, implementing, and using it for real. Free versions of products are commonplace when subscription costs are low, but what about high contract value Enterprise SaaS software products?

These products can take significant time and resources to set up, configure, train users, integrate with other systems, and optimize to deliver a positive experience.

So, should you offer a proof of concept? And if so, should you charge the customer for the privilege of evaluating your product?

The decision to provide a proof of concept option depends on several factors:

1. Setup and Configuration: Can your product be set up and configured to a customer’s requirements within a reasonable amount of time, say a few days at most?
2. Customer Experience: Is the customer likely to have a positive experience within a proof of concept timeframe, which must be measured in weeks, not months?
3. Resource Availability: Do you have the resources and the appetite to provide attentive setup, service, and support during the proof of concept period for multiple evaluations? Can this support be provided without degrading the service of paying customers or committed opportunities?
4. Return on Investment: Can you ensure a return on investment? In other words, is there an increased win rate for customers who successfully complete a proof of concept versus those who do not? Does the eventual aggregate contract value justify the extra load on resources?
5. Competitor Practices: Do your competitors offer proof of concepts? How comfortable are you with the chance of leaking intellectual property or other confidential information to firms that evaluate but decide not to proceed?
6. Deal-Driven Development: What is your policy on allowing deal-driven development? Are you willing to adjust your roadmap to accommodate proof of concept feedback?

My experience is that proof of concepts can increase win rates, help differentiate against competitor products, and fast-track an eventual implementation. However, they must be designed with specific parameters in mind and be tracked and measured carefully.

Here are some recommendations for designing a proof of concept program:

Align on the Proof of Concept Goal

Ensure you have full agreement on the goal of the proof of concept. Present an outline of the proof of concept plan (see below) and do not proceed if you cannot reach an agreement.

The danger is that a customer (or an individual evaluation member at a customer) may view the proof of concept as a product development procedure. Instead of evaluating the product, they meticulously record a long list of requirements, enhancements, and must-have additions, setting an expectation that these must all be included before go-live.

Of course, there may be genuine gaps, but they should be the exception and follow a defined process for evaluation and negotiation.

Develop Your Own Proof of Concept Playbook

You must have a plan for your own proof of concepts including:

• The duration of the proof of concept
• Prerequisites to start a proof of concept
• Resource requirements from the customer
• A set of predefined recommended activities and goals that should be completed within the product
• A schedule of activities including setup, training, testing, and wrapping up

The goal of the proof of concept is not to test every feature and function in the product nor confirm with 100% certainty that every possible goal, aspiration, or future idea of the customer can be supported. The goal is to provide a general hands-on overview of the product and solution and to trial-run working in partnership with the customer to achieve a mutually beneficial outcome.

Stay Hands-On

The worst thing you can do is to email over the product credentials to your potential customer, leave them to it, and check back in four weeks. Instead, you should always have a proof of concept kickoff with the actual evaluation team. Understand their goals, preconceptions, and allegiances if any. Then schedule regular check-ins—at least weekly and more often if needed.

This is especially true if the same firm is running multiple evaluations with different vendors or if an internal team is also pitching to build a solution instead.

Be responsive to questions and have a strategy for resolving difficulties. Try to resolve issues as you go rather than documenting and saving them all up in an ever-increasing list. Be attentive and responsive, but don’t overstep and start managing every aspect of the implementation. For example, don’t write the minutes for meetings or the work schedules or lists of requirements that have been met or not met.

The customer should execute their own evaluation in the way they see fit as long as they are hitting all the main milestones in your proof of concept plan. If they want to do a lighter touch evaluation without reams of documentation, that’s fine—don’t force them into your process. Equally, if they want to do a scientific product-by-product comparison, don’t fight it—get involved, support supplying the right data, but be attentive to false assumptions and comparisons.

Assemble the Team

Your proof of concept support team should be cross-functional, including pre-sales, professional services, support, infrastructure, and product management. Bring in the right people at the right time and even find excuses to make key introductions.

Remember, the evaluation is as much about road-testing ways of working and depth of expertise as it is about testing product functions and capabilities.

Make sure the proof of concept team is collaborating and has a shared documentation and notes platform. Everyone needs to be on the same page, providing the same messaging, and needs to be aware of any identified strengths and weaknesses.

An account manager or similar role should check in occasionally so that the customer can speak freely without feeling they are upsetting or offending the day-to-day proof of concept support team.

Handling Exceptions and Gaps

Every proof of concept will likely generate some aspects that the evaluation team doesn’t like or prefers a competitor’s approach on. Different companies will have various policies on how to handle these situations. This ranges from not entertaining any deal-driven development to negotiating customer development and everything in between.

The important thing is to have a predefined process that everyone understands and agrees to. Avoid putting every suggestion and enhancement on a “To Do” list, but large obstacles significant to decision-makers must be dealt with head-on.

Consider the size of the contract, the chance of success, and the opportunity cost of diverting resources when making the decision to support delivering a request. If possible, try to ensure that there are no development requirements that are prerequisites to going live with the product. After all, you already have hundreds/thousands of existing users who are living without the identified capabilities that theoretically solve the same problem.

Integrate Scope and Pricing Negotiation

Do not let the pricing negotiation become detached from the discussions around scope. In addition to allowing a customer to evaluate you and your product, your teams should also be evaluating the customer to assess the cost of implementation and ongoing service. What resources will the customer allocate during implementation? How complex will the configuration be? Will we need to do any development? Are there any other red flags?

All of these factors need to be rolled into the final pricing discussions, especially if there are accelerated development or custom development requirements.

Ensure There is a Formal Wrap-Up

Irrespective of how the proof of concept draws to a close, ensure there is a formal wrap-up. If the proof of concept has been successful and the customer proceeds to contract, ensure that all of the materials produced and the learnings that occurred are collated and passed to the implementation team. Ideally, someone involved in the proof of concept should be a member of the eventual implementation team.

If the proof of concept was not successful, ask the evaluation team for a quick product or process-focused call to understand their decision process and identify any areas for improvement. Ideally, this step should be written into the proof of concept agreement to ensure that it always occurs.

Implement Product and Content Analytics

In-app product analytics solutions such as WalkMe and Pendo can be used to monitor evaluation progress and depth. In-app training guides can also help guide evaluation users through predefined positive experience routes through the product.

Also, consider tracking proof of concept support materials such as training videos, how-to guides, and checklists. Monitoring this type of activity will tell you how engaged the evaluation team is and ensure that key decision-makers are hitting all the areas you want them to see and experience.

Charging for Proof of Concepts

There are three philosophies when it comes to charging for proof of concepts:

• Free: The customer doesn’t pay for proof of concepts at all. The vendor bears the full cost on the basis that they see a sufficient uptick in win conversions following the proof of concept and the contract values and terms pay for the increased resource requirements.
• Paid but Refunded: The customer pays for the proof of concept but gets refunded if they decide to proceed. This model acknowledges the cost of providing a proof of concept and attributes a value to it. This provides some protection to a vendor if the proof of concept is not successful and can help the vendor fund increased resources and create dedicated proof of concept materials.
• Paid: The customer pays and is not refunded irrespective of the outcome. The vendor aims to generate income from proof of concepts at least to cover the costs and in some cases to generate revenue that can be deployed for growth initiatives.

My personal preference in most cases is to offer proof of concepts for free to qualified prospects, with strict guardrails and close performance monitoring. However, there are exceptions, and it may also be possible to offer all three models using different qualification criteria.

Performance Monitoring

Keep an eye on the performance of your proof of concept program and revisit it at least every quarter. You should be aiming for a 75%+ win rate from customers who enter a proof of concept. If the figure is lower, then check your entrance criteria or competitive intelligence. Do not be afraid to pause your proof of concepts if they are just not working for you. You can also revisit them at a later date.

In summary, proof of concepts can be an important part of the Enterprise SaaS sales process. However, they don’t make sense for certain products, need strict guardrails, and require careful monitoring. By aligning on goals, developing a clear playbook, staying hands-on, assembling the right team, handling exceptions, integrating scope and pricing discussions, ensuring a formal wrap-up, implementing analytics, and deciding on a charging model, you can effectively leverage proof of concepts to increase win rates and differentiate your product in a competitive market.

By following these guidelines, you can make informed decisions about offering proof of concepts and manage them in a way that maximizes their benefits while minimizing potential drawbacks.