Presenting your work
Last modified on Tue 19 Mar 2024

Presentations

You’ve been working hard, building nice-looking things. Now it’s time to present them to the world.

May that be at the end of the sprint, PI, or a special meeting with the client, the line of any feature’s development ends with its presentation. Things we are refining, developing and testing are part of our daily life. They are concrete issues and challenges that we are constantly trying to overcome. They are on our screens, on our tasks and on our minds. But for our clients, they are often just short descriptions, a mention in an email, or a talking point in a meeting. For them, they are very abstract. And the best way to breach the gap is to present our work to them.

Who presents the work will depend on the project and on the team. If there are more developers on a platform team working on the project, it’s always better for the team to choose one presenter and rotate them from sprint to sprint. This means that you will sometimes present work that somebody else was implementing. On these occasions, it’s especially important to prepare well and to go through features with your colleagues who worked on it.

Often, the first obstacle we meet is what to present. The work on the project varies from resolving bugs, technical maintenance, refinements and feature implementations. But we should present features that bring the most value to the user or the client. Was there a highly requested feature tackled in the sprint? Did you refactor the flow of working on some parts of the application? Will the users or clients have to be aware of some big changes? Features that cover one or more of these questions are good candidates for the demo. Of course, it's fine to mention everything you worked on in the sprint. But in order to keep the presentation manageable and not too long, prepare only the most important features for your demo.

You should only present finished features, that passed QA and are deployed to a stable environment. If at all possible, you should avoid presenting from your local environment. If the feature you are presenting is part of some MVP feature set, that is fine, and it's a good idea to even mention that during the presentation. If there are already some plans about future post-MVP development, you can mention that, but don't go into too much detail and focus on the feature at hand.

Preparing yourself

Everyone prepares in their own way. Some need more time, some less. It’s important to take enough of it to cover the things you’ll be presenting and be confident in your knowledge of the feature. When we are prepared, we are less nervous and we sound more confident. We can also react better to any questions or unexpected turns during the presentation.

It’s important to find your preferred way how to prepare. It might help you to write down the whole demo or at least some bullet points, important sentences or phrases that you expect to have the most impact. A good idea is to also craft a script for your demo, with scenarios, main points and the most important things you want to convey. It will help you to construct a more cohesive and understandable presentation.

It’s always best to prepare the data you’ll be using. Some nice titles, descriptions or images on the content are always much better than ‘adgfhioadhgfpia’ and ‘testestest’. Presentations are all about, … the presentation. Small effort when preparing the data goes a long way to look professional. Think of your presentation as a story-telling. Well-presented data creates a nice visual experience, whereas test data could ruin the experience and distract the client from the story.

When preparing your presentation, keep in mind the end user and how they use the application or features you are creating. This is one of the reasons that it’s important to know your client base and the challenges they face, and in what way your work will ease theirs. During the presentation, keep the experience of the end user in mind, as this is the best example of the value of things we develop.

It’s also important to tailor the presentation to the audience. Most often you will have diverse audiences of different backgrounds and technical knowledge and you have to be able to reach all of them. Try to present the feature in common terms, and you can omit any technical details and cover them if anyone asks about them.

In the beginning, introduce the topics (features) you’ll cover and explain why. This way you will put the presentation in a concrete context that will help people who listen to you to connect the presentation to real-life problems they are trying to solve. To help this further, try providing some concrete use cases. It’s a good idea to start with some background information about the feature and why it is important. Mention any benefits that the new feature introduces. This can be either an improved UX, easier workflow or some metrics on saved time or effort in the future. Optimisation of resources is an important metric for clients. If some feature will save some development time in the future, this is an important thing to mention.

After your presentation, offer the clients an opportunity for questions. If you are presenting several larger topics it could be a good idea to ask for questions when moving between them, while the context is fresh. Q&A is an important part, as this is another way of connecting value to the product, and it provides an opportunity for clients to get to know the product better. When preparing for your presentation, try to imagine what these questions might be. With practice, experience and more domain knowledge, you’ll also get better at knowing your client’s needs and interests.

Don't be surprised if someone interrupts you and asks something that is tied to what you are currently covering. These can sometimes break your flow, but the techniques we covered will help you to regain your place. This way you can continue with the presentation after the question is answered.

And what if you can't answer it? It's always completely fine to say that you are not sure. Maybe the question is tied to some technical details or business logic that you are not familiar with. Usually, you are not alone on the call and you can ask your colleagues to chip in (someone you know is more familiar with the topic, or perhaps your PM). It's also a good idea to say that you'll investigate the topic and get back to that person with the answer later.

There are also times when the discussion goes its own way and people start discussing a topic in detail. This is still a presentation and is most likely only one part of the meeting you are on. If you feel that the discussion is taking too long or is going too deep, it's a good idea to propose arranging a separate call to tackle the topic.

Sometimes pre-recording a presentation is a good idea. If the project you are working on is in its early stages or the dev environment is not fully stable, it's better to make a recording of the feature. You can use this recording during the presentation as an aid, pausing it if needed, to explain a certain part in more detail. But you can even record the whole presentation itself. This approach doesn't have to be used only when technical limitations make a live presentation hard. You can also use it if you are more comfortable making a pre-recorded presentation than talking live. If you decide to do that, still keep in mind pointers from this chapter and expect questions from the client at the end. Some clients like this approach, as it allows them to re-watch the recording or share it with a wider circle within their company. But this approach also has its limitations. For instance, it makes asking questions during the flow much harder and more disruptive (if the video needs to be paused or retraced).

Pre-demo meetings (an example of good practice)

We'll do it live

This approach rarely goes well. We should all treat demos just as seriously as we do coding, refining, and testing. Enough time should be allocated to the presenter to prepare a good-quality presentation. This could also mean a dry run before the actual presentation.

On some projects, there is a pre-demo meeting before every sprint closing, where the presentation is rehearsed. The point of this meeting is to have an internal demo before the real demo. An hour before the meeting with clients, the presenters meet. People from the team who worked on the features sometimes come to listen and give feedback. The presenters have an opportunity to simulate the real thing that will come soon. This way, we can make sure that things are ready. Are audio and your connection ok? Is the presentation visible? Do you have all the permissions to share your screen? Is the data that you’ll be using still valid and prepared as it should be?

Some projects demand an even more technically demanding presentation. You might need some external devices, other than your laptop, to showcase the features to their full extent. Make sure, that all your external devices are ready and that you are able to present any external video or audio sources during your presentation (this might vary from showing some flows on mobile devices, tablets, playing audio from external sources, etc.). Make sure that the communication service you'll use (Zoom, Meets, Slack, etc.) allows you to share the full range of inputs you require. Perhaps your internal video camera on your laptop is not enough to capture everything and you need to set up an external camera (if you are, for example, working with some prototypes). Make sure that all this is set up and tested before the presentation begins, and if your projects require this more elaborate setup, take enough time to prepare everything.

This setting serves as the final check and also allows your colleagues to suggest improvements and additions to the presentation. Maybe something was overlooked, maybe some part of the flow should be emphasised more, or maybe someone remembered another thing to add on the spot.

We caught a lot of important things through these pre-demos and we usually iron out all the kinks. This results in higher quality presentations but also helps the presenter to find the right words and ease their nerves. Questions from your colleagues can prepare you for any questions from the client and often you have a good answer ready to go.

We make sure that after this call, we have enough time to finalise everything, prepare the environment, reset the data we’ll be using and get ready for the real deal.

Talk with your project team if this could be implemented in a similar manner. Perhaps it doesn’t have to be so structured, but you could try out presenting to a smaller number of your closest colleagues that are familiar with the features included in the presentation.

Tips, tricks and last checks before the demo

When should you use Pitch, Google Slides, or Keynote?