What I learned by miserably failing a demo at the Smart Port Hackathon

One of the most effective mindset I have learned to use to succeed in life is not to blame others for my own failures. Blaming others only shifts the responsibility of future successes on them, and this approach can only bring more failures on my way. The only way to succeed is to learn from my failures and take direct responsibility for things that went wrong. Doing this I can have an active role to avoid similar occurrences in the future rather than be the "victim" of other people mistakes or wrongdoing.

This weekend I participated at the “Smart Port Hackathon” in Singapore, and I had to pitch a project idea and demo it to a quite large public. My pitch and presentation have gone so bad that not even trying to make things go bad in purpose would have work out so well! In the misery of my failure I learned a few new lessons, and I share them here with you.

Here are my main 7 mistakes:

1) Accepting to do a pitch and a product demo in just 3 minutes
While I been talking at conferences for more than 20 years, I am new to the startup scene where an idea must be pitched in a very short amount of time. I learned in the past 6 months to squeeze presentations in less than 5 minutes (something I purposely am NOT doing with this post), yet I have never done both a pitch and a product demo in just 3 minutes. If the hot aspect of the project was visual, focusing mainly on the product demo would have been ok, but the hot part of the project I had to pitch is the technology and the legal aspects of it, and that requires explanations.
Lesson learned: as I didn’t feel confident of squeezing pitch and demo in just 3 minutes I should have refused to present it.

2) Using most of the time for the demo rather than for the pitch
I did prepare a nice pitch deck that would have made my 3 minutes mostly focused on the explanation of the technology rather than the demo. At pitch rehearsal (3 hours before the presentation) I been asked to cut the pitch to less than 1 minute and give most of the space to the demo. Bad choice. I should have refused to do it, but I end up making a shorter version of the deck, and squeezed the pitch in 30 seconds leaving 2 minutes for the demo of the technology.
Lesson learned: I should always be sure the audience knows about what I am showing. What makes sense to me may not make sense to them.

3) Try to demo a technological innovation without explaining it
Presenting an electric car simply driving it around, without saying that it has an electric engine, may leave people thinking it is just another car. A blockchain powered solution - the project I presented - demoed without explaining the business and logistic advantages of using the blockchain technology, at the eyes of the public will look exactly like any other existing IT solution.
Lesson learned: without context each person gives their own interpretation to what they see based only on their experiences and knowledge.

4) Be one between so many teams
I had no idea that every single project presented the previous day would have been pitched and demoed. 21 teams did pitch and demo their products one after the other, 3+1 minutes each. No pause. I was team #20 in the queue (out of 21). By then the public is either catatonic or in a big hurry to leave. Is it true that the best wine gets served last, and I really think that the organisers have left me at the end to give me a chance to leave a good impression, but nope, it didn’t work out. I did expect a selection, and a better chance to present for those that did deserve it. Rather than 21 times 3+1 minutes pitches and demos, I expected 10 times 5+1 minutes presentations.
Lesson learned: next time I should enquiry first if there is a selection

5) Not rehearsing with the technology 01: video projector
This has been the biggest mistake and problem (not only for me). While a lot of attention of the organisers has been given to make sure people would pitch as little as possible to give space to the demo, not a single test has been done to make sure the available technology would have fit the needs of the teams. The projector had a top resolution of 640 pixels by 480 pixels. As comparison my 3 years old MacBook has a resolution of 1440 by 900 and my iPhone has a resolution of 1920 by 1080. What is expected, since 10 years ago, is at least a resolution of 1024 by 768. I (and others) made the mistake to assume this was the case also for the projector to demo the softwares. The web app I had to show, below a certain resolution simply did not work. As it is a work in progress (prepared during and for the hackathon), the design of the pages had been set to work on the minimal common resolution of 1024 by 768. Once below that resolution the page became unresponsive.
Lesson learned: never give for granted the infrastructure to demo is what I need. Always test it before the presentation. If an organiser does not think of it, suggest a test. If refused, don't demo.

6) Not rehearsing with the technology 02: Internet connection
Second mistake, all mine, has been to rely on an internet connection for the demo. The wifi offered at the hackathon did not work with my computer, so I relied on my phone 3G connection. I should have had a local deployment of the application, rather than using one online, and connect the mobile phone app to my computer via direct wifi connection. As Murphy's Law says: "if anything can go wrong, it will", and so it did! 1 minute into the demo no more internet connection. Suddenly no mobile coverage and my 3G connection went down.
Lesson learned: if possible avoid using internet connections during a demo. Deploy everything locally, and run all from there.

7) Last minutes changes
I was ready to present with my initial pitch as I rehearsed it several times, check the duration, and had good matching slides. Just 3 hours before pitch time I been asked to pitch in less than a minute, and focus on the demo. I made changes to my slides, and it has been a disaster. I had no time to rethink what I had to say, I had no time to reorganise the demo now that I had much more time for it, and I was not ready to manage issues as they came along. At presentation time I went through the slides in 30 seconds with no breath (I may have sound as if I was drowning and asking for help, I literally couldn't breath), I started the demo and it didn’t work because of the screen resolution and internet connection issues, and while I was trying to make sense of what was going on, the 3 minutes bell rang, and I was out. I apologised with the public and left the venue. I had to make sense of the disaster that unfolded upon me.

Who's fault was it? Blaming the organisers for not alerting me about the projector resolution or 3G coverage means that at the next event I may find myself in the same situation. Lesson learned, I will from now on remember to ask (or go check for myself) if the projector supports the resolution I need and if the 3G signal is strong enough. To summarise:

1. DO NOT accept to do a pitch and a product demo in just 3 minutes: good things must be savoured.
2. DO NOT give more time to the demo than to the explanation (if the selling point of the product is not visual.)
3. DO NOT demo a technological innovation without first explaining it, unless you are in front of a public that knows the technology.
   
4. DO NOT be just one between many others: be a chosen one or be not.
5. DO NOT pitch and demo without being sure all works ok: it is a pity to kill a good project because of poor technology to present it.
6. DO NOT make last minutes changes, unless there is enough time to rehearse.

 What have been your fails at demos and pitches and what lessons did you learn?