SaaS Product Demo Environments – A Maturity Model
How did I collect this information?
Before launching Reprise I conducted 200 ‘product-market fit’ interviews. I went outbound to my extended network on LinkedIn and asked for your time. I did brief introductory calls where we started with a demo and ‘problem statement’ –
“Your CTO won’t build your demo environment and you can’t build it yourself.”
I asked you to help me understand your current state and how you arrived there. My goal was to understand how a typical SaaS company’s demo matured over time, as they grow and scale.
On these calls, the kindness and genuine interest from the market enabled me to really dig deep into the current state, before we would try to advise on the future state. This blog is a cheeky look at the current state of demo environments — what do we demo, who builds it, and the various points at which we upgrade our demo.
Take a look. Does this resonate with you?
Trends We See
- The demo might be one of the last untouched frontiers in your go-to-market stack.
- We’ve noticed that companies do not invest in a demo until it’s too late.
- And when they do, it’s then human capital rather than technology that is thrown at the problem.
As we often see in SaaS, with demos a lack of planning ahead leads to more expensive problems later. Most of the teams I met shared that they don’t have a formal demo process today, don’t have a path or project to create one and don’t even have a recognized ‘owner’ for their demo environment. However, this lack of foresight doesn’t mean the problems aren’t predictable. In fact, the trends are clear across industry, vertical, and company size. These are the patterns we found:
At the seed stage, the company is lucky just to have a product that works! You are focused on the baseline feasibility of your tech and not spending those precious engineering points on sales and marketing assets like a demo.
At a seed-stage startup, the rate of iteration is so fast that you’d never keep a standalone sandbox or demo environment up to date even if it did exist.
The sales team at this stage is just one of the founders. You’re still discovering the messaging and value prop. You don’t need scalability, and in fact you wouldn’t know what to scale anyway.
There’s something endearing in a scrappy startup that dogfoods its own product live, as a buyer. it’s a huge red flag if you can’t even close a deal with yourself.
So the demo environment? It’s production data, and if you had a legal team, they’d be holding their breath the entire time. It’s super dicey with continual product changes and probably against your ToS. It’s a necessary evil but like every other part of the seed stage, you are living on borrowed time.
When do startups build an anonymized sandbox for demos? Typically after getting in trouble for showing the wrong info on a live call! (Or you’ve got an exec with a memory of getting burnt on this at a previous company.)
So, you anonymize your own data or a customer’s data. You create a demo instance with a cool, funky name like “Demo1” and you’re off to the races.
Or so you thought. To get to the race you realize you have to solve for time series data, the overcomplexity of database schemas, persona tailoring, segment-specific data sets, and multiple reps living in (breaking) one demo instance…I’ll build a complete list of ‘sandbox gotchas’ someday, and then you can spend the rest of that month reading it.
The demo sandbox works, sort of. It took 3x longer to build than you thought and now takes 9x more effort to maintain than you thought. Your small sales team feels like it’s something you endure rather than benefit from.
Big companies have big budgets. You’re enabled with technology and headcount to address ‘force multiplier’ projects. Headcounts like sales ops, sales enablement, and other overlay roles arrive at this middle stage.
However, when it comes to technology, you don’t have an option in the tech stack. In fact, there’s no tech stack for the Sales Eng function at all. Think about that — we hire BDRs that are an average of 5 years more junior in their career than a SalesEng, make about 65% of the OTE of a sales eng, and last an average of 9 months before turning over. That team gets a stack of 3-5 products: Outreach or Salesloft, LinkedIn Nav or ZoomInfo,’ and the list goes on.
But the Sales Engineers? Oh, they just manage the most technical and difficult part of the sale, move across departments more than any other player on your team, and are expected to be hybrid or multitool players. But there’s not a single piece of technology in your revenue stack that you bought for them? This is a wild, wild blind spot.
At the growth stage, you have acute pain with scaling your demo. But you’re throwing humans at it.
You think this is the stage where the magic happens and your SE team transforms your patched-together demo environment into a beautiful butterfly. Your sales team lives happily ever after, using tailored interactive product demos to close deals at ever-increasing conversion rates.
Instead, think of the moths from Silence of the Lambs. Your beleaguered SE team is struggling with an underinvested demo environment. You have no control over changes or quality.
Maybe you work around the demo issues by having SEs do the demo since they know how to navigate around the potholes. But you know that’s an expensive fix because you’re deploying 2x the human resources. Plus, the SE teams aren’t part of sales training or the closed-loop sales/marketing meetings.
Now your SE group has ballooned to >100 humans, you’ve got demo instances in multiple stages of undress or stored in multiple places, and there is no consistency or control to your demo! Welcome to the butterfly garden, the rules are that you pretty much just flutter around and do whatever you want. K, bye!
Yes, this post was meant as a joke. No, I don’t think it’s this bad everywhere. I’m just making a point with the hope that it generates a discussion. What are you doing about your demo environment? Should I reserve you a spot in Butterfly Garden?