How to prepare and give a good demo of your product: my 5-point cheat sheet

You will find hundreds (if not thousands) of articles on "How to prepare and give a good demo." Being Product Owner myself, I’ve read quite a few in order to develop my own style. I feel it works well for me, the development team working on the product, and the engaged (business) stakeholders who participate, so I'll share my approach with you.

1. Define the type of demo and create a story around it.

The title sounds a bit like a marketing prompt, but let’s be honest, a demo is the product team's marketing tool. It means that you want to showcase (sell) the accomplished work to the stakeholders, so you need a story.

The story definition differs, if it is a demo of the whole product (sometimes quite extensive) or just a specific feature. As soon as you know about the scope of the demo, you can move forward with what you want to show:

1/ Demo of the whole product should be based on a happy flow of the solution for the main user. You want to tell the story from the point of view of the user, trying to capture their goals, aspirations, pain points, and highlight how the product answers them. Be sure all the key features work perfectly for a happy flow and have been tested several times in advance of the demo. I strongly advise not showing the product “feature by feature,” but rather explain how main users will accomplish their goal based on their needs.

Tip: Do not even show some additional, “nice to have” features destined to a secondary target group. It will make it less clear to the stakeholders who do not know it by heart, as you do.

2/ If you demo just one specific feature, which is always the case at the end of the sprint, you can still tell a story. Start from the broader context of where the user will start using it, in which part of the solution and then go into details about the future itself and what will be the next action the user might/will take after.

2. Offer the chance to test the presented solution and share feedback.

From my experience, the stakeholders are usually interested after the demo in testing the solution themselves. Great news, as you can recruit free and motivated testers! You can incorporate a QR code in your slides or share it during the demo, where they can access a solution in testing/preview environment and test it themselves.

Tip: Explain to whom/where they can share their feedback, so that there is a clear communication channel. Otherwise, it will be a mess!

You will benefit from their feedback in identifying existing bugs or future improvements of the feature, but also increasing their level of engagement and knowledge around the product.

3. Demo presentation by all team members (developer, product owner, UX/UI designer)

The goal is to give a different rhythm and a variety of styles to the demo. Every expert will present exactly the same feature with a different perspective, and it can be a great way of showcasing how the team is complementary and share in the delivery's success.

Write a small script with who will present what and when. You will also want to practice it a couple of times to be sure that it goes smooth for everyone.

You can be sure to  learn some new memes from your teammates that you’ve never heard about 😉

4. Show product/development data

Business stakeholders always want to know how long it takes to build the feature and it is a fair question (time = money, we all know that).

Demo activity might be a great opportunity to lift the curtain on this very debatable topic. One potential way to calculate can be very simple: how many days, story points, any other metric you use to budget the development of the feature/solution vs. how many were actually spent? It will be a very easy and explicit chart with 2 columns, however what is more important is to include the explanation of why the columns are not the same (if they are not, of course?!).

The explanation also opens an opportunity for a pedagogical discussion and exchange about impossibility and take into consideration everything before you work on it. It's challenging to anticipate the additional information that will come through or will be gathered during the development cycle.

What you want to achieve here is to be transparent with your stakeholders about the process of estimation, its challenges and also build up on their competences for a better understanding of the development process.

Tip: It might be also interesting to show the usage data of the feature which was showed in the previous session and how it works once put into production (kind of a flash back to the previous demo).

5. Share the next steps and ask questions.

All demo participants want to know when the feature/solution will be in production. If you have this information, go ahead and share it openly. In case something goes wrong, you might be alerted by someone you did not have in mind.

Asking questions after the demo is key for both sides—demo team and business stakeholders. Each side should prepare their own list of questions and throw them out for an open discussion.

Tip: Some of questions you can expect me to ask:
1. When I am on a demo team as a product owner towards business stakeholders:
> Does the feature correspond to your expectations? Do you have some ideas for V2 at this stage?
> Do you understand all the business logic/calculation method/flow behind the feature?
> Do you want us (demo team) to come and demo it to your respective teams?

2. When I am on a business team towards a demo team:
> What unexpected challenges did you encounter while working on the feature? How we could have avoided them for the next time?
> Do you have already an idea on how it can be improved?

To recap here are my 5 tips:
1/ Tell a story during a demo.
2/ Open the possibility for testing.
3/ Let every team member speak.
4/ Show data.
5/ Share next steps and ask questions.