The Business Side of Data Science: 5 Tips for Presenting to Stakeholders
By: Eric Kleppen
Tags: Data Science, Business Intelligence, Business Analysis, Business, Professional Development

The Business Side of Data Science

Things can get intimidating pretty fast when you turn a hobby into a profession. Although I’m not a professional Data Scientist nor Machine Learning Engineer, I work with them on a Data Science team as a Software Product Analyst (similar to Business Analyst). I write code, analyze data, help make business decisions, and present our team updates to an audience of 80+. To anyone looking to get into the field, Data Science is a lot more than just algorithms and modeling. When you start working with business leaders, they expect you to be able to explain things in a digestible way.

I do the following to make sure I’m at my best when presenting to business executives and stakeholders:

1.Prepare and Practice

2. Explain the business value

3. Include images when possible

4. Create a cohesive story

5. Avoid jargon and tech-talk (mostly)

Although these seem straightforward, you might be amazed at how many meetings I’ve been in where the presenter doesn’t meet any of these criteria! Even just doing a few of these things can go a long way and help you come off looking professional.

Photo by Brooke Lark on Unsplash

Prepare and Practice

When the position opened up, my domain knowledge, background in Technical Writing and my enthusiasm for Data Science landed me the job. As I went through on-boarding and cut my teeth on some small projects, my boss asked if I’d take over the team’s Sprint review presentation in front of stakeholders. I jumped at the opportunity to sharpen my presentation skills.

When I started doing them, I was still relatively new, didn’t have a solid handle on all my team’s projects, and didn’t understand the audience’s level of knowledge, but at least I sounded polished. That’s because I prepared and practiced. I didn’t try to wing it! Depending on how long I’m presenting (normally 10–20 min), I’ll start putting my ideas together at least 24 hours in advance. I write notes, I craft slides, I talk through it from start to finish, timing myself, multiple times. Because I have a lot of anxiety, I find it especially helpful if I run through the presentation right before bed too. My goal is to sound confident and present clearly.

I share my slide deck with my team to get feedback, and I generally meet with them to make sure I’m doing justice to their work since I’ll be talking about it. Overall, I probably put in 4–6 hours on prep and practice. That will likely decrease over time as I continue to grow into the role, but for now, it is what makes me feel comfortable going up in front of 80 people.

Explain the Business Value

If you’re talking to an audience of business people like customer-focused teams, executives, and/or management, you should describe how your work is adding value to the business. When I started giving my presentations, I was too focused on explaining the technical accomplishments we achieved during our sprint. Although interesting, some of the audience didn’t understand how our work was adding value to the business. I adjusted my approach and started presenting our work from a much higher level. I tie our work to our roadmap, explain how we’re approaching enhancements and innovation, and use deliverables to convey business value.

It can take time to formulate a way to connect the dots between the team’s technical work and the company’s mission, but as I gain experience working with business teams, and as I improve my business analysis skill-set, it has become much easier. I use resources like batimes.com, Harvard Business Review, and Medium to keep up to date on trending business analysis content. I’ve also taken a couple of online Business Analysis courses, and an Intro to Agile certification to give me a foundation.

Include Images when Possible

Some of the first critical feedback I got on my presentations said I need to include more demos or diagrams. My slides weren’t overrun with bullet points, but I needed to do more showing and less telling when describing my team’s work. Instead of showing them lines of code, I present things like workflows or a topology… things that easily translate into images.

Example Diagram

I also include images to help convey business ideas and frameworks. If you’re making your own, I find pyramids or pillars are a commonly used for stuff like this! For example, I’ve used similar images in the past:

Various Business Frameworks and getthematic

Using images can help keep the audience focused, and it can help keep the presentation lively. Although I want people to think of me as a professional, I can’t help but let my goofy personality show through a little. I have fun with it and try to throw a subtle meme or Easter-egg into the mix, just to re-engage the audience and keep things light. Just make sure to know the audience and check with your team before adding personal touches.

Create a Cohesive Story

Creating a story can seem like the most difficult thing to do, but once you get good, it feels like you’ve moved up from amateur to pro. When crafting my story, I often start with a few ideas, and as I’m practicing, the slides start to arrange themselves. I find a nice way for the words to flow, and I can come up with an overall theme because I gave myself enough prep time!

Leverage things like the team’s vision or roadmap to come up with a theme that ties the work together. My team is working on more projects than I can present in 10–20 minutes, so I use our roadmap to group the projects in ways that make it easy to come up with a theme. For example, a theme could be internal analytics one week, and customer products the next. The team works together to decide on what deliverables will be ready to show.

Sometimes a teammate wants to demo or present their own work, so I make sure the story transitions smoothly into their demo. The goal is to make the team look as good as possible, not make me look as good as possible. Keep the ego at bay and focus on communicating with the team to have smooth transitions.

Avoid Tech-talk and Jargon (mostly)

Knowing your audience is technical communication 101. If the audience is there to hear you describe your code, by all means get technical. If the audience is there to hear how you’re making them more money, spare them the tech-talk.

To sum up the advice given to me by our Head of Learning Sciences when discussing deliverables for a stakeholder update:

“The audience has never cared about evaluation metrics. They assume if we are willing to put something into production, we have evaluated it.”

Keep things like that in mind when putting together images and deliverables. Don’t simply try to include something because there is visual output related to it. To evaluate models, we look at graphs. Just because the graphs are valuable to us doesn’t make them valuable to a business executive.

Instead of jargon, keep concepts simple. If you have to use jargon, explain things clearly. As the communicator, it is your responsibility to clarify ambiguity.

Final Remarks

When I first learned about Data Science, I was overwhelmed by the technical things. I was fairly new to Python, hadn’t taken a math course in over a decade, and wasn’t even really sure what the difference was between the two fields. I spent a lot of time studying, I attended a six month data analysis bootcamp, and I made connections with people at work and in the local DS community. When I landed a job in the field, I had to get up to speed and present to business teams and stakeholders. These are my tips for coming across as a professional when presenting your projects:

Prepare and Practice

Explain the business value

Include images when possible

Create a cohesive story

Avoid jargon and tech-talk (mostly)

Check out my other tutorials to learn more about Data Science and Programming!