How to Create a Killer Demo for your Deep Tech Startup

You are a deep tech startup. You are bringing some new capability to market, i.e., at least some of the outputs that your API provides are new to people, or significantly improving the performance/scale/scope of an existing capability. Basically you have some jaw dropping tech. But it is not quite there yet. You are missing the tons of (annotated) data needed to train your machine learning models, the 80% of the effort that is required to make your tech really work (not just in the lab but also in the wild) and the customer traction that will validate the relevance of your tech and lead you towards a product-market fit. And you don’t yet have tons of credibility either. You are fresh out of a research or academic lab with some limited startup experience. You are going up against investors, customers, and the public. And you are asked time and time again to demonstrate 0) what you are building and that your technology 1) works, 2) is cool, i.e., can be used to build news-worthy or viral applications, and 3) is relevant, i.e., it solves (at least) a crucial problem for the market/vertical you are targeting. How best to create enough credibility for this in the absence or with limited business traction?

Enter the dance of the demo, prototype, MVP, alpha, beta, product. But first the demos. The duct-taped almost-working pieces of tech that will get your foot in the door. Live or canned, but always, a thin slice of reality — tech that works conditionally, almost. But works well enough to sway the non-believers over to your side. There are at least three flavors of demos for a deep tech startup associated with the three basic goals mentioned above.

Namely the:

1. Holy Grail Demo: This is an early stage deep tech company demo. Your CEO/BD/sales lead needs to persuade the infidels that your technology works. There is no adequate market validation yet and (typically a live) demo of your deep tech is needed to add credibility to your amazing (sales) pitch deck. This demo is also needed for your angel/VC investors to secure a pre-seed round towards building an MVP. You are fresh out of a research lab and you have a working prototype of your core tech. But not enough data to train your ML models — surely you have not solved the general problem yet. What to do?
2. Wow Effect Demo: Your marketing department with the full backing of your CEO is pushing you hard to create that jaw dropping demo that can be demonstrated at trade-shows to a mixed audience of technologists, entrepreneurs, investors, or the general public. It is all about publicity after all. This could just be the natural evolution of your Holy Grail Demo. Or should you start from scratch?
3. ABC Demo: Your “always be closing” demo, what your BD/sales lead has been harping about all along. A demo of your MVP — which you are still building by the way. Showcasing your use-cases, the data-flow and the ROI. Simple, yes? Or maybe not. Your MVP is still a deep tech SaaS platform with an API open (?) to the world. Your use-cases are your customer use-cases. You don’t have a product, your customers do (maybe). What to do, what to show?

What to Build: bringing balance to the force

Here, instead of listing a bunch of principles for software design, project management and UI design, I tackle some of the main design decisions that you will be faced with when building your demo.

Here we go:

1. Live or canned: In case you have the option to do a live demo with data streaming in from sensors, e.g., video from your iPad's camera, this is the decision that will probably most affect the scale and scope of your project. Building a live demo can be significantly more complex but also very rewarding in terms of the effect and credibility you will get — if it works. At the end of the day this is all that matters. Will it work? If you believe that at least for parts of your demo your tech is mature enough to conditionally work (see bullet 6 on the definition of adequate performance) then go for it. It is worth the extra effort and resources. Also canned demos rarely have a wow effect — so if you wanna be cool go live. A note of caution: don’t do a live demo just for the sake of a live demo. If the demo does not fit your purpose, e.g., you work in analytics and your MVP aggregates information over hundreds of data points, go for a simpler canned demo.
2. Real-data or synthetic-data: OK so now you decided to go with a canned demo. The next decision you have to make if you are gonna do this demo on real-data or on doctored (synthetic) data. In general, real-data, close to your core use-case is best. However, if your deep tech fails to produce “good” results on real-data (both in terms of performance and in terms of providing interesting data points that showcase your tech) you might be better off producing data using a scripted scenario. For example, instead of analyzing a news video you might instead use the video of a talk show.
3. Scale and scope: Being a brainiac you might have the tendency to over-engineer your demo or make a push to get your deep tech working in very challenging conditions (in the wild). See the “Common Pitfalls” section for more details on this. Remember that your demo is a toy that you (or someone else) will play with for a few minutes. It should have the right level of complexity and the right level of novelty/challenge to put your audience in a state of flow. Not you, your audience. For you it should look straightforward, even boring. Now per the scope of your deep tech: if you cannot get it to work (see bullet 6) even under very specific conditions you have designed the wrong demo. Go back to brainstorming. If, however, your demo is working well under specific conditions and you keep trying to improve the deep tech to make it work in general, you are over-engineering. Take a step back and stop wasting precious resources.
4. Polished or raw: Polished. Your demo is a sleight of hand. As a master illusionist you will show what works and hide what doesn’t. So you should make every effort to keep your audience in system 1, and polished graphics can help you do that. However, as you lead your audience down the garden path remember that people are not infinitely gullible. If the semantics of your demo fail, look and feel will not help you any. So get the content and UI design right, before you turn your attention to the UX.
5. Putting the demo in the hands of your audience/customer: So you decided to do a demo live with real-data after all. Should you put it in the hands of your audience/customer? There is no greater credibility than the one given by an audience member trying out your demo live. If it works. If it doesn’t or it misses a wow effect it can lead to a pretty brutal lashback. Note that unless people get enamoured with your demo they will try it 2-3 times max. So make sure performance is up there — see next bullet. And of course your demo should be super robust. Debug diligently. Reduce or eliminate all dependencies if possible, e.g., internet connection.
6. Performance: The psychological limit of something that works is getting it right about 9 times out of 10. This does not include maybes, just examples where your technology clearly works/breaks. So if your demo produces 9 corrects, 5 maybes and 1 obvious error out of 15 tries you typically are good to go. If you do decide to do a live demo on real data or even worse put the demo in the hands of your customer you better be up there in terms of performance. If you are not in the 90% accuracy range go for a canned or doctored real-data demo. If you are over 90% for some of your results (but below for some others), do a live demo only for the part of your results where you pass the 90% threshold (and for the rest do it canned/doctored). OK you can also live in the 80–90% range if you are bold. But don’t go below that.
7. Core tech vs use-cases: This is the hardest question of them all. You have this amazing tech that can be applied to so many different problems in different verticals. You don’t know which one of them to select. Should you focus on a very narrow use-case in a specific vertical that you have achieved some amazing results from a recent pilot? Or just demo the generic core tech? Or a little bit of both? In most cases, you should go for a specific use-case/vertical if you have it. Generic tech is rather unattractive to investors and customers alike (even for OEM customers where you are selling an API it is better to showcase a use-case). For the general public however a core tech demonstration can be pretty powerful, e.g., Affectiva has gotten tons of mileage out of their frown/smile face detection demo.

How to Build: 7 stages in the development of a deep tech demo

Next I suggest seven (possible iterative) steps to build the right demo w/o wasting too much time or money on expensive UI/ programming resources. On average you should plan for the whole process to take in 1–2 person-months. If you are planning more effort than this you are building a prototype not a demo — too much complexity. If you are planning for less effort you are probably building a canned-demo, something more like a concept video explaining your tech (which is also fine by the way).

So here it is:

1. Concept: You draw up a sequence of screens. This is basically a glorified power point presentation. This is the most creative part of the process, so make sure you include all important actors in your company and spend at least 50% of your time brainstorming before starting to limit your choices. Rank-order the ideas and work on the most promising one. Keep the rest for future sessions if you need to revisit step 1. Note: feel free to mockup in pen & paper, take snapshots and add in a presentation. Duration: 3–5 h x 4 iterations = 2 days.
2. Test the user experience: It is time to turn your sequence of slides into a storyboard. This is an early video of your “slides”. Record yourself as if you were giving the demo using the slides as mockups of your demo screens. Review your recording. Seek at least three independent opinions, preferably, your BD/sales lead, your marketing lead and a “customer”. Is the information flow, detail and density good for the non-expert? Is the presentation of your technology/ use-cases clear and effective? Are you achieving your goals (credibility, cool factor, business relevance). If yes, continue. Else go back to step 1. Duration: 4h x 2 iterations = 1 day.
3. Data Validation: Add some real data behind your demo, i.e., do steps 1 and 2 with real data. Use 2 or 3 data samples that you have collected from customers during early pilots. During the first iteration, annotate the data manually. At the second iteration run it through your platform and review the results. Do the selected visualizations continue to provide the appropriate information flow and density? Does adding real-data support your messaging and claims? If not, go to your engineering department and ask them to tweak your ML algorithm (Note: give them up to three days — no more). Then repeat this step. If tweaking does not work go back to step 1. Duration: 1–2 days … plus the time needed to tweak the tech to make it work in the context of your demo as necessary.
4. Build it — Part 1: Create high quality mocks of your screens using a UI/UX expert. Review with your tech team and your BD/marketing expert. Make sure that they are happy with what they see visually and there are no blunders on how the information/data is presented spatially and spatio-temporally. Note: do the trick in step 2 to understand the timing aspects of how the information associated with data is presented in real-time, e.g., annotation associated with audio or video streams. Duration: 2–4 days.
5. Build it — Part 2: Write the code to build and connect your mocks into a webapp. This is the most time-consuming part of the process, typically. However, with the well-defined specifications in step 4 and a good understanding of the information flow there should be no surprises here. Important to review step 4 with your tech team so that there are indeed no surprises. Duration: 1–2 weeks.
6. Build it — Part 3: Connect to your data store. Again it depends how “real” you want to make your demo. Typically your data store will not be very different than the examples you worked with in step 3. However, you might have to hunt for better examples in your data or even create “synthetic” examples. If this is a live demo this step might be significantly more time-consuming. You might have to go back to step 3 or even all the way back to step 1 if the live demo does not work as well as expected, especially if you are inclined to put the demo in the hands of your customer. Note: again consider the scope here, if you put this in the hands of your client you might want to limit it to a subset of demo outputs/functionality. Duration: 2–3 days.
7. Test it out: Debug, debug, debug. Get feedback from your presenters and customers. Tweak by going to step 5 as needed. Make sure that the demo is unbreakable. It only takes one failure to lose that crucial first deal or investor opportunity. Duration: 1–2 weeks.

Common Pitfalls: the power of the dark side

Sometimes things go awry. The best way to learn is from our mistakes. A less painful way to learn is from other people’s mistakes. My favorite UI book is GUI Bloopers, a terrific collection of stupid mistakes that smart people make when they design UIs. Lots of fun up to the point that you realize that the book is talking about you — also 😉. So here are some common mistakes that you may commit when designing and building your demo. I have, at one time or another, indulged in every one of them.

1. Lack of (or wrong) resources and expertise: It is not uncommon for an early stage startup to be cash strapped or work with a nominal full-time tech employee headcount of one — you. Don’t be afraid to hire short-term help for creating demos; there might be technical aspects that (at least at this point in your deep tech startup lifecycle) should not be part of your core tech team competencies, e.g., integration with external data sources, real-time signal acquisition, UI/UX expertise. If you have it great. If not, hire freelancers that you know personally or are suggested by your advisors. If you have no leads you can also find this expertise online, e.g., at upwork. If you know what you are doing you can get this project done cheaply and efficiently. If you feel, however, that your project management expertise is limited or you feel lost/clueless, go to a company that serves as an one-stop-shop for startups or use the resources of an incubator.
2. Lack of focus: You are working long hours, have tons of technical tasks to conclude and many tech fixes (aka your deep tech that always seems one elusive step away from finally working). Naturally you view demos as a distraction. Something that the CEO/business/marketing keeps pestering you about. You start, hit a wall, get some diverging feedback from business on the quality of your mockups and you stop. Then you start again. You do one more iteration but it feels like emptying the ocean one bucket at a time. You stop. Business complains. You start again. The demo seems to drag on forever. Most probably you don’t have the right scope, scale or resources either.
3. Lack of a product owner: Remember who you are building your demo for. Your goal (credibility, coolness or relevance) and your end-customer (investors, customers or general public). For each of the three types of demos there is the perfect product owner, namely your CEO for the “holy grail demo”, your marketing lead for your “wow-effect demo” and your BD/sales lead for your “ABC demo”. Make sure that they agree to that role, while you take the technical lead/scrum-master role. Respect these roles and don’t allow, e.g., the CEO to rain on the “ABC demo” parade. Note: having an actual customer/user of your technology platform is a big plus if you can find one committed enough to work with you on a demo.
4. Lack of a clear goal for your demo: One demo to rule them all. A valiant goal. But not always a realistic one. By trying to make everybody happy (CEO, business, marketing) you make no one happy. You demo is bloated and lackluster. It misses a punch. In general, when given a 2–5 minute window to present or validate an idea always make sure that you present one clear idea (maybe one and a half). No more no less. Building three demos in one does not work. But tweaking a “holy grail” demo to become a “wow demo” might work. And of course all your demos should share significant components (especially the back end). However, what you show and how you show it for each type of demo should be different.
5. Wrong scale: Instead of building a demo of your MVP, you are building the actual MVP or even worse writing specs for your product. Deep tech should be as easy to demonstrate as any other technology, with the added complexity of priming your audience for a new result or use-case. Think simple, simple, simple. Best case scenario you have 10m to showcase this, worst case scenario you only have 2–3m. Choreograph your demo carefully and avoid all clutter. Don’t waste time and resources on a bottomless pit of a project. If it becomes too complex and falls way outside of your scrum planning specifications don’t hesitate to go back to the drawing board.
6. Wrong scope: A demo is supposed to work only under specific circumstances, it is a small-scale, conditional MVP. If you have required your demo to work in a real world situation you have erred on the scope of your demo. You are again (in terms of core tech performance) building the MVP proper or the product. Note: the only exception here is if indeed your core tech has matured to a point where it works in many different settings. In this case, do increase the scope and even put the demo in the hands of your audience or customer.
7. Wrong audience: Make sure that you tailor your demo to the right audience. Investors, customers and the general public are very different on the amount of due diligence they will perform on your demo, questions they are gonna ask, their technical knowledge and attention span. A common mistake is to make your demo too technical or too ambiguous (see here it works and here it does not work for reason x, y, z …). Business people need simple, clear, short answers to the problems. They want determinism. Investors will try to pry and break it to figure out the limitations of your technologies. And the general public is looking for something that can excite their imagination and offer a window into the future. Another common mistake in the design or presentation of your demo is lack of common grounding. By the time you are showing your results you have already lost your audience because they are lacking the context to understand it.

Roald Amundsen the explorer once famously said that “adventure is just bad planning”.

So plan accordingly.

A few years later, Amundsen disappeared in a rescue operation.

Shit happens.

Plan for that too.