Why demos are like demons for developers?

[5 minutes reading]

If your team of developers consider demos are a stressfull waste of time that delays development, then you may have an issue that this post could help to solve.

Some weeks ago, a robotics engineer working for a company in Singapore shared to me his concern with his boss, who was asking for a weekly demo to potential customers of an uncomplete prototype. This is quite a common situation and the reason why I decided to write this post.

It is clear that demos are key for a business success. Having customers and stakeholders involved in demos gives them not just a way to evaluate a product, but also a living experience. We are rational, but also emotional. Demos should also touch the rational and emotional inside of the audience. But why developers think demos are demons conspiring against development?

• Sometimes because demo preparation takes long, as reinventing the wheel every time.

• other times because it involve the same developers and the team do not see them as an opportunity to get good feedback for development and business.


• and many other, the product or prototype is not properly tested and mature for a demo, so the stress of developers for a highly probable demo failure is too high

But really there are really good things we could do about demos. Let me tell you some key actions I recommend to follow:

• Have clear requirements of what the demo should do. These requirements usually are a subset of the product requirements and will give clarity on what features will be part of the demo.

• Prepare a demo as much standard and automated as possible, so it could be executed with minimum amount of supporting people. This reduces cost of demo and transmit simplicity to the audience.

• Prepare a written Demo Plan, describing roles of people involved in the demo, what should they do, in what sequence, describing the preparation of the demo, the execution and the post-demo actions. 

• Keep always one unique interlocutor for each demo, who would give turns to others to clarify specific points of the demo if needed.

• Before doing a demo, ensure the features have been tested properly and a rehearsal of demo is done.

• Share with the development team clear reasons why demos are important and a good way to test, learn and correct features, as well as for the business.

• Rotate the responsibility of doing a demo between different people, so they could learn and dilute stress between each other. Consider also doing demos with sales or product management team instead of developers as main executors of the demo, may be with a developer as support in case of doubts. This shows simplicity to audience and usually sales and product management  people are more adequate for communication with customer than developers.
  If your company requires doing demos with developers, take care of the amount of demos a developer does. Usually, developers need to develop and could understand dedicating part of their time for demos, but too much time doing demos and low time developing may demotivate them.

• Give clear expectations to the audience. I saw many times failing demos of products, with the promise to be mature products when they were really prototypes in alfa version. Being sincere to the audience on what you are showing will ensure adequate expectations and prevent deception and stress if something wrong may happen. Anyone could understand a failure if they know is an alfa/beta version but not if they believe it is a finished product.

At the end demos are important and necessary for a company success. The way we prepare and do demos will directly influence the mood of the people involved in the demo and the experience of the potential customers.