One of the most difficult parts of any analyst’s job is packaging and presenting analytics work for a business audience. It’s a matter of showing the “So What” rather than just the “What” of the data. As someone who not only does a lot of presenting, but also coaches others on how to improve their deliverables, I found myself in need of a consistent way to structure results that minimizes the technical or mathematical description and instead focuses on the business implications.
Here’s my framework, along with a handy acronym: FIRST
You have to present the facts of the model or analysis. These are the numbers that came from all your hard work. Talk about the hypotheses tested, what fell out, what stayed in, results of tests, etc. Detail any rabbits you chased in the data (anomalies, unexpected results, iterations, etc). Include visualizations wherever able to succinctly illustrate what you saw. This section is of particular interest to other data scientists, model auditing teams, and the statistically-inclined.
Now read into the numbers or the model and weave the story. Describe what you learned from the analysis or model and, especially, what it means to the business. Explain what the findings mean in a broader context.
Document further analyses, follow-on projects, or deeper dives that you recommend pursuing. Also note any follow-up questions that your business stakeholders come up with based on the findings and insights. Build your own backlog of projects and then track them down. This is where you plan to tie up loose ends.
Describe what you think the business should do, or how it should change, to make use of the insights or models. If there are specific processes that would benefit from incorporating a model or API, indicate how this might be done (do not show code – just say how it would revamp the process). How does this help the business make better decisions about their initiatives?
This section details who is doing what coming out of this analysis. If there were specific expected actions to be taken based upon results, identify whom is needed to complete them. Any time frames necessary should also be outlined.
Presenting Analytics in Documents
Putting FIRST into a document is pretty straightforward. Set up the project at the top, laying out the key questions, expected actions, and the planned analysis steps. Then include the FIRST sections with the majority of the content. Document as you go along so that you capture the findings roughly as they occur. This helps to ensure that you present all of the permutations of analysis performed.
Presenting Analytics in Slides
Most of the time, when presenting analytics, we are called upon to use slides or a slide-like format for conveying information. Again, present the project overview and key questions. Then immediately put forward the key insights. Yes, this is out of order for FIRST. However, the next section is where FIRST comes into play. For each key insight, present the FIRST elements on a single slide.
An example might be that customers using discounts are more valuable over time. On a slide, show a graph comparing the spend patterns of customers with and without discounts. Provide a bullet point indicating that this is the key insight. Then outline additional steps for:
- analyzing types of discounts or time periods of discount as a recommended follow-on,
- using promotions to increase total basket size as a suggestion, and
- planning an upcoming promotion as a takeaway.
Wrap up with a summary of next steps so that there is a clear list of actions to be done.
What methods do you use today for presenting analytics? If you give FIRST a try, please leave comments about how it goes with your key stakeholders.