Last week, I talked about making a trial/demo environment that let people imagine how software would work for their team. Today I want to explore what kind of data is useful in a team-product demo.

Consider setting

Because I’m talking to developers and decision-makers in noisy, chaotic, and distracting environments, I prioritize showing the every day use of a product. Setup is important, but it’s not the place you can usually show business value. When I’m demo’ing, I want to get to the “oooh” in under 2 minutes. And that means that I need to have a pre-configured application and environment. Because I was working with feature flags, it was handy to have some pre-configured flags, so I could, for instance, turn dark mode on and off, or show or hide a banner. The power of the product extends far beyond front end whizbang, but it gave me a little more time to explain that. I also needed to avoid entering any user data, because it takes time. My demo environment had a variety of users with different levels of access.

If you have more time, or are setting up a user-run trial, or recording a video, you can spend a little more time on setup, but again, the people who set up the software and the people who have it permanently open on their desktop are not always the same people. If you have a trial sandbox that you can spin up and run from a service like Digital Ocean or Glitch, you remove a lot of the friction that may stop people from their aha moment.

Consider function

Not your software’s function, your audience’s function. What people do for their job really changes what kind of demos and trials they want. A developer often wants to see how your software interacts with theirs. An operator wants to know how it will be installed and work with their existing systems. A manager wants to know what your software offers that makes adding another tool to the stack worthwhile. When you’re building trial and demo environments, work with your sales and marketing teams to be sure that you understand the audience’s you’re targeting.

Consider communication

Many people can read code, even if it’s not exactly “their” daily language. But it’s not usually their first language. Many people can read documentation, but don’t usually do it unless they need to. But almost everyone you’re talking to is familiar with front-end interfaces and diagrams. The more visual you can make your demo, the showier it is. Some people will want to dig into the details after seeing that, but that extended conversation is a win. Some people will be able to grasp what they need from some clear actions, diagrams, and animations. I’m not saying that you should replace your documentation with TikTok, but you should absolutely consider visual impact as part of your demo.

Include these elements

Here are some things that you should include as you’re building a demo environment or test environment:

• Architecture diagram – how this software relates to other pieces of the ecosystem
• Easy win – a single action you or the audience can take to make a visible change
• DEI – names, icons, and user representations that invite users to see themselves
• Documentation – if you need it, you want to find it easily
• Smooth data – the kind of data that the system was designed to use
• Ugly data – the weird kind of things that people actually end up with in a real system
• Security and compliance – how can people trust your software?
• Supported  integrations – will it work with what they already have? Prove it.

When you list it like that, it seems like so much work that will distract several people on the team, and will require maintenance. But it’s worth doing. It’s worth doing because the goal is to sell software, not just build it, and it’s worth doing because the people using it will be your best, most responsive, most effective testers. If there’s something wrong this environment, it will show up early, and someone will let you know.

I hope these thoughts help you build a robust environment that shows off the value of your product to all the members of the team you’re targeting. Let me know if you think I forgot anything.