AgileData #48 - Data Storytelling with Kat Greenbrook

Foreign.

Welcome to the Agile Data Podcast, where we talk about the merging of agile and data ways of working in a simply magical way.

Welcome to the Agile Data Podcast. I'm Shane Gibson.

And I'm Cat Greenbrook.

Hey, Cat, thank you for coming on the show today. Today we're going to talk about that exciting subject of data storytelling. But before we do that, why don't you give a bit of background about yourself to the audience.

How far back do we want to go? Let's start with university. I went to university to actually become a vet. That didn't quite pan out, as you'll see from my story that I'm about to tell. My career has been a mix of learning what I do want to do, but also learning what I don't want to do. Starting off going to university to be a vet, realising I didn't want to do that, switching to science. I got a degree in science, majored in genetics and biochemistry before realising I didn't want to be a scientist. So the next step after that was to fall into some sort of analytics role. And I fell into quite a few of these because I realized that this space was where I did enjoy working. I do enjoy analytics, so I've done lots of different business analytics roles, from your more reporting analyst, insight analyst, through to your more data science predictive modeling work. And then I realized after probably a good 10 years in the space that I was becoming very disheartened by the field. I was building predictive models that just weren't being used and I was working for organizations who didn't really understand how to operationalize the analytics. And as an analyst, when you're doing all this work to try and build these amazing models and only to find that they're just sitting there doing nothing, it's not a great feeling. And so I found myself in this position. Do I carry on doing this job that I do enjoy, but I don't feel I'm really adding any impact, or do I do something different? And so I decided to try and switch careers. I did a diploma in digital design. I was working as an analytics consultant at the time and I had this little secret goal to maybe just completely get out of analytics. I thought, I'm going to try and become a graphic designer because maybe I could create more of an impact doing that. But as fate would have it, this was around about the time that data visualization started to become popular. There was this new wave of data visualization at the time, so Tableau was introduced to the New Zealand market. Power BI came a couple of years later and there were a whole lot of different analytical tools that started to incorporate more visual ways of displaying their information. So I found myself at the right place at the right time to be at the intersection of these two fields. So the intersection of all this data experience that I had, but also all this design knowledge that I was learning. So my plan to go off and be a graphic designer was put on hold. I still have the degree, but did enjoy and lean quite heavily into this new field of data visualization. And that's where I've stayed and played data visualization. The field has evolved a lot since then, so we're talking eight or nine years ago that I was studying. One of the fields that it's emerged into is this data storytelling field, and data storytelling is this evolution of data visualization. So what we've learned from this data visualization journey has moved us or pushed us into this data storytelling field, which is more the communication side of. And so that's where I'm finding myself today. I set up the company Rogue Penguin, about, I think it's seven years ago now, and this is what I help my clients to do. So how do they use data visualization and data storytelling to help communicate the insights that they're finding through data analysis? In short, that's my journey.

Lots of people in the data space seems to have come here by accident. I often have a saying that if you're not having fun, you're doing the wrong thing or doing the thing wrong. And I'm always intrigued with bioscience because I see a lot of people in analytics come out of bioscience and into data. Why do you think that is? Do you think it set you up for a set of skills in terms of understanding that scientific method and you could apply that to data? Why do you think people that do those bioscience degrees and start off in that career tend to jump over to data space often?

Yeah, that's interesting. I don't know if it's just bioscience because the scientific method relates to all disciplines of science. So it's not just unique to bioscience. I do think there's a lot of statistics that is learned as part of bioscience, so I think maybe that does cross fields, especially with this data science space. You can apply what you learn through those bioscience degrees to business analytics, and it does convert quite well.

I often talk about skills, not roles. So for me it's the fact that you've learned some skills in that bioscience space that you can apply into the data science space. It's the same set of skills. It's that problem solving, that structured analysis, that stuff with a hypothesis and work your way through and prove it or don't prove it and you're just applying it to a different role. And that's the beauty of what we do in data when we steal patterns from other domains. And for me also that data storytelling seems to be this blend of art and science, which is again is a bit weird because normally you fit in the eerie, very arty, wordy drawing, picture y side of the world 1. Is it left or right brain? I can never remember. Or you fit in that structured science. Everything's a method and there's no interpretation effectively creativity in that side. Yet data storytelling, that visualization and telling a story with data seems to be a weird blend of art and science together.

Yeah, it's interesting because I used to have that opinion. But the more I've learned about data storytelling, the more I realized that you don't have to have that what's stereotypically seen as this art side because not all data stories are told visually. So if you choose to tell a data story in a non visual way, you don't have to have any kind of art or design background at all. For me, data storytelling is about communication. And if you can look at the results of data analysis and you can pull out what's important and you can craft that into a specific message and then just tell that to an audience in a very clear manner, whatever that method is, it could be visual, it could be verbal, it could be written. That's data storytelling. And so I think we get this view of data storytelling that it is this blend of art and science, because the majority of people that are going into this field of data storytelling are probably coming at it from a data visualization standpoint. So they've had this love of data visualization and are wanting to push it a little bit further. And so they're coming from that pathway which generally the people that are passionate about data visualization are those people that have that kind of art background or art passion. So I think yeah, the more I learn about it, the more I realize that it's not necessarily this arty thing.

Okay. So you can see it coming from two sets of skills. It's the people that work with the data, munch the data, wrangle the data, beat that data into helping us give the action the outcome we want. They can use data storytelling to articulate that data in a Better way, or if you're on the viz side, that presentation that consumption, that last mile, again, you can use data storytelling to enhance your graphs with something that has more context.

Yeah, absolutely. I think there's a lot of strategic thinking involved in doing data storytelling. I think that that can make the difference between a good powerful data story versus one that doesn't resonate.

You do a lot of training, so as well as doing data storytelling, you now spend a lot of your time training teams on how to do it themselves. What's the mix of people in the audience in terms of the people you've trained? Is it the majority of them come from a busy side of the paradigm or do. Is it half and half? What's your gut feel? What's your data on the split of where they come from?

Generally, the people that I train have analytics backgrounds, so they come from large organizations who have large either analytics or data science teams. And those teams are challenged with communicating the results of their data analysis. So they may have some who really enjoy the data visualization side of things, there may be some who don't, and they're just really into the data science and they want to be able to explain what they do, what they found in their analysis to create that business impact. Because they do realize that if they don't communicate what they found in the work that they do, they're not going to create any sort of impact in their role. And when you're doing any sort of role, regardless of what it is, and you realize you're not creating impact, it's not a nice feeling.

If we think about data storytelling as a skill, not a role, then it's something the whole team should learn. Every person in our team, every part of that information value stream can be enhanced. If we're telling stories with the data that we're working with. So it's not just at that last file, it's not just presenting that story to your stakeholders. You can actually use the data storytelling skills all the way through that value stream because telling a story, it makes things interesting.

At the end of the day, it's communication. And so if you think about the amount of times that you communicate in the role that you do, every time you send an email, every time you have a conversation with somebody, you're communicating with them. And because data is so much of a part of how businesses operate these days, it's just becoming part of the conversation. So if we think of data storytelling as a way in which we weave data into these conversations, we're doing it all the time anyway. Absolutely. People in any sort of role who are using data and have to communicate what it means should have an awareness of how to do data storytelling. You're always going to find that there are some people who are more passionate about it. And so you have these. I know you've talked about T skills. So having a team that's across the basics of data storing, telling and then a couple of people who go deep into it, that works really well. If you're working as a large team and have to communicate what you find, often it's good to have those champions within a team. But yeah, absolutely, there should be the high level idea of what it is and how to do it across all teams in that data analytics space.

And there's a whole push at the moment around working and describing the value that a data team delivers. Because, you know, with the financial downturn, we've seen large data teams get canned basically because the organization doesn't see a lot of value for them. And I think one of the reasons for that is the companies have hired too many people and it wasn't sustainable. But often data teams are seen as being in cupboards is what I describe it. So the team work in isolation, they take a set of requirements, they then work in their cupboard, do that data work and then there's a presentation or a way of delivering at the end, and then stakeholder engagement really is at the beginning and at the end and there's nothing in the middle. So for me, the skill of data storytelling is really valuable as we do all of that work, because then our stakeholders can see the story around that data that we're working with and they understand what we're doing and they can see the value they're going to get out of it. And that constant engagement has value. So for me, again, it's get the team to increase their skills. Like you said, there are people that love to do it, love to steal stories. Probably other people that used to do drama at school and in the school play maybe, and so they'll naturally pick this up. Extending the skills of your team has value for all the team members and your team and the organisation.

Yeah, it's funny you say that the people that do drama in high school, because I hated drama. Oh, my goodness, I was such a shy kid. And so I think there's a difference between writing the data stories. They're pulling out the message of data and figuring out what that is and how to frame it, then telling that data story. And so telling it involves presenting sometimes and yes, there's two different people that gravitate towards those things. But you don't have to be that extrovert drama kid to be a good data storyteller. It's not a pre record.

Okay, you got to do debating then. Risky. No. Okay.

So one of the things I was coaching, we were lucky enough to get them to go through your course and I was lucky enough to sit in the back and learn by watching. And for me, one of the core patterns that came out of what you taught was this idea of abt. So why don't we start off with the whole ABT pattern. For me, that was the pattern that stuck in my head for some reason and the pattern that I'm constantly going back and trying to remember to use. So talk us through the ABT thing.

So for those who don't know, ABT stands for the words and but therefore and it is a particular narrative structure. Randy Olson created this idea of the anderbut therefore ABT narrative structure. And it's based on the three act structure. So anybody who's done film studies has probably heard of the three act structure. It's been around for centuries. It's nothing new, but having the words and, but therefore they're very conversational and so they're very easy to weave into whatever it is that you're talking about. So the ABT has been described by Park Howell as the DNA of story because it is so simple and it can be applied to so many different things. And I can give you an example. I do this in my workshops. I give high level plot lines to movies in this narrative structure framework. So using the words and but therefore I can describe the plotline of a movie in those three acts. So I've got one here for you. Africa's animal kingdom is ruled by lions. And Simba is a young lion who will succeed his father Mufasa as king. But when Simba's uncle Scar murders Mufasa, Simba is tricked into thinking he is responsible and flees his homeland. Therefore, Simba needs to overcome his guilt before he can take his rightful place as king. So that's an example of the and, but therefore ABT framework. And that's story. So story to me is how you arrange the information that you have into a framework or a structure that's going to engage an audience. And there are lots of different narrative structures out there. A common one that's talked about is the hero's journey. You've probably heard of that before. I think that one is quite long, quite involved. So when you're trying to do data storytelling within an everyday setting within a business, that one's just a bit too complex. So I do Randy Olson's ABT because it is so simple and it can be weaved around data very easily. So I'll give you an example of how we can weave it around our data to create a data story. If we look at customer numbers, let's say that's our data metric. This is a story that we could put that information into this narrative structure. So, for example, last year we had 20,000 customers and held a large proportion of market share. But this year, customer numbers dropped 25% because of increased competitor activity. Therefore, we need to do something to win back our customers. So it's a very simple example of a data story, but you can see how you can weave this information around these three words to put what you've got into these three acts to create that story structure.

The reason I love it is it aligns with a couple of boxes on the information product canvas. When we talk to stakeholders, what I suggest people do is the first thing they ask a stakeholder when they're gathering. The kind of idea of what people want us to work on is this idea of what core business questions you want to answer. In that scenario, we'll hear something like, how many customers have we got and what type of customers are they? And then what I tend to say is, okay, now if I give you that information, if I answer that question with data, what action are you going to take? So it's going to be, where are we losing market share? And I want to go and do a save offer. Okay, and if you do that save offer, what's the outcome? The outcome is we retain 10% more customers from what we were losing. And then you can go, okay, what's the value to the organization if we do that? Theory is increased lifetime value, more margin, more revenue, whatever. And the reason we do that is now what we have is a very clear value proposition that can be prioritized. So when our stakeholders are looking and prioritizing the work that can be done, they can look at those statements and go, that one has more value to our organization than that one. So let's do that one first. And for me, the ABT is just another way, another language for doing that that we can apply and actually apply in the way we present that story. Because now we can say, this is how many customers we had and we're losing them. And the action we need to take is this. And the outcome that we expect if we take that therefore, this is the value to the organization of us doing that. Can we do that? Yes. No. And so that language alignment of using this early in the process and delivering that data story at the end has massive value for me because we're just reinforcing that value to the organization at every stage in the way we.

Yeah, absolutely. This narrative structure is not about the information, it's about how we arrange the information. And we can arrange the information in whatever way we like. And this is what it means to craft a story. This is the art that's coming into the storytelling. So given the framework using these three words, how we arrange the information that we want to communicate around those three words to create that narrative, that's completely up to us. And so you can have lots of different versions of data stories, and they all may involve the same information, but the information is arranged slightly differently. So therefore, you get different versions of these data stories. They're all true. But depending on your audience, one might work.

There must be immense pressure though, to be given the therefore and then try and find data that supports the A and the B to support the therefore. So effectively our stakeholders know what action they think they want to take. And now they're telling us to go and find data to support the that action, that therefore. Do you see that?

Yeah. And this is the danger. And I think this is why data storytelling in some ways gets a little bit of a bad name. Because we think maybe it's just about making up a story to fit whatever preconceived idea that we have or action that we want to do or take. And yeah, that is a danger, but there are certain storytelling ethics that we need to live up to, especially in terms of data storytelling. It's just like analytics. Right. And so when you go through the analytics process, there are certain things that you have to do as part of that process to make sure that you're being honest in the way that you're looking at that data. And it's the same with data storytelling. There are certain things that you need to take into account, and one of those is the whole cherry picking. You can't just start with this framework and say, oh, I have the answer. I want to influence people to do this based on what I think is in the data. So I'm just going to go and find the data to support only what I think. That's completely inequality of cherry picking your information, and that's something you shouldn't do.

If we think about analytics and we think about supervised and unsupervised learning. So this idea that I want to unsupervise, I want to look at a big blob of data and I want to see what insights it's telling me tells me where things look interesting. And I'm going to go and do some investigation in that versus supervised learning, where I'm actually going through some steps. I've got some questions and I'm trying to answer those. From a data storytelling point of view, which way does it tend to work? Is it that I have a bunch of data and I'm looking for stories that are interesting and have value to the organization, or I have a story boundary that I'm then seeing? Does the data support that? Therefore, is it both? Does it not really matter?

I don't think it matters which one you go with. You wouldn't communicate unless you were trying to achieve something. So every time we communicate in a business, we're trying to achieve something in terms of we might send an email because we want someone to do something or we want someone to read a certain report because we need them to understand this information. Whatever it is, we have a goal. And it's the same with our data storytelling. It's not about making up the information because all that information has been analyzed as part of the analytics process. So I do see data analytics and data storytelling as two separate processes. So the results of data analytics produces data insights. So generally we end up with a whole lot of different data metrics as part of, hey, these are all our insights. Now storytelling happens after that and we have to think about before we start our storytelling processes, what are we trying to achieve? So why are we communicating these specific insights to this specific audience group? What are we hoping to do here? So are we trying to encourage them to take a specific action? That action could be to approve a business case, or are we trying to get them to understand certain information? So maybe we need them to upskill on a certain part of the business. So having a clear idea of what we're trying to achieve with our communication will enable us to pick out those data insights that are appropriate for what we are trying to achieve. So it's not about cherry picking in terms of going through the analytics process and tweaking that to fit our needs, because that's already been done. It's a separate process with data storytelling. It's just about how do we communicate the insights that are appropriate for our audience to achieve the goal that we are trying to.

So let's just drill down into that way of working a little bit. Because you talk about discover and inform and educate. You do say there is a typical way of working and buckets of where you do things for a certain reason before you get to that final story. Have I got that right?

This Discover, informant and educate comes from data visualization. So these are the three reasons that you would visualize data within a business. And because so many people come at data storytelling through data visualization, I think it's good for people to understand when they are creating a data visual, what is their reason for doing so. Because we don't need all of our data visuals to tell stories. This is a myth. And I've heard it, I heard it a lot when I was first getting into data visualization is that all data visualizations need to tell stories, whereas that's not true. Discover visuals are part of the analytics process. And we create these as a way of helping to uncover those insights in the first place. And so we're using them as a tool to help make the analytics process a bit easier. Inform and educate visuals, those are two types of visuals. They're both data communication because we're designing them for somebody else. Inform visuals, their job is to make the data easy to access. So their job is not to tell stories. It's just to help make it easy for people who already understand the significance of those metrics to access that information. So you'll find inform visuals as part of dashboards. Dashboards present information in a very ordered way. They make it very easy for somebody to see the latest measurement. In my view, DAT data storytelling tools, they are there as more of an operational tool to help make it easy for people to quickly access the information they need. The last reason to visualize data is to educate. And this is where your data storytelling comes in. So if you're trying to upskill your audience, whether it's around a specific data metric or a specific topic or business area, whatever it is, educate visuals are part of the data storytelling process. And so if you choose to tell your story that you've written in a visual way, educate visuals can help you do that. But I think the majority of people coming into the field of data storytelling will come in through that data visualization pathway. And so they need to understand when the need for data storytelling involves creating that visual and when it doesn't.

So let me replay it back to you in a kind of different lens to see if I got it right. So, yeah, discover is all about our slicey, dicey, notebooky us playing with the data, trying to find that insight, trying to find that story, trying to find things that are interesting, things that hold together and we can prove. So it's tools we use for ourselves to understand that data so we can do the next steps and then inform is automation. We're saying, here's some information, here's a KPI, here's a number, here's a trend, here's some data, here's some information. We want you to be able to get access to it really quickly whenever you want to do it without us. And so we're doing our dashboards, our charts, our reports, that kind of stuff so somebody else can self serve without us. Because the data is immutable, that information can be automated and we don't need to be involved. Once it's automated, we don't need to be involved between the information and the consumer who's using it. So fits in that space and then educates narrative, that's words. Now we may augment the words of pictures because we love to do that, but it's telling a story, it's a bunch of words and those words are very context sensitive. About the information we're looking at, the point in time, the story we're trying to tell, the action we're trying to enable, the outcome we're trying to achieve. So that narrative be automated. And we'll talk about that maybe in terms of chatgpt in a minute. But it's the words and the way those words describe a context that's really the key to that educate that narrative, that storytelling process. Is that right?

Yeah. So educate visuals help to tell a data story. And so you might find that you have just one educate visual and that's okay to tell the data story you've written. Or you might have multiple educate visuals because that's what's needed to tell a more complex story. And so educate visuals really do rely on having an understanding of what that story is before you can create them. So if you don't understand your narrative, if you don't understand your message, if you try and create these educate visuals, you will fail because they do rely so heavily on that narrative.

If I'm ever drawing something and I'm really bad at drawing or I'm designing something, what I know is I know I love to fill in white space. Wherever I see a bit of white space, I just want to put something there. Oh, there's something interesting I can put in that space. But what I've learned working with very talented people over many years is white space actually has value. And that often removing something has far more value than adding something something. So I'm guessing that our natural reaction of starting with a bunch of visuals and then trying to write a story around it is an anti pan. What you should do is write the story and then go, do I need a visual? If I put this visual in there, does it support and help the story or is it just, I think you use the word chart vomit. Is it overloading it? Has it got no value because the story's strong enough on its own? Is that how we should think about it? We should write the story, add some visuals, and then pretty much remove them and see whether the story's any weaker. And if it's not, don't add it. If it looks weaker, then leave it in there. But natural data people, visualization people, is fill that space because somebody might want it.

It's an interesting one because I've seen it approached at different angles. So I do think you do need to have a whole lot of chart vomit. So those discovery visuals or even inform visuals as part of a dashboard, you need to have those first because you need to use them to actually pull those story building blocks out. So you do start with a whole lot, gather or curate the information that you need to tell your particular story. And so I always start with writing my story down first before designing any visuals. So you might use visuals as part of helping you find your message. Then you write your story down, get really clear on that message, and only add your visuals if it helps you to tell your story. So you shouldn't be designing these educate visuals unless they're actually making it easy for your audience to understand your story. So if your story can exist without any sort of data visual, you don't have to create a data visual to tell it.

And the key there is take the visual away and see whether the story is still understandable.

Or don't design the visual unless you need it.

At the moment. We can't automate that narrative, can we? Yes, in theory we could use ChatGPT to write some stuff, but actually that narrative requires a human who do understand a whole lot of things to use that cognitive thinking. They need to be able to apply that narrative with a context at a point in time. So that narrative will probably change in a month's time or two months time if I'm looking at that data, that information again because the organization's moved on or the context has changed. Data storytelling really isn't about automation at the moment, is it? It's really about that human Doing that hard work to tell that story?

Yeah, absolutely, at the moment. So I think to put together a good data story, you need to have an understanding of your business goal. What are you trying to achieve? You need to have an understanding of who it is that you're communicating with. So who is in your audience, what's going to motivate them? It is a very manual human process in terms of pulling out the right information from a whole lot of analysis. So pulling out or curating that information to a point where you're putting it into the story framework, which I think that part could be automated in the future. We're not there yet. I've played around with Jackie Chat and we're not nowhere near there yet, but that's the room that could be automated. But then there's so much more in terms of business acumen that you need to understand to be able to create a data story that's going to have some sort of business impact. And at the end of the day, that's what it's all about. Your storytelling is there too create business impact. Because if it doesn't, what's the point? What's the point of everything that's gone before it if it's not creating that change?

I think about that automation, that AI, and I'm using air quotes here. I've come up now with three buckets that I think about. So I talk about Ask AI, assisted AI and automated AI. And in my head is Ask AI is when we're using something typically in LLM, but we're having a conversation, the humans asking a question, getting a response, asking the question, getting a response, then they'll go do an action. And that process is meant to help with that action. Assisted AI for me is when you're doing something, the machine's watching and it's coming back and it's making a recommendation. So you're playing with some data and it might come back and say, look, I think the unique key of that data is this. You got to go and check it. Because I can't prove it, as I'm not 100% sure, but that's my hint. And so that hint shortcuts some of the work that we're doing. And automated AI is where it just does the work for us. We don't even know we're not involved. There's no human involved. The machine just does it. And for me, I'm intrigued about this idea of using Ask AI in the storytelling space. Whereas I think once you've written your story, you could put it into an LLM and use it as a test. Say, what's the story telling you? What action should I take? What outcome would I achieve? So you could use it as a feedback loop. Have you seen that? Where once you've crafted that story, you're really using the LLMs as a way of refining the language, confirming the story you think you're telling is the story that people will probably see.

That's just using it essentially for writing, isn't it? You can give the LLM an idea of, hey, I'm writing for this particular audience group. Does the story resonate, do you think, with that particular group in terms of their challenges? And I do find the whole ask AI thing works quite well if you're trying to understand a certain audience group that you don't necessarily know too much about. I think that it can be where it sheds some real light. You do have an audience group that you need to communicate with and you're not necessarily sure of everything that could motivate them. Using things like ChatGPT to help have more of an understanding in that space. It does work really well. But in terms of the narrative, yes, it can help with the writing, but if you understand that narrative structure already, you're halfway there in terms of how you can structure that narrative yourself. Yes, it might tweak it, it might be a bit Grammarly and just point out all the areas that you're doing wrong. But it's not quite there yet. In terms of, hey, have you chucked in this data? Create a story from it. It's not there yet. I'm not saying it's not going to get there, because I think it will, but not yet.

And so that ABT is quite a simple framework until you try and do it. And then you realize that often you're not putting the right things in the A's or the B's or the T's. Right. It seems simple. And then you go and try and do it and you realize, actually it takes a bit of learning. So what's the anti patterns? What are the. The A that you've seen where people naturally fall into things and you look at it and you go, that's not a great abt. You might want to think about tweaking this thing. Have you got some anti patterns that you've seen with all the teams that you've taught and worked with?

Generally, it's that when people present the story, they forget the key word and the key word in the structure is the word. But so this is the word that will make people pay attention. And it doesn't have to be the word but. So synonyms for the word but include however despite. Yet these are all high contrast words. And when you say these, it does make people wake up. But when people present, they lose that word and all their information just carries on and flows through and we end up with this and. And that's the death of that communication. People just get a little bit bored because they just have hearing stat after stat in some cases. And including too much data is another way to bore your audience. But it's this death by and that doesn't go down well.

But see, we love big buts. And that's the thing that when you watch people do it, you're right that as soon as we use the word but there's something in the English language that we change our tone, we change our emphasis. We know we're being. It's not aggressive. We're bringing something in that is a word that people don't tend to like because but is normally a negative. I agree with you, but that's a really great idea. But I don't agree with you. I'm just bullshitting and saying I'm agreeing with you. And now my butt's going to come and tell you what the real answer is. As I think about it, the blah blah before your tone doesn't change as soon as you bring in that big but there's a natural intonation change. It becomes interesting. I'm listening for that now because I'm like, hey, hold on, now you're going to argue with me.

You're changing the direction of the narrative. And is a very common agreement word. All the and statements agree. And as soon as you say that contrast word, however, despite whatever it is, but you are changing that direction of the narrative. And so your audience think, okay, now we're in for something new. So it's not necessarily a negative, but it's just, it's a new direction. And so if people are getting bored with all these agreement statements, they wake up in terms of, oh, now we're. Now I'm going to see something different.

In terms of career changes. I always cracked up when I was at school and I did stats 101 at school, university or something like that. And I hated it. I was crap at it. And I've learned over the years that things that I don't enjoy, I'm not good at. And then of course I went to work for a company that sold statistical software and I was like, oh, My God, I hate stats. And then as I started coaching teams, I found a lot of patterns are based around language. So seven W's and the idea of nouns and verbs. And again, I wasn't particularly good at language either. I wonder what I was good at. So now I've got to understand all the stat stuff that I've never liked. And then as I do more and more data work, I've got to understand this language stuff. So I'm really intrigued that we work in this world of data and information, but often a lot of the patterns we use are bound to language. I find that kind of intriguing because.

All these people that work in data, so you have some really technical roles, but for those people to communicate what they do, have to distill it down and have to lose a lot of that technical jargon in order for other people to understand what it is that they're trying to achieve. And so if those technical people don't know how to distill down their roles and what they found in those roles to include less of that jargon, they're not going to be able to create the impact that maybe they want to.

And we often say the stakeholders don't understand what they want. They don't know what they want. But what I'd do is flip it around and say we don't help them, we don't understand what they want. It's not their problem. They understand it really well. They use a language we don't understand and we don't do the work to bridge that gap. And we should. That's our job.

Yeah. And it does go both ways. And so there is the whole data literacy or data fluency argument in terms of we need to upskill people outside data teams with their data literacy. But actually maybe we don't. Maybe we just need to get better at communicating technical information in a way that doesn't involve all of that jargon.

We become the babelfish. Right. Because that's our job, is to take this knowledge and this three letter acronyms that we love to do and then be fluent in speaking a different language because we're the ones that can do that. Translation. Why do we force everybody else to do it for us? Think about patterns of tools, slicey, dicey analysis tools, notebooky things are around discovery, the tools we use for ourselves to discover and understand that data. And then dashboardy KPI thing forum form in that educate space. There was a big wave of infographics a few years ago. Do you think infographics was a previous generation of data storytelling where we still focused on the visualization and not the narrative? Or do you think it's still got a place in the world in data storytelling? Do you think the next generation after ChatGPT is going to be infographics again? Where do you think that infographics style of communication fits into data storytelling?

Graphics haven't gone away. Infographics is just a form of design really. But you're presenting numbers. I think infographics got a really bad name because it was just about prettying up information, prettying up numbers, making them big, making them colorful and not necessarily making them meaningful. And so I think infographics are a great way to tell data stories. But in the past the actual data story has been missing. And so it's almost been we're just going to put some numbers on a page, we're going to make them really beautifully designed and so therefore they become initially quite engaging. But there really is no more explanation around what those numbers mean to whoever it is looking at them. If you take a data story and you present it in a very infographic way, it can be really effective. I just think it's had a bad name, so I don't think it's necessarily gone anywhere. But I think we are questioning what and how we present using it.

I'm a great fan of taking patterns out of other domains and applying them in data. And most times the patterns come out of agile or products because they're the kind of most adjacent that have value for us. Think about again, when I was a kid and I used to love to read and so I used to read a lot of books, but every now and again I wanted a break. And when I did that I'd read cartoons, so I'd read comic books. So I remember the. Was it 20,000 leagues under the Sea? I had the book and I had the comic book version. Do you think that actually that's where we'll end up? That this data storytelling, because it's got a structure, beginning, middle, end and about, therefore it's a combination of visuals and words and both provide value in that comic strip? Do you think maybe that's where we'll end up is that data storytelling will become a blend that almost looks like a comic book?

I think it'll be a niche if it does. So comic storytelling people don't have the time to do that within a business necessarily. And a lot of the time, data storytelling people don't have the time to put a lot of effort into the way that they present and Visualize the information. And I think if they can instead put the effort into figuring out the data story, it doesn't necessarily matter what those visuals look like. If your data story is clear, you're clear on your message. That's going to create more impact than having beautiful visuals with no clear story. Yeah, it's great if you've got time and resources to put into creating these amazing visuals to go with your data story. But I think if you had to choose one, it would be the story. Focus on the story first. And if your visuals don't quite live up to this beautiful comic designed expectation, that's okay because you're still going to be able to communicate a clear data story, a clear message, and that's what's going to create the impact.

So it comes back to the narrative again. If we can't explain that story, that narrative, for all that expensive work we just done, then we get the meh. Oh, that's nice. Oh, that's interesting. Yeah. And then they go and do something else. So we spend people's time and we haven't actually changed anything. We haven't changed the core business process. We haven't changed anything in our organization. We haven't provided any value, we've just provided expense.

You hide that in visuals. So visuals are easy. In some cases they're easier than maybe figuring out what that story is. And so you can have beautiful, expensive visuals produced by expensive software that don't necessarily add the value that you need them to, but you can buy them.

We don't have to understand what that outcome is, what the therefore is. We just need the ands and butts are always interesting. I can go, I can find an outlier and go, oh, but because it's told me it's an outlier, but there's no close to it. It's like, who cares? Who cares that we're in that segment of customers? Who cares? I don't give a shit. I'm not going to do anything about it. There's no value in me knowing that. But it was interesting. Thank you very much. Now how much that cost?

And this is the skill of being a good data storyteller. You do need to have that understanding of business operations and how what it is you're communicating is actually going to change things. And this is why people who can become data storytellers don't necessarily have to have gone through those technical roles. Somebody who has a really good understanding of the business and can work with the people that have generated that analysis and found those Insights can be a really good data storyteller because of their background.

Okay, so we still see that skill being near the end of the value stream with people who are skilled in doing that work. But again, I go back to if the team understands that structure, if they understand how to tell those stories, they're going to naturally surface the interesting stories, the valuable stories to that person that's doing the final presentation, that final glossy piece of work on that narrative. So again, it should be a shared language across the team, not just one data storytelling person sitting in the team as the expert and everybody else having no clue on what the hell they do and how they do it.

Yeah, it is a hard one though, because I have been in both boats and when you are doing the analysis and you're really deep in the data, there's so many different stories you can pull out. And sometimes it's really hard when you're that deep in the detail to lift yourself up and be like, okay, I just need to focus on one, one narrative and tell it effectively. But when you've got all of these different data metrics and there's all these different directions you can go, that can be a really hard process to go through.

But if we talk about experimentation, it is a simple structure and, but therefore, this is a bunch of words. There's nothing stopping the people that are doing that analysis, doing their exploration, just writing a shit ton of them really roughly, not in the way that they can actually be used at the end. They still need to be polished. But. Oh, that's interesting. And, but therefore. Oh, that's interesting. And, and, but therefore you just, you're drafting a simple bunch of sentences. You now have this, wasn't it not chart vomit, story vomit. But again, what you're doing is you're distilling that insight at the time you're doing it. It's a low cost pattern. There's not a lot of effort to do that. And there is potentially value for that. When you start refining those narratives at the end of the process, pick the ones that have the most value. You wouldn't want to over Baker. You wouldn't want to spend too much time and slow you down. But, but I don't see it as an onerous pattern to continuously do that as you work.

You can approach it that way. I have more success if I provide a bit of guidance in my workshop. So I have a canvas that has informational building blocks. And so if you go through and fill out this canvas, you end up with all these building blocks of Information that you can then rearrange into the structure. So it's this in between what you're talking about in terms of, hey, we're doing this now and trying to write abts as we go. It's just providing that little bit of just gather the right building blocks, the information you need for your story, and then arrange it. Because then you're not having to arrange your whole analysis. You're just arranging certain building blocks. And I find that works better than flying blind, almost.

So it's almost like Lego blocks. You're putting a bunch of andans into boxes, and you're putting a bunch of buts, and you're putting a bunch of therefores, and then. And you're effectively collecting that easily as you go. And then you're crafting the narratives that you want using those Lego blocks in the future.

Yeah, they're not necessarily narrative building blocks. They're just information. So one of the building blocks is we're talking about data stories. Data stories. There's two types. And so one data story, you focus on a changing character. So you could have a data metric. Let's say go back to the customer number example, and you're looking at customer numbers across two different time points. So you're using time as a contrast. And then the other data story is about using character as a contrast. So we use the same data metric, customer numbers, and we're looking at customer numbers for our business versus our competitors. We're using different characters to contrast that particular data metric. And so storytelling is about contrast. And so having an idea of what kind of story, whether it's a time data story or whether it's a character data story you're trying to tell will help you to start with. So those two different stories mean that you're collecting different building blocks. One of the building blocks could be about what is the reason for the change in this metric over time. So why have our customer numbers decreased? Collecting that particular building block of information means that you could put that reason building block. You could have it as the but statement. You could have it as the and statement or the therefore statement. Where you put that depends on how you craft that story. So starting with certain information, and then it's up to you how you put it into that abt.

In terms of the way we model a business, we talk about three things. Concepts, details, and events. So concepts are things we want to count, things we want to manage, things we can see in an organization. So customer, product, order, payment, employee, store details, things that describe it. So you Know customer name, customer date of birth, product, sku, product value, order value, order, quantity, order date, those kinds of things. Things and events are. Who does what things? We can see happen in organizational core business process. So we can see a customer order product, we can see them pay for the order, we can see somebody ship the product or the order, those kind of things. And so if I think about the abt, if I think about those building blocks, I hadn't thought about it that way. So what we can say is, well, one of the core concepts we're talking about in our story is our customers. What other concepts can we bring in to give us that. What would you call it, that step change? Oh, we want to talk about location, store, or we want to talk about organizations, competitors, or are we talking about, like you said, that change over time? Is that where the story lives? That's about the event? How are those events changing over time? Are we getting more orders, we're getting less orders, or is it a detail about one of those concepts? We're really focused on margin or revenue or profit or lifetime value. That's the core of the story. That's the thing that's driving that story. I hadn't thought about it that way. That we can actually bind that, that business model to that story and then start playing with it and going, if I bring in a new concept, does it change the story? Does it enhance it or do it like visual on the page? If I bring in a new concept, does it make the story stronger or does it just make it messier and noisier and just take it off? Because I don't need that. I can get to the therefore without introducing that concept or that detail or that change in event. Yeah, I'm going to have to think about that one a bit more because I hadn't thought about that mapping of language, but that kind of intrigues me.

Yeah. And it is interesting with the canvas. I found it works really well because one canvas equals one story. And so a lot of the time when people tell data stories is the mistake they make is trying to tell too many at once. And so they're trying to put in, as you say, all of this information, and it just gets really confusing to whoever's listening. So what I find with data analytics projects is there'll be a whole lot of stories that will come out of this. And I start with the canvas and I'll have multiple canvases going at once because each canvas is one story. And then it's up to the person, the data, storyteller to choose what canvas to carry on and develop into a story. And so you might have some canvases that are going to resonate with different audiences better. And so therefore you choose the canvas that is most appropriate for you to then develop into that narrative structure and perhaps present in a visual way. But the canvas is the starting point.

Yeah, it'll be the same as information, product, canvas in that way I talk about it is we can have a canvas that is a really big product. Product lifetime value is one I always use as an example. That's massive. The amount of work we got to do to get lifetime value calculated from scratch is horrendous. But there are sub products that we can do, there are smaller products we can deliver to build up that Lego block of lifetime value. And each one of those have value. Demand forecasting has value. Revenue attribution has value. Cost to serve has value. And in terms of that storytelling, I'm assuming we can do the same. We can start with a very large story and then based on the therefore, our stakeholders can say to us, okay, now we want to focus on this. We want a smaller story. We want you to do some more work. Break it down into something smaller with a more targeted therefore. Is that how you think about it? Big data stories can get broken down into smaller data storings over time as we reduce uncertainty, as we get more guidance on where the value of that story is.

Yeah, so it doesn't have to be over time. So you can start. I always start high level. Start with a high level story and then if you feel your audience need more detail on any aspect of that story, then you flesh it out. So these are what we call nested narratives or stories within stories. And so you can end up taking a particular statement from a story and then building another story around that statement, which is a detail or level below it. And that's how you flesh out and add detail to these, to this really simple ABT framework. Because it is simple, it is very high level. But you can flesh it out, you can use it to add more detail, but you should only add detail when it's necessary. And you should never start with the detail and try and work your way up, because that's really difficult to do.

Okay, so don't start with a hypothesis and try and reverse engineer it into the story.

It's just, it's hard to go from detail to high level to summary. It's easier to go summary level down.

But on that hypothesis one, do you ever see that where somebody's effectively written the Data story, without doing any of the data work, that's the hypothesis. And then they get told, okay, go see if this is true or not. Is that a valid approach?

I don't think so. I think you're in danger of your story leading your analysis and it shouldn't work that way. You should do the analysis first. I mean, you can always have questions that you want your analysis to help you answer. That's fine a bit like, as you say, having a hypothesis, but to have a story and be led by that story and then look at the data through the lens of that, that story and you're essentially, you are cherry picking your information when you get to that point.

Yeah, because sometimes the hero has to die. Game of Thrones, you can't have happy endings in all your stories. So if that's what the data is telling you. Right. The data is telling you that there's nothing you can do about it. That's the story that has value.

Yeah, absolutely.

And so I can imagine that this is a skill that you get better at with more practice because it is a language, it is fairly simple. But then the devil's in the detail, the devil's in refining that skill. And just like I see teams have value with book clubs where they look at a bunch of patterns together and discuss, read about them and then discuss them. I can almost imagine a data storytelling club in an organization could have value where there's a closed circle of people you trust, there's kind of chathouse rules or trust charter. And what you're doing is you're practicing, presenting your narrative with the sole goal of getting feedback to refine your narrative telling skills, to get better at crafting that narrative in a clearer way, getting better at removing three of the pictures and just leaving the words. Have you seen that? Have you seen that ability of learning by practicing is valuable?

Yes, absolutely. And it is something that I do recommend to teams that they do, even if it's. If you have a fortnightly or monthly team meeting and you have a couple of people that bring along a data story to share and you don't have to prepare slides, all you have to do, it's three or four sentences using that framework that you just stand up and present, it'll take you less than a minute to present it. But it is getting into that practice of seeing the world through this narrative lens. And you're right, the more you do it, the more you're able to recognise it. I do encourage people to watch the news because people that present the news These journalists, they use this narrative structure all the time and you start to pick up on its use. And when you can recognize it being used in the world around you, it becomes easier for you to apply it because you've built up this narrative intuition and you just start seeing the world differently.

I remember when I was doing pre sales in a previous life, we used to go and do a training where we used to get taught and presentation and effectively it was a form of storytelling, but using the software and one of the brutal techniques. It was very good. But man, it was brutal, was we always got given a so what sign. So you're sitting in a room with your peers, you have to present demos or presentations that were articulating some business value for the software. Everybody had a so what sign. So when you started to waffle, the whole room would go up and hold up their so what sign.

Oh, that's brutal.

It was good, but it was a trusted environment. And I got to say, you learn quickly when you were waffling. I remember you saying once that what people often do, especially data people, is they focus their data storytelling around what they've done. The process of use the models they've run, the things they've done to that data to get the answer, not the answer. And again, I can think that data storytelling club, where there's a polite but brutal way where it's that's about you, not about them or something, there's some kind of immediate feedback to help you understand. Nobody really cares whether you've done a group bio or a linear regression or a net neural model. They just care what the actual value to the organization is. If they do that action again, that trusted environment where you can get feedback and practice and unlearn some of those aiming patterns that we naturally fall into, would be interesting.

Yeah. You've just got to be careful, I think, who you do that in front of, because sometimes when you're presenting to your peers, if your peers are technical, then they're interested in how you got to what you found. So you really do want to practise in front of people that aren't necessarily data people or technical people, and see if you can communicate in a way that they understand. Because that's the audience, the general audience in a business context that you probably want to influence.

Good point. But then you're going to find that trusted environment where, like we say, you shouldn't have your boss sitting in a retrospective with a team because they'll influence what the team talks about. The team will try and make Themselves look good. Yeah. Maybe that trusted circle is you need somebody that that comes from that business background and understands their outcome and that value, but isn't in a place where you worry about looking good to them because you're naturally learning. That would be an interesting trust circle to try and form. Excellent. Okay. I think for me data storage is really valuable. I think it's something that we should be doing. It's something we should bring into our skills. But it's a hard skill to learn. It seems simple, but I think practice is something that you need to do with it and therefore once you've done it a lot, you're going to provide more value to your organization. Anything else we need to know from a data storytelling point of view? Anything else? If the team was starting off, you got a book coming out and we'll talk about that in a second. What's the best way for a team to start off on their abt on their data storytelling journey?

I think it is just to learn those basics. And when everybody in the team is talking the same language who understands the methodology, you're at least all on the same level and can communicate in terms of hey, this is what, what the process involves. I'm this part of the process or I'm trying to do my narrative, I'm trying to create my abt. Can you help me with this? People understand what it involves. A lot of the time when you're new to the field, you don't necessarily even understand the difference between data storytelling and data visualization and the fact that they are two different things. And so having this shared knowledge, these defined areas of this is what it involves. That's a good starting point. Point.

So find the patterns, understand the patterns, learn the patterns, practice the patterns, then focus on the anti patterns, focus on the things that you know, you naturally start to do that don't align with with the pattern itself. And for me, chart vomit's one I naturally go to. Oh, there's a white space. I can put another graph there because somebody might need. Doesn't add any value, it just adds noise. But it looks semi pretty. So for me that's one of the anti patterns that I need to unlearn. Excellent.

All right.

And. And the books out. So you've been coaching and teaching this for quite a while now. You've done that hard work that hard mahi to finally write it all up into a gorgeous looking book. Where can people find it? Where can they find you?

It's for sale on Amazon and you can find out more about me through my website, RoguePenguin Co NZ it's super exciting. This is my first book and I have just left nothing out. Everything about my process and what I've learned through the seven years that I've been full time doing this in this data storytelling space and teaching this and everything I've learned from that is included in this book. And I'm really just so excited for it to be out in the wild. It's been a long time coming.

Yeah. Not as long as mine. Yeah. So anybody who doesn't know, we had a bit of a competition. So I find that if I don't have competition, I tend not to do things. If for me, it's. If I don't have competition or I don't have homework, it's not due on a certain date, I never quite get around to it. We had a bit of a competition. I definitely lost. So congratulations to you for winning.

I think the competition was all in your head, because it wasn't real.

If I had won then, yeah, that would have been. That would have been good. But I'm nowhere near finished. I can understand how hard it is to write these bloody things. So congratulations on getting it out the door and no doubt it'll be of beautiful quality and visually stunning and tell a great story. And on that. How did you come up with Rogue Penguin? I'm sure I even asked in terms of company name, where'd that come from?

Yeah, I get asked this a lot, actually, when I was trying to come up with a company name. I didn't want to be boring, I didn't want to fit in with everybody else. And a lot of company names at the time, they all had data in them and they were all quite technical sounding. And so I was doing some name brainstorming and rogue was just one of the random words that popped out of the brainstorming and it was a word that resonated because I did want to do things differently. I didn't want to do what was always been done and repeat the same thing and end up in the same place as everybody else. I did want to go away from the norm and so I loved how that word spoke to me. And Penguin. Penguin was actually the name of my daughter's favorite book at the time. She was five and she had this favorite book called Penguin and we used to read it every night. So it was just stuck in my head. So Rogue Penguin came about.

There you go. That's another one that stands out. There's a good AB sitting behind how you created the story of the company as well, which is good. Excellent. All right, everybody go to Amazon, buy.

The book Data Stories Handbook. Just I don't even think we said the name.

I don't know how many other data story books there are out there. I've never bothered to look.

There are a couple. There are lots of data visualization books out there. This is not a data visualization book. It is a data storytelling book.

Excellent people. Go buy the book, see what you think, give some reviews, give some feedback, and then I've used the technique myself a lot more than I expected after being lucky enough to sit through one of Kat's courses. I find it a valuable pattern in many different ways and like I said, a lot of them unexpected. Definitely a skill to have in your talk. It excellent. On that note, I hope everybody has a simply magical day.

Data Magicians was another agile data podcast. If you'd like to learn more on applying an agile way of working to your data and analytics, head over to agiledata. I.