Thoughts on Demo Engineering
What is Demo Engineering?
Demo engineering encompasses the creation, delivery and support of demonstration environments and assets to support presales and other internal and external groups that leverage product demos. By using a dedicated team to create and maintain reusable and bespoke demo assets, the presales team has considerably more bandwidth to support field-facing activities.- Factors to Consider When Building a Demo Engineering Function
Read on to learn why you should care about this function, and my personal experience with it.
Why should you care?
Preface (opinion): This function typically only applies to SaaS (or on-prem) platforms with many features, integrations, and/or complexity.
As a company and product grows they will continue to become more complex. That complexity requires broad and deep working knowledge to piece together over-arching or specific (persona, vertical, segment, etc) demo environments. Putting these demo environments (infrastructure, custom software, third party software, SaaS products, etc) together, and maintaining/enhancing them, is a very time consuming task. With growth a specific role's capacity (e.g. Pre-Sales Engineer) for "free time" (e.g. building demo environments) greatly diminishes, and there is never any time to monitor and remediate systems that are not their primary focus. Demonstrators will come to rely on these haphazard systems and inevitably they will fail in one way or another.
You hired your pre and post sales engineers, customer success, product, technical account managers, support, account managers, advocacy, documentation, engineering, marketing, etc teams to execute specific functions as quickly as possible. In the case of the pre-sales engineers: land new deals and logos bigger than before. They should be wholly focused on these efforts, not slapping together software, systems, integrations, infrastructure, etc in the days and hours leading up to a huge demo with a Fortune 100 prospect. Nor should they be worried about the stability of these systems over time, their uptime, bugs, necessary updates, etc.
Demo Engineering does that. It acts as a company within your company; working along side all those aforementioned constituents to build a world-class set of demo systems. Demo Engineering is a partner to nearly every team and function within a company; building and enhancing as your product grows, monitoring those systems to ensure their uptime and functionality for an ever-growing world wide sales, marketing, advocacy, and demo force.
You need this team much sooner than you think. Left unchecked a ball of mud will emerge that is hard to reverse. Worse yet you lose potential business due to lackluster or downright bad product demos. Starting late in the game and breaking demo practitioners away from old habits and systems is hard. I've been there and done that. Start early and enable your teams with reliable environments that can be used for marketing materials, demos, documentation, trade shows, debugging, testing, implementation examples, advocacy, etc.Why Demo Engineering, why early?
You should treat Demo Engineering like you treat Engineering Effectiveness. For every ~25 pre/post sales engineer (and perhaps product managers and product marketers) you should have one demo engineer to be effective. If you short staff this area, it will lead to issues; ranging from tech debt to burnout, both which are hard to recover from.
Here are a few articles on demo engineering and why you should invest in such a team:
- Reprise: The rise of the demo engineer
- Navattic: What is a Demo Engineer?
- Reprise: 3 reasons you need a demo engineering team now
My journey to Demo Engineering...
I started the Demo Engineering team at Datadog, but before that I was a software engineer on several small teams building tools that others used. I was also product manager for those tools for a brief time. In those roles I often had to give demos for the products I was building. This often meant generating and seeding data, creating believable fake, mock, and sometimes real environments connected to other systems. I do believe this is part of the job of a software engineering team, you don't need a dedicated team to help with this (though in my time as a Demo Engineer I helped many software teams test their new products and features with my demo environments), but my next role showed me a different side of the tech business I wasn't familiar with.
I joined Datadog in 2017 as an Enterprise Pre-Sales Engineer on a relatively young team (I was part of a cohort with other SEs that were the 6th through 10th members of Sales Engineering at DD). My background made me a strong candidate for the role. What I found once I was in the day-to-day, along with my peers (who were also new to the SE role and had backgrounds similar to my own), was that we needed to build out our own environments and data sets for use in our demos.
While my peers and I were able to find the time to cobble together small scale demo solutions, it was not tenable. We could not keep pace with product growth, our day jobs, and the persona or industry vertical scenarios we needed to sell to certain prospects. Not to mention any customization that we might need to match a prospect's technologies. We also had no time to properly monitor these systems, fix bugs, or remediate runtime issues w/o putting in long hours. And as time went on, other sales engineers, and other departments and groups came to rely on these systems. Without any true ownership or accountability this became wrought with issues.
I originally pivoted out of the SE role and into sales engineering enablement. Building tools, implementing solutions, improving process, cultivating a culture of visibility around product updates, fixes, new contributions, etc to accelerate time to value. This included the aforementioned "demo environments". I eventually asked for proper ownership recognition and a focus of duties in this area.
I spent the next four years building a team and systems that could be relied upon, that were up to date, monitored, and reliable. In 2021 those environments secured $400M+ in new revenue via Pre/Post Sales deals. The systems under my purview were used by product, software engineering, documentation, marketing, support, sales engineering, professional services, and many other teams for a broad variety of reasons, well beyond just demos. Demo Engingeering at Datadog was often one of the very first customers of new features and products, often helping find bugs, UX flaws, documentation/setup shortcomings, and environment issues that hadn't been considered.
Personal Opinions on Demo Engineering
- Demo Engineering should be very close to, or even part of your engineering organization. This team will face engineering challenges, will need to work with other engineering teams. They should be able to leverage the tools, practices, and expertise from those teams. Sales Eng is an okay fit to start, but ultimately it will lead to a divergence and lax engineering rigor that is hard to course correct at a later date.
- Demo Engineering should scale with the rest of the company. As product teams grow, as Sales Eng grows, so on and so forth, so should Demo Engineering. If left behind they will be inundated with requests, tech debt, bugs, and more.
- A demo engineering team requires technical leadership, but also one that understands their value at the company. There will be non-technical problems of course, but they will face engineering challenges just like product, infrastructure, compute, etc teams.