From Algorithms to Impact: How to Communicate Data Science Results Across Audiences

Author(s): Pawel Rzeszucinski, PhD

Originally published on Towards AI.

Introduction

Working on a data science project is exciting. Understand the context, discuss domain-specific topics with domain experts, take the data by the horns, and tweak algorithms. Working towards providing business value can be truly rewarding. However, at the end of the journey lies a task that many fear — presenting results to stakeholders who, more often than not, live outside of the data realm. This might seem like an easy job — showing off what we did. We’re the experts, right? We know our stuff. That’s all correct, yet the difficulty I’ve observed over and over again lies in aligning the content we want to present with the expectations of the people in the viewing seats.

Two worlds collide

Working on a specific task often translates to starting with a broad perspective, and as we move toward the solution, our perspective narrows down. We tend to get comfortable with assumptions, estimations, interpolations, and best guesses. Preprocessing data, performing EDA, modeling — it’s all very time-consuming, often mundane, and frustrating. But soldering through difficulties makes us very appreciative of what we do and inevitably leads to some sort of pride in what we achieved. When it comes to sharing the results with someone outside of the bubble, we tend to share the quote of Christopher McCandless “Hapiness only real when shared”. The quote is very relatable, but not always in a business setting…

Stakeholders have a very specific and well-defined interest in what we do. In a business setting, I tend to divide my stakeholders into three distinct groups:

1. Team members and team manager: This group is deeply involved in the project and, therefore, has a comprehensive understanding of both the technical and business aspects. When presenting to your team members and team manager, you can delve into the intricacies of your work. This includes discussing algorithms, data processing techniques, hyperparameter tuning, and any other technical challenges or successes you encountered. Your language can be technical, and it’s appropriate to use industry jargon and detailed explanations, as this audience will likely understand and appreciate the complexities of your work. However, it’s also important to discuss the business outcomes and how your technical work contributes to achieving these goals. This dual focus ensures that your team understands both the technical excellence and the business relevance of the project.
2. Project sponsors (e.g., Division Head): Project sponsors, such as a division head, are typically more invested in the business outcomes of the project. While they might have a basic understanding of the technology, their primary concern is how the project contributes to the broader goals of the division, such as revenue generation or cost savings. When presenting to this group, adjust your language to be less technical and more focused on the business impact. Use clear and straightforward language to explain how the results of your project align with business objectives. While you should minimize technical jargon, be prepared to provide some technical details if asked, as sponsors might occasionally want to understand the high-level technical aspects of the project. Focus on the return on investment, improvements in efficiency, and other key business metrics that are important to this group.
3. C-Suite executives: When presenting to C-suite executives, such as CEOs, CFOs, and CTOs, your focus should be on the strategic impact of your project. This group is interested in understanding the project from a high-level, “helicopter” perspective. They want to know how your project aligns with the company’s strategic goals and how it impacts the bottom line. Avoid technical details and use non-technical language. If complex concepts are necessary, use analogies and simple explanations to convey your points. Your presentation should be concise, focusing on business outcomes such as revenue generation, market impact, competitive advantage, and cost savings. While it’s unlikely that C-suite executives will delve into technical specifics, have those details prepared in hidden slides or an appendix, just in case they are requested. This approach ensures that you’re ready to address any questions without detracting from the main, business-focused message of your presentation.

The following steps should be taken into consideration when putting up a presentation about your project. I’ve presented them in the order that should align with the flow of your presentation.

Ready? Buckle up. Especially the first one might be a bitter pill to swallow…

1. Nobody cares about your algorithms. If you could only take away one point from this text, it is this one: senior executives are (almost always) only interested in the strategic and business implications of your data science project. While the technical aspects such as algorithms, hyperparameter tuning, and data transformations are fundamental to your work, listening about them is a — sorry to say that — waste of time for busy, business-oriented stakeholders. You’ve invested significant time and effort in these areas and should be proud of your technical achievements, but it’s crucial to save them for your teammates only. When communicating the results to the business, maximize their Return On (time) Investment by focusing on core business outcomes.
   Having said that – come prepared! Include detailed technical information in your presentation, but in a way that it can be referenced only if someone shows interest. See the last point for more.
2. Clearly state the project’s goals and expected outcomes (in monetary terms if possible): Begin your presentation by clearly articulating the objectives of your project. This alignment ensures that everyone in the room understands the purpose and expected outcomes of your work. If everyone nods their heads — phew, you safe. That’s not always the case, though. Aligning understanding and expectations is critical — above all, it’s your safety policy.
   If the project is expected to yield tangible results, such as increased revenue, cost savings, or improved efficiency, make sure to highlight these. Stating the objectives in monetary terms can be particularly effective, as senior managers often think in terms of financial impact and return on investment.
3. Explain your metrics in layman’s terms: You have measured the performance of your solution in some way. This metric, or set of metrics, essentially determines how dependable your solution will be to the business. Therefore it is important that you make sure everyone has a clear understanding of what has been measured and why. While, for example, accuracy is easy to understand even for the less technical crowd, other metrics like precision or recall can come across as confusing, especially when heard for the first time. Make sure to use simple, relatable examples to explain the concept on a high level. This could involve creating analogies or scenarios that help illustrate what these metrics mean in the context of your project. Avoid jargon and technical terms as much as possible. The goal is to make these concepts as accessible as possible to an audience that may not have a data science background.
4. Demonstrate final results in a contextual manner: Present the final results of your analysis, such as the achieved precision or accuracy, and immediatelly explain what these numbers mean in practical terms. This helps in visualizing the impact of your results in a real-world setting. Again, paint the picture using monetary terms if possible. Don’t only focus on the relative gains from having the model on production (increased sales by X), but factor in the costs of running and maintaining the solution.
   For instance, if your model achieves a certain level of precision, translate that into how many correct predictions can be expected versus how many might be errors. The second part is especially important, and be patient receiving feedback: not everyone is aware of the fact that ML/AI solutions make mistakes. They do, by the very nature of their operations, but folks who deal with these topics for the first time, may perceive these solutions as a magic wand capable of the unrealistic. Expectations management is very important.
5. Transparently discuss assumptions and their impact: You’ve presented the results. Work done; celebration time!
   Not yet…it’s vital to acknowledge any assumptions that were made during your work. Clearly state these assumptions and discuss how they might impact the results and conclusions of your project. This transparency is key to building trust in your solution. But perhaps more importantly, this is another insurance policy of yours — if you come clean with what might happen if the assumptions don’t hold, you will minimize the need to answer some pretty uncomfortable questions in the future.
   If you made assumptions with the help of your business partners or subject matter experts, make sure to mention this: it adds to the trustworthiness of these assumptions and shows you approached your task professionally.
6. Highlight data limitations and potential for future improvement: This point starts to be a bit too much for the top tier stakeholders (C-level), so probably spare them the details, but definitely mention it to the folks from the other audience type. Discuss any limitations in your current dataset and how these might affect the outcomes of your project. For example, if you’ve used (half-)synthetic data for training purposes, explain this and discuss how the introduction of real-world data is expected to influence the model’s accuracy. This shows that you’re not only aware of the current limitations but also actively thinking about how to enhance the project in the future.
7. Outline future steps: Business stakeholders are strategic thinkers — they are always interested in the ‘what’s next?’. Make sure to discuss your future steps. It doesn’t matter if these are steps for productization, further data collection, spin-off research, or plans for scaling the solution. Signaling what comes next is a great tactical move —you are planting the seeds for future investments and can answer some early questions on the spot.
8. Be prepared with technical details as a reference: As mentioned a couple of times already, you should be prepared to answer technical details, but don’t force them on your audience. Prepare a detailed technical appendix or hidden slides, or have a separate presentation ready that delves into the more complex aspects of your work. These should be readily available for reference if a member of the senior management team requests more in-depth information.

Conclusions

Effective communication in data science hinges on aligning your presentation with your audience’s interests and understanding. For team members and managers, a detailed technical discussion is suitable, as they appreciate the intricacies of the work. Project sponsors, such as Division Heads, require a focus on business outcomes, with technical details provided only as needed. C-suite executives, on the other hand, need a high-level overview emphasizing strategic impact, with technical complexities distilled into simple, relatable terms. Across all groups, being prepared to delve into technical specifics upon request is crucial, but such details should generally be kept in reserve. Ultimately, the goal is to seamlessly integrate technical achievements with business value, demonstrating the overarching benefits of data science projects to the organization.

Would you add/remove/alter anything? Let me know in the discussions section!

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI