[MUSIC] Remember the best presentations you have seen and the worst. You noticed that the best presentations always share a characteristic. Good presentations are very often story driven. The presenter tells a story that you want to follow. In contrast, poor and boring presentations are nuts. For instance, particularly when dealing with technical topics if you are presented to a list of result, without any relationship whatsoever, or the presenter starts focusing on technical details that nobody cares about, we'll likely stop paying attention. Whether you will be presenting the result of your own analysis, it's tempting to forget that you're not talking for hearing your own voice, but to pass a message and accordingly. You shouldn't focus on what you want to say about your walk. For instance, how technically twice and how difficult some of the analysis were. But focus on the key messages you want to convey to your audience. And so, a good business analytics story has a good beginning, and I'm not talking about a opening joke, even though that could work. I'm talking about starting your presentation with a relevant to-the-point hookup. For instance, there is no need to start haranguing about the history of the company, or its sector in general. Imagine that you're talking to your clients as a consultant. He probably knows his own company better than you. Instead, you should directly identify the issue at hand in a quantities and visual way to convince your audience that what you will be presenting will be worth their time. For instance, what's the pain point you want to solve? Are you trying induce on presentation? Say it directly and give us a number indicating how serious the problem is. Even better, show us a graph about the number of people leaving each year. Are you trying to serve your customers better? Why is it important? Is it because a recent satisfaction survey was tabled? Are we losing market shares? Use quantitative information as soon as possible to demonstrate the relevance of what you will address later in the presentation. It may be a pin point. Something to solve, or it may be an opportunity to take. But it cannot look like you're playing with data for the fun of it. If there is a reason why we are listening to you, we should know it within the first 30 seconds. And by the way, don't forget to address it by the end of your presentation. I very often seen presentations that claim that they would address the first issue, and where actually addressing another one as the story progressed. A great storyteller always delivers what was promised or foreshadowed. Now as a matter of fact, in practice the key issue of the presentation is very often discovered the other way around. The paying part of opportunity that you will be presenting at the very beginning of your presentation, We usually only be identified in the course of your analysis after you've concluded your analysis. What happens is that while analyzing the data, you will discover opportunities to take or problems to solve, only after a while. But when you present your work, it shouldn't follow the order of the different actions you've taken in the course of your analysis. It should be restructured after you've come to your conclusions, to ensure that everything you do, from the beginning to the end, looks like it has been aimed at addressing the issue raised in the introduction. Even so, when you've done your analysis, the issue was only identified after your conclusions, you should approach the structure of your presentation as a storyteller is the story you want to tell that drives the structure of the presentation. Not the way you analyze the data. And when you present your conclusions and recommendations don't forget that the manager has limited resource and time. At the end of the day, she can only focus on what is expected to have the maximum impact from the smallest effort. Remember what is said about the need for efficiency in most of the modules. Keeping in mind, when you're writing your own recommendations, you need to focus on the most efficient actions to take. So, once you've understood what are the actions that could solve the issue you've raised, you need to make sure. Prioritize those actions according to their efficiency. Do not make an ordered list of all the actions that could be taken. Present quick wins or the low hanging fruits first. Those actions that could be taken easily because needing little effort, but would have huge positive impact on your business. And only then explain what should be done on the longer run that will be impactful as well. But that may require more effort. And again, you'll probably to decide to discard the less impactful and realistic recommendations in any case. If it doesn't sound relevant or easy to do on paper, it will probably be worse in practice. And so, you need to connect logically the issue that you've raised with the conclusions that you've drawn. Since we're dealing with business analytics, you need to explain why you need the data you've collected to address the issue and why the methodology you've chosen is relevant. That doesn't mean that you need to enter into all the little detail of your approach. But it means that your presentation should be self-contained. It should contain everything needed to understand the why, the what and the how of your results. I often do the test of the executive assistant. There is a smart executive assistant who understands your analysis. Someone who knows the business but is not a computer scientist or statistician. If the answer is no, work on the presentation until it's clear enough, and the story flows well. Remember something. The point is not to show how smart you are, and how advanced your methodology is. The point is to obtain the buy-in from your audience. And nobody likes to feel stupid, or to listen to the bragging of the first in the class. Be as clear and to the point as possible. It's in your own interests. In the same fashion, do not start explaining in details why something didn't work. Very often, because of your work, you will start conducting analyses that will be fruitless. It is very frustrating, and it is very tempting to explain at length, afterwards that you've worked for so many hours on something that has been shown to be irrelevant in the end. Sometimes, it may indeed be a question raised by the audience, but is not really relevant for your conclusions, you may decide to keep it in appendix. That's fine. But if it's not really relevant for your story, discard it and move on. Just say one could have made this analysis, we did it and it didn't work because of x, and then go on with the rest of your story line. I know it will be difficult to let go, because you're on the task. But unfortunately, nobody else than you cares, so don't spoil your story with detours that are irrelevant for your audience. And that is actually the question that should drive everything else. What is relevant for your audience and what's not? And that depends on who is in front of you. So who's your audience? Is it an executive? Be very concise then with one or two executive summary slides. Emphasizing what should be done and what will be the expected benefit. Is it a technical person? Then you should take the opposite direction and you may want to describe the measurement in details. The same goes for the style. Some people like that you start from the big picture and zoom into the details afterwards. And some people instead, like that you do the opposite. Build your story piece by piece, and present your overall conclusions only at the end. To wrap up on the story telling. Let's say that your presentation shouldn't look like a list or a series of analyses conducted separately. A bunch of interesting facts, but not really related, whatsoever. It's a story. So start first with the pin point to solve, an opportunity to take. Think at good movie you've seen recently. Probably, starts with an average Joe who is suddenly in front of a problem. You should have the same type of hookup. Then, explain how you approached it. Describe the data, but only what's relevant for your analysis. Do not waste too much time on what didn't work and focus on having a flow of insights that follow each other and make sense. You want to attain your conclusions logically and propose recommendations that will look like there's almost no other common sense actions to take than those that you propose. And the way you will tell your story will depend on your audience. What's relevant for them, and what's not. Some rationals will resonate better to a certain type of audience, while others won't. If you do your homework and adapt to your audience by telling your story, most of the stakeholders will buy in your recommendations by the end of your presentation. What you want to obtain is a shared representation of the reality between you and your audience. This is a key success factor in getting people to move in the same direction. And it will work even better if they feel they participate in the reflection, and come to the right conclusions by themselves.
