{"id":6695,"date":"2019-08-03T15:16:00","date_gmt":"2019-08-03T15:16:00","guid":{"rendered":"https:\/\/greatdemo.com\/?p=6695"},"modified":"2023-01-26T15:32:03","modified_gmt":"2023-01-26T15:32:03","slug":"a-perfect-demo-environment","status":"publish","type":"post","link":"https:\/\/greatdemo.com\/a-perfect-demo-environment\/","title":{"rendered":"A Perfect Demo Environment\u2026"},"content":{"rendered":"

Have you ever heard (or said):<\/span><\/p>\n

\u201cSorry, I don\u2019t have an example like that in our demo system\u2026\u201d<\/span><\/p>\n

\u201cNo, we can\u2019t show that workflow \u2013 this is a demo database\u2026\u201d<\/span><\/p>\n

\u201cOur demo environment isn\u2019t up-to-date \u2013 that\u2019s why this feature isn\u2019t working\u2026\u201d<\/span><\/p>\n

\u201cNo, I don\u2019t have good data to show in this report \u2013 no data, in fact \u2013 sorry\u2026!\u201d<\/span><\/p>\n

\u201cThat report hasn\u2019t been built for our demo system \u2013 but trust me, it\u2019s terrific!\u201d<\/span><\/p>\n

In your demos, how often do you find you are apologizing for an inability to demonstrate capabilities, complete workflows, or present compelling results and reports?\u00a0 Far too often, in many cases!<\/span><\/p>\n

A perfect demo environment enables you to show what you need to show, clearly and convincingly.\u00a0 No apologies, no excuses.\u00a0 Accordingly, here are some recommendations for demo environments to make your demos as crisp, compelling and successful as possible.<\/span><\/p>\n

Don\u2019t Call It \u201cDemo\u201d<\/strong><\/span><\/p>\n

One of our objectives in a software demo is to \u201csuspend disbelief\u201d.\u00a0 Anything that looks real helps our cause; anything that appears fake is going to hurt us.<\/span><\/p>\n

In spite of the fact that we teach \u201cdemo\u201d skills in our Great Demo! Workshops, and in spite of the fact that the customer has asked<\/em> for a \u201cdemo\u201d, I recommend avoiding the use of the word \u201cdemo\u201d in, well, demos\u2026\u00a0 And, in particular, in demo environments.<\/span><\/p>\n

Why?\u00a0 Because customers unconsciously translate the word \u201cdemo\u201d to mean \u201cfake\u201d.\u00a0 If it is a demo<\/em> environment, then it is not real, from customers\u2019 perspective.\u00a0 Anything done in a such an environment is suspect, accordingly!<\/span><\/p>\n

So, don\u2019t call it your \u201cdemo\u201d system or \u201cdemo\u201d environment or similar.\u00a0 Instead, give it the name of a fictional but plausible customer or other realistic-sounding option.\u00a0 (\u201cApex\u201d is an example we used long ago\u2026)<\/span><\/p>\n

And Don\u2019t Label Things \u201cDemo\u201d<\/strong><\/span><\/p>\n

Similarly, anything labeled \u201cdemo\u201d in your (ahem) environment causes the same result.<\/span><\/p>\n

File names, module labels, login names, forms, dashboards \u2013 I\u2019ve seen all of these emblazoned with \u201cdemo\u201d in one form or another.\u00a0 All of these subtly scream \u201cfake!\u201d to our customers.<\/span><\/p>\n

Again, use a neutral name or naming convention that looks like a real customer.\u00a0 Much better!<\/span><\/p>\n

No Obviously Fictional Names<\/strong><\/span><\/p>\n

Similarly, when a customer sees the names of famous characters in your demo environment, this also says, \u201cThis is fake!\u201d to customers.<\/span><\/p>\n

I recently saw a vendor that used the actors\u2019 names from the full Oceans XX series of movies \u2013 including George Clooney, Brad Pitt and Julia Roberts (the original cast) plus Sandra Bullock, Cate Blanchett and Anne Hathaway \u2013 all of these names were in the vendor demo database.\u00a0 I\u2019ve also seen sports figures, important scientists, authors, and more.<\/span><\/p>\n

Perhaps it\u2019s easy to remember the names, but they communicate \u201cThis is fake!\u201d to customers.<\/span><\/p>\n

Instead, use realistic names, addresses, and other data.\u00a0 One simple solution is to use the real names from your organization \u2013 that\u2019s an improvement.<\/span><\/p>\n

A great source for convincing, dummy data is to use the databases and data sources created and used by your own organization\u2019s QC team.\u00a0 After all, your QC folks need realistic data sufficient to explore a broad range of testing scenarios (hmmm \u2013 potentially very similar scenarios to what you need to demonstrate!).\u00a0 A few example sources are DTM Data Generator<\/a>, SQL Data Generator<\/a>, and Mockaroo<\/a>.<\/span><\/p>\n

Include Problems, Exceptions, and Opportunities<\/strong><\/span><\/p>\n

Status quo<\/em> is boring.<\/span><\/p>\n

I\u2019ve seen countless demos that present a dashboard or report that shows everything \u201clooking good\u201d \u2013 everything is \u201cin the green\u201d, without any problems or concerns.\u00a0 This is pointless.\u00a0 You need to show that your tools can find<\/em> the customer\u2019s problems and that your software can directly address those problems or enable solutions.<\/span><\/p>\n

The most compelling demos show examples of how customers can solve their business problems, address outliers and exceptions, and surface and exploit opportunities.\u00a0 This means that your demo environment needs to include good instances of these with good example data.<\/span><\/p>\n

Problems should be uncovered and presented clearly \u2013 and provide opportunities for alerts to be generated and sent from your system (just like a customer would use it).<\/span><\/p>\n

Exceptions should be similarly discoverable \u2013 with the appropriate data to explore and determine how to address (just as a customer would investigate).<\/span><\/p>\n

Opportunities should be readily surfaced and exploitable (just as a customer would pursue).<\/span><\/p>\n

The more realistic, the better\u2026!<\/span><\/p>\n

U.S. vs. International<\/strong><\/span><\/p>\n

When I was banished overseas (to Switzerland \u2013 tough duty), I realized that our demo environment was entirely U.S.-focused.\u00a0 This can be a big \u201cfail\u201d for non-U.S. customers.<\/span><\/p>\n

U.S.-based companies often use demo environments that show U.S. maps, list U.S. cities and addresses, U.S. telephone numbers, U.S. currency, U.S. ZIP codes (even the use of the term \u201cZIP Code\u201d is an example!), U.S. product names and more.\u00a0 This can be semi-insulting to non-U.S. audiences \u2013 and it won\u2019t help your cause.<\/span><\/p>\n

If you want to sell in Europe, make sure you have Euros, European addresses and postal codes, telephone country codes, and all of the other units and measures that are used in your target countries and markets.\u00a0 (Furlongs per fortnight is one of my favorite arcane units\u2026)<\/span><\/p>\n

Want to sell into the UK or other English-speaking (but non-U.S.) counties?\u00a0 You may also need to use their local version of English spellings and vocabulary.\u00a0 Now that<\/em> box is ticked\u2026<\/span><\/p>\n

Launching into Asia-Pacific?\u00a0 Same guidelines.<\/span><\/p>\n

You don\u2019t support local languages in these regions?\u00a0 You may want to rethink your strategy\u2026!<\/span><\/p>\n

Very simply, we need to have region-specific data (as appropriate) if we want to build a vision for customers of using our tools in the region(s) in which they<\/em> operate.\u00a0 [And, to be fair, if you are a non-U.S. software company seeking to enter the U.S. market, the same guidelines apply to you as well\u2026!]<\/span><\/p>\n

Market Alignment<\/strong><\/span><\/p>\n

Have you ever seen a demo presented to a large construction firm that used example data from the banking industry?\u00a0 (I did \u2013 it failed\u2026)<\/span><\/p>\n

Best case:\u00a0 your data, vocabulary, use-cases and demo examples match the customer\u2019s specific market or vertical.<\/span><\/p>\n

Next best:\u00a0 your data etc. are close enough<\/em> to the customer\u2019s specific market that the customer can make the connection.\u00a0 Note:\u00a0 it is the customer<\/em> who decides if your data is \u201cclose enough\u2026\u201d<\/span><\/p>\n

Generally insufficient:\u00a0 your data etc. doesn\u2019t bear any resemblance to your customer\u2019s market \u2013 you are asking them to make too large a leap.\u00a0 (Disbelief is no longer suspended\u2026)<\/span><\/p>\n

Really bad:\u00a0 data that is obviously fake and<\/em> has nothing to do with the target market\u2026!<\/span><\/p>\n

One successful approach I\u2019ve seen is to have a fairly neutral set of data, but also<\/em> have the ability to configure or customize the screen labels, dashboards, forms and field names to map to specific markets.\u00a0\u00a0This may require some level of configuration or programming to achieve, but the payoff can be high.<\/span><\/p>\n

An additional note to consider:\u00a0 Customer Success guidelines suggest that the further your prospective customers are from your current, successful target markets, the worse the fit \u2013 and likely represent the highest risk of failed or unhappy implementations.<\/span><\/p>\n

Market Maturity<\/strong><\/span><\/p>\n

\u00a0<\/strong>Interestingly, customers at different stages of the Technology Adoption Curve will likely react very differently to demo data.\u00a0 \u201cTechnology Adopters\u201d and \u201cEarly Adopters\u201d are often very forgiving of the data that is used.\u00a0 \u201cEarly Majority\u201d customers may be reasonably forgiving, but the further you move to the right, towards and into the \u201cLate Majority\u201d the more they need to see their own data (or what appears to be their own data).<\/span><\/p>\n

Who Am I?<\/strong><\/span><\/p>\n

Logging-in as \u201cAdmin\u201d is another approach that yell\u2019s \u201cFake!\u201d to your audience\u2026<\/span><\/p>\n

The only people who login as \u201cAdmin\u201d in real life are, well, the system administrators\u2026!\u00a0 This is even more of an issue when vendors start talking about how \u201cthe system can be configured by role for end-users, managers, executives\u201d etc.<\/span><\/p>\n

Along similar lines, try to avoid obviously fake names, such as:<\/span><\/p>\n