5 Best Practices for Virtual POC and Sales Demo Environments

When it comes to software sales and technical and developer marketing, demos and proof of concept (POCs) have long been used to showcase how a product works and outline the benefits. 

Virtual POCs and sales demos can both be used during the software purchase process, but they often have different use cases and audiences and are better suited for certain parts of the process. 

Normally, software salespeople present demos to (often non-technical) users from the C-suite and management to help them understand what a product or service can achieve under a normal use case. Developers will not normally be interested in sitting through demos where they watch someone else use the product instead of getting hands-on. That’s why they favor a POC.

A virtual POC is a key part of the developer purchase journey as it ensures they have the tools they need to be able to convince management of its long-term value. If you don’t offer a virtual POC — or it’s not easy to spin one up — then developers could fall out of the funnel and find another solution. 

Below we’ll explain how to use virtual POCs and sales demos to best effect during the purchase process. 

1. Understand When to Provide a Sales Demo

In the business-to-developer (B2D) purchasing journey, developers and buyers have different needs and ways of consuming information throughout the process. As the software sales process is increasingly transforming from a top-down to a bottom-up process, you need to understand when to use a virtual POC and when to use a sales demo during the different stages of the journey and who to target with each one.

A sales demo is useful for delivering a lot of information to a prospect in a short amount of time and requires a lower commitment from both the vendor and buyer. It’s a good way to get prospects thinking about what your software can do for them, understanding their unique needs, and how your product is different from competitors. 

They are useful if you are targeting a non-technical audience who wants you to show them how the product works, rather than having to figure it out for themselves. This could be early on in the purchase process, or it could be after the developer has tested the product and recommended it to the buyer.

But pre-recorded, static demos are not normally used when marketing to developers, as the more technical audience prefers to try out the product themselves, rather than listening to sales engineers explain it to them. 

During the awareness stage of the purchase journey, you need to provide frictionless access to your product if you want to keep developers in the funnel. If developers sign up for your product, they will disengage as soon as they realize that they need to attend a sales demo before they can try your product. 

2. Provide Software Sandboxes

A developer needs a sandbox environment to try out your product so they know if it merits them building their own virtual POC. They need interactive product learning experiences that let them try out your product in real-world scenarios that they will encounter on a day-to-day basis. They also need to be able to demonstrate how your product works to the buyer to gain their approval.  

Hands-on software sandboxes will also ensure that they get a learn-by-doing environment that lets them analyze your product to determine if it solves the problem they’re working on, or delights them enough to justify using or buying your product.

3. Remove the Blank Slate Problem

You need to make it as easy as possible for developers to set up a virtual POC and to be able to see and show its value quickly. So if they spin up a trial of your product to create a virtual POC, but there’s too much effort to use it (e.g. needing to import sample data or configuring its settings), they may move on to an alternative product. This issue is known as the blank slate problem. 

The blank slate problem refers to when developers sign-up for a sandbox environment as part of the virtual POC only to find that the environment is completely blank. Before they can see your product’s value, they have to spend hours creating and importing dummy data, configuring your product’s settings, and understanding how it works. 

Instead, you need to provide a sandbox environment for your virtual POC that comes pre-populated and pre-configured to ensure that developers can quickly experience and demonstrate the power of your products without having to do too much heavy lifting on their end. 

4. Offer Resources to Help Build a Virtual POC

Even if you provide a sandbox environment that is pre-populated with data, you can still lose developers if they don’t have learning resources that explain how to use the product to solve their problems and create a virtual POC. 

Developers need to be guided along the process of creating virtual POC with useful tutorials, code examples, documentation, courses, and labs. You need to create an effective and well-tested developer education program that provides stepping stones to keep them engaged and to ensure they can achieve all they need to by themselves, rather than having to ask your support team for help. 

To educate themselves about your product, developers need to read copious amounts of uninterrupted, continuous documentation. Consider adding interactivity to your developer documentation with:

• Live API calls
• Videos
• FAQs
• Discussion forums
• Sample code

By turning your existing developer documentation into immersive, educational experiences, you can help developers increase their usage of your product and enable them to build more applications, which boosts the effectiveness of their virtual POC.

5. Choose the right Virtual POC software

Selecting the right virtual POC software will enable you to provide users with an immersive experience where they get hands-on, real-life experiences that allow them to build a business case for implementing your product. You should look for the following when selecting this software: 

• Fast spin-up times
• Efficient cost and pricing structure 
• Launches a reliable environment
• Scalable
• Ability to tailor and personalize the environment
• Accessible from anywhere
• Provides an isolated environment
• System agnostic
• Provides in-depth analytics