Demo Environments
These are drawn from my experiences working for startup SaaS companies and are likely not applicable to larger organisations. I have had to balance company resources with best practices. Additionally there is always room to learn and grow so I will likely look back on these observations in a year or even a few months and have a different take. The feedback form at the bottom is always open and I would love to hear your thoughts.
Tailoring
The best indicator of success in a product demonstration is a prospect speaking about different ways they can utilise the product. To achieve this you need to personalise the product. The analogy I use for prospects who are adamant about an out-of-the-box demonstration is the new phone scenario:
If you needed a new phone, I could give you a fresh out-of-the-box phone, but wouldn't show you its full potential. Your current phone has your favourite apps on, your kids or dog as a background and personalised settings. While we can't fully replicate that level of personalisation, we can still make a product more relevant to you. Ideally, some example documents, workflows and hierarchies and a few days to configure it means we aren't wasting prospect time.
Audience Appropriate
Dependent and the technical aptitude of your audience you'll need at least two versions for demos; the bells-and-whistles version and the pared-down version. When your day-to-day requires strong product knowledge and technical aptitude it can sometimes be hard to take a step back and see how overwhelming the full product capacity looks to fresh eyes. Some prospects are coming from a background of paper trails and excel. So start simple. What would grandma see?
After that you can start delving into audience maturity. The complexity of their existing processes. For an established company with fully developed departments, they will need current processes replicated but with the ability to review and change. However, for a less mature company, they will want processes replicated but may be open to or actively pursue advice and consultancy on best-practice.
Industry-specific tailoring may involve research, but finding at least one common process or template to replicate makes all the difference. As I mentioned in my first section, the best indicator of success in a product demonstration is a prospect speaking about different ways they can utilise the product. Demonstrate that you have done your research and that you have proof-of-concept already built.
Data
Linking to the previous section, we've already established the importance of creating a custom environment but it does need populating. During demos you'll likely be creating records but in addition to that you'll need pre-created objects in progressive states of completion and preferably a backlog of records. If your product features analytics, then those records need to be accurate and preferably up-to-date. In an ideal world, I would be able to click my fingers and the time/date fields for all the records would roll forward every month or so to keep them current. I've previously used batch uploads, relied on custom screenshots of ideal dashboards, figma mock ups and I am always intrigued to hear about companies demo record options.
Data cleansing is vital and should be automated where possible. If we're entering personalised data for prospects, the next person to log into the demo site should not be shown all of that information. When I've worked with manual data hygiene, I've needed to create checklists and conduct audits.
Separation
Demo environments should not be the dev teams playground. We need different sandpits. Otherwise, someone's going to poke a sandcastle mid demo and Sales will have to freestyle and pull up backup video demos. I personally prefer to keep a shared calendar and an open channel of communication so no one is performing updates or bug fixes. Sales Engineers will be your cheerleaders for updates and fixes if you let us know in advance.
Continuity
Marketing has brand guidelines, Sales Engineers should have demo guidelines. This allows for continuity across the environment, especially when it comes to data entry. For example, an issue can occur if I'm using a title field for quantitative, barcode-like entries (so my records are called "WBS23445") but my colleague is taking a more qualitative approach and using descriptors. This would mean any listing page is going to be a mess, and any progressive demos that I step into for my colleague may be jarring for the prospect and the Sales team. In the data section I mentioned having records in various stages of completion; reason for this is that data entry is particularly boring to watch, so keeping it to a minimum during demos is a must.
Ongoing and Scheduled Renewal
The technology industry is constantly evolving, and as a sales engineer I am constantly asking "Is this the best way? How can I improve?". It's important to not only be innovating as you go, but scheduling deeper dives to prune the obsolete and allow room to grow. Yesterday's templates may not be relevant anymore, new legislation can mean new compliance measures and environments can stagnate. Writers are told to "kill your darlings" which means that elements you may have worked hard to create must be removed for the sake of your overall story, and I've found this concept is equally applicable to software.
Insights and peer review from across the company often gifts insight, marketing trends can lead to environment tailoring that pre-empts customer interest and equally sales or product can use demo environments as testing grounds.