Demos are expensive: they take a lot of time to build, and a lot of thought and effort. This scares a lot of teams…spending a month iterating on a single design idea, and perhaps it won’t ship? It’s risky. Still, demos are a required part of the journey of building a product. Whether you’re a product manager, designer or engineer, demos are the single most important tool to convince others of your idea early on.

What makes a good demo

As Ken Kocienda wrote in his book reflecting his time at Apple, Creative Selection, “…software demos need to be convincing enough to explore an idea, to communicate a step toward making a product, even though the demo is not the product itself. Like the movie, demos should be specifically choreographed, so it’s clear what must be included and what can be left out. Those things that aren’t the main focus of a demo, but are required to create the proper setting, must be realized at the correct level of detail so they contribute to the whole rather than detract from the vision.”

Demos need to be good enough to give the feel of the final idea. Demos aim to create the aha! moment real users would have with the product.

Demos convince others

Demos have allowed me to make important decisions easily, proved possibilities, and convinced leadership with data.

Make an important decision

When we were first developing the earliest iterations of Vsho, we came across quite a few difficult user interface problems which we deemed as (nearly) irreversible decisions. We had many feature sets on the table for our MVP, including messaging, saving, private profiles, etc. We had TOO many feature sets, and we wanted to constrain ourselves to a total of 5 main pages in our app for the next year, as we pushed out new features.

For our main pages, we were choosing between messaging, a person’s profile, a feed, a search and explore page, personal messages, and saved posts and lists. We ended up making the decision based off what was most important to our target users, and what “felt” good as being a main page. Some of our options, including messaging, “felt” good enough being a part of a separate page. It more literally “felt” good because we were able to bring three different versions of the app to our demo meeting. In a demo, what worked and what didn’t became very clear.

Prove something is possible

I started at Dropbox on a relatively new product and team. To choose large features to add to a younger product, we engaged in a lot of experimentation. The product was technically complex, and often the team was unable to estimate the number of hours a feature would take to build. We had so many exciting ideas, but it was difficult to prune what made it onto our product map for the sprint, quarter or even year.

For many of these ideas, a staff engineer or enthusiastic less-senior engineer would go and try to hack together a version of the idea, to prove that it was possible in a given amount of time. Embed things like Sketch files? Not super technically complex. Add giant tables? Very technically complex. Create a “public” version of a doc from a “private” version? EXTREMELY technically complex. As a smaller product team at Dropbox, our engineering team was scrapping and smart to reuse a lot of the code Dropbox already created to accomplish some parts of our vision.

Every time we wanted to embark on a project that included a lot of unknowns, a demo was required to prove the feature was feasible and to get leadership to commit more resources to the project.

Accumulate data

Demos can also help you accumulate data to convince your team that a feature or project is more important than they realize. Again, during my time at Dropbox, an engineer, a data scientist, and myself were trying to understand how we could increase the number of our signups that activated. Our jaws hit the floor when we realized a sizeable portion of our signups were not hitting our onboarding pages – because the sign in process was taking 7+ seconds for them.

We thought that fixing this might be a huge opportunity to engage more users in the product (and, it’s also a pretty poor user experience). However, we had two major reservations: first, we didn’t know if these users were high-intention users…perhaps they wouldn’t have activated anyway. Second, these users likely had slower internet speeds and were possibly used to slower loading times, implying that fixing this loading time wouldn’t make a sizeable difference in them activating.

The best way to accumulate this data, to see if these users were high-intent users and it was worth a very expensive trip into our authentication flow, we created a hacky demo: we helped set up our product’s account when that Dropbox user first established their intent to try our product. Technically, it was slightly complex and not very elegant, but the demo worked: it shaved off seconds on the sign up for those users, and increase our activation rate by over 25%.

Now we had a very specific goal and pay off, and we could bring our findings to the team and made the decision to invest our time in this part of the flow (spoiler: we did).

•

As Thomas Edison said, “Genius is one percent inspiration, ninety-nine percent perspiration.” A product that appears to be a stroke of genius is usually a product of many smart people collaborating and throwing themselves at a problem over and over, putting their ideas on display in many different iterations of demos. Demos, although expensive in terms of time, are required to continuously push out great products.