Design your PLG demo to deliver what the prospect is expecting
Part one of a two-part series on designing, building, and delivering the best interactive demo experience for your PLG-driven Saas business. Read: "Everything Starts Out Looking Like a Toy" #154
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? is a post that grew into Data & Ops, a team to help you with product, data, and operations.
This week’s toy: a kindergarten building shaped like a cat. The cat’s tail provides an excellent slide, making me wonder if return-to-office efforts might be more effective with improved design for office fun. If I had to work in an office, I’d rather work in one like this Github office. Edition 154 of this newsletter is here - it’s July 17, 2023.
The Big Idea
A short long-form essay about data things
⚙️ Demos reflect how you want to greet prospects
Here’s a story about product-led growth (PLG).
At a series A tech company, I wanted to build an interactive demo for a wide-ranging platform product that would help prospects learn more about what we could do.
The goal of the product: enable data and go-to-market (GTM) teams to unify the data in their go-to-market environments using a common schema of information, rather than creating a data model based on the data architecture of the tools they used like Salesforce.
The goal of the interactive demo: go beyond simple screen capture and let prospects try the product in the actual interface using simulated data, but not necessarily using their own data. At the end of the trial process, if they liked this demo we could convert their work into a real account and maintain the configuration they had started.
We thought that building a PLG motion would let prospects try before they bought, letting them engage with the basic features of the product and see how things worked to give them more context for whether the platform solved their needs.
In Part 1 of a two-part post, we’re going to look at the choices we made to identify our PLG process, how to optimize for building an interactive demonstration, and list our ideas for making the type of demo that best matches your organizational goals.
What does a PLG Motion do?
A classic PLG motion does the following:
Enables prospects to use a free (or time-limited free) account
Turns on almost all available features or uses a feature gate to disclose different tiers of the product
Once prospects engage, they have enough knowledge to make a buying decision
As a fallback, many products add a “free” tier to keep prospects in a nurture role so that the next time they have a need, they consider buying
PLG is tough when it comes to a wide product
Building PLG for a platform product is like putting together an IKEA product. It helps to have very detailed instructions, and they need to be assembled in the proper order.
One of the first problems we encountered with a wide product is that the prospect could do almost anything and it was hard to recommend a set of steps that would appeal to the average prospect in our Ideal Customer Profile (ICP).
GTM teams are action-biased. They don’t always pick the long-term solution for a problem when there is an immediate gain that will move the problem forward.
To appeal to this group, we wanted to limit the scope of our demo to a typical set of demo problems that would appeal to a GTM operator. We also thought they would abandon a demo if they didn’t understand what was going on fairly quickly.
Another goal of our demo was to make things as easy as possible, so we wanted to avoid the friction of authenticating systems, transferring data, and worrying about security.
What is a “typical set of scenarios” in a SaaS Product Demo?
Let’s take a step back for a moment to consider the components of a “typical set of scenarios” when building a product demo for a Software-as-a-service (Saas) product.
Reasonable problems to solve for a demo include:
Feeling close enough to the “real” experience to convey the feeling of using the software
Fast enough to try so that you get near-instant feedback
Not too frustrating so that you give up
Providing a path to learn more if you want to go deeper
Our experience crafting a demo journey went like this. First, we decided the general outline that we wanted the journey to be for prospects. We thought they should sign up, load some data into the platform, confirm it was loaded, and complete a simple data transformation.
By “simple”, the goal was to demonstrate that a single transformation could change a field, e.g. using Proper() to capitalize the first letter of a first name field for a contact.
The expectation was a “tell me”, “show me”, “let me try” series of paths where the prospect could select if they wanted to read information, see it demonstrated, or try the task in the context of the actual application.
This last point is particularly important because when you think about the combination of a time constraint and the difficulty of an introductory task, the prospect might not have enough time or interest to try things in the actual application. But if you could get them to do this, the leap to building their own use case is much smaller.
We initially considered a hybrid approach to the traditional slideware/demo approach because we weren’t sure whether demo products could deliver the kind of result we wanted: a place for prospects to take actual actions with actual (safe) data in the actual product.
The nuts and bolts of building an interactive demo
Here’s how we understood the larger task of building a demo experience.
First, we needed to learn a little bit about how modern demo products work. Then, we needed to evaluate the products we looked at in the context of your requirements. Finally, we were going to make a decision on using one of these traditional demo products or use another means to create an interactive demo.
Learning about how demo tools work is a process of evaluating the technology they use, the methodology they employ to share information with a prospect, and the outcomes they produce.
How most demo tools work
A lot of tools on the market today combine some version of the following technology stack. Using a Chrome browser plugin, they capture the screen as you execute a demonstration workflow, and create a duplicate of that structure that you can traverse and annotate.
By structure, I mean the screens you navigate to, the items you click to reach a new screen, and any labels and inputs for form elements you see as you go through this process. They also let you create virtual signposts or “guides” that use visual interactions to hint where you should click in the prototype, or otherwise let you click “next” to take the default path.
The generic process to build a software demo
?file=Candy_Land_2004_Board.jpg){kind=link}
There are three basic chunks to building a software demonstration in a demonstration tool.
First, define the “happy path” you will be guiding users through in the application.
What are you trying to accomplish? What are the steps to complete this path if you were doing it yourself in the application? Write these out in an outline format, indicating which element to click or form to fill to reach the next page, and identifying when you transition to a new page.
As part of this happy path, you’ll need to know if you made a mistake or have completed the step successfully. What concept are you trying to reinforce at each step? If you were giving an in-person demonstration rather than creating a demo experience, what would you say to the prospect at this point?
Decide if you want to stop the demo until the user completes the step correctly or give them an “easy button” to move through things and get to the next step.
Hint: it’s usually a good idea to give them an easy button.
Don’t forget, you are building an app
When you build an interactive demo experience, you are building a very simple application. You start with a landing page and a path to the next screen. You decide whether the experience has open choice or if you will tell the user where to navigate.
In building your demo, consider the atomic structure of the information.
Are you thinking about:
Concepts - broad inferences that you need the user to make after understanding what’s going on?
Page actions - plays that the user can execute by following steps exactly?
A sequence of events - a story that plays out over multiple interactions
How did the demo products we evaluated meet our needs?
Typically when you search for demo software, they are arranged by the output they produce. Is it an interactive, standalone experience? Does it embed in a website? Does it feel like a video?
This wasn’t a helpful frame for us as the use cases that we wanted to explore were based on the outcome we wanted to achieve for the demo user, not the output of the demo itself.
Going back to the “tell me”, “show me”, “let me try” use case, we wanted to ground our results in the kind of measurement you would see in a learning context.
Did they recall what happened after watching a demo?
After using the demo, would users know how to proceed?
Could they copy what they had learned and repeat it?
Could they apply these concepts in their own work?
This is roughly the evaluation you would make in designing a remote learning instruction course. A common way to measure this success is to use Kirkpatrick’s levels of learning.
What’s the right kind of platform for you?
If you’re starting the journey to pick a Saas platform for demo management software, I’d recommend thinking about it in this way:
If you’re building for PLG, having a constrained path might be ideal
An open path (within reason) works well if you understand your buyer well and want to give them freedom and a sense that this “feels like my data”
A complex, enterprise sale requires nuance in the way that you demo. You are likely dealing with multiple buyers simultaneously, and it’s important to be able to remix your content to meet the needs of your buying team.
Next time, we’re going to take this rubric and apply it to several tools in the market so that you can not only decide how you’re going to build a demo, but also make an informed decision about how different tools approach this challenge.
What’s the takeaway? The best demo for your product gives the prospect enough information to engage in a buying decision. If you’re trying to build for PLG, that means the prospect needs to be able to buy without much help. If your motion requires hand-holding, why not build that into the process?
Links for Reading and Sharing
These are links that caught my 👀
1/ Simple ways to visualize - The next time you have some data and need to turn it into a relatively simple and clean graphic, try Datawrapper. Here’s an example of summer cookout costs year over year.
2/ “Invisible” tenets of design - This is a fantastic discussion of small details and how they make interaction design effective. I’m not going to do justice to this by writing about it, so go read it.
3/ The new retargeting - In a store or a bar, you hear an unusual song that sounds familiar. Is it because you heard it first on Spotify, or because music programmers are pitching the songs that you will hear on your Discover playlist as a form of retargeting?
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon