Data Storytelling with Kat Greenbrook - AgileData #48

Welcome to the Agile Data Podcast, where we talk about the merging of agile and data ways of working in a simple, 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, realizing I didn't want to do that, switching to science. I got a degree in science, majored in genetics and biochemistry. Before realizing 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 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 their 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 markets. 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 I 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 8 or 9 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 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 7 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 learnt 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 learnt 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 start 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 airy fairy, arty, wordy, drawing, picturey side of the world, right? 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 creatively 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 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, munge the data, wrangle the data, beat that data into, to 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, does the majority of them come from a Visi 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, 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, every person in our team, every part of that information value stream can be enhanced if we are telling stories with the data that we're working with. So it's not just at that last mile, it's not just the 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 are 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. But 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 storytelling 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 a 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 because the companies have hired too many people and it wasn't sustainable. But often data teams are seen as being in cupboards, is the way I describe it. So the team work in isolation, they take a set of requirements, they then work in their cupboard, they 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 are 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 tell stories, probably are the 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 organization.

Yeah, it's funny you say that, though, 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, so pulling out the message of data and figuring out what that is and how to frame it, and then telling that data story. And so telling it involves presenting sometimes. And yes, you're— 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 prerequisite.

Okay, you got to do debating then. No. Okay, so, uh, one of the teams I was coaching, uh, 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's 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 and, but, therefore, ABT narrative structure, and it's based on the 3-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 plot line of a movie in those 3 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, or 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 3 acts to create that story structure.

The reason I love it is it kind of, 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. And 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 you, 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 of if we do that? And the 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 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 work.

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 3 words, How we arrange the information that we want to communicate around those 3 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 better.

There must be an 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 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 are 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 an example 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 unsupervised, 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? Or 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 do we, 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 and 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, 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, inform, and educate comes from data visualization. So these are the 3 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 are 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 measurements. In my view, dat— data storytelling tools. They are there as more of an operational, 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 that 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, our notebooky, our us, 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 are 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 are doing our dashboards, our charts, our reports, that kind of stuff. So somebody else can self-serve. Without us because the data's immutable, right? 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, right? And then, educate's narrative, that's words. Now, we may augment the words with 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. 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-pattern. 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 used 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 of 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's 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 2 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 are 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 and 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 ChatGPT 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 to 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?

When I think about that automation, that AI, and I'm using air quotes here, I've come up now with 3 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 human's asking a question, getting a response, asking a 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 are playing with some data and it might come back and say, look, I think the unique key of that data is this. You, you gotta go and check it cause I can't prove it is. 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.

And 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 can be where it sheds some real light. If 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 As or the Bs or the Ts, 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 As 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?

So generally, It's that when people present the story, they forget the keyword. And the keyword 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're just 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 but's going to come and tell you what the real answer 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 7Ws and the idea of nouns and verbs. And again, I wasn't particularly good at language either. I wonder what I was good at. But, well, 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, you know, 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've 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 goes, 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 babble fish, 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 are the ones that can do that translation. Why do we force everybody else to do it for us? So you 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, KPIy, the thingy for inform. 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? World in data storytelling? Do you think the next generation after ChatGPT is going to be infographics again? Where do you think that infographic style of communication fits into data storytelling?

Infographics 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, 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 and we're going to make them really beautifully designed. And so therefore they become initially quite engaging, but there really is no, no more explanation around what those numbers mean to whoever is looking at them. If you take a data story and you present it in a very infographic-y way, it can be really effective. I just think it's had a, 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 product 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 the state of storytelling, because it's got a structure, beginning, middle, end, and, but, 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. Yes, 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've 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 spent 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 Buts are always interesting. I can go and 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 have 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 did that cost me?

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. 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 are 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, it's just 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 a 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're just, you're drafting a simple bunch of sentences. You now have this, what is 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 overbake it. You wouldn't want to spend too much time and slow you down, 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 analysis 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 and-ands into boxes and you're putting a bunch of buts and you're putting a bunch of therefore's and then 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 the 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 if 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 3 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. And events are the who does what, things we can see happen in an organizational core business process. So we can see a customer order product, we can see them pay 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, that, what would you call it, that, 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? We're 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 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 does it light vision 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 gonna 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. And 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 the information product canvas in that, like I talk about it as we can have a canvas that is a really big product. Lifetime value is one I always use as an example. It'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's 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 stories 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, you know, 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. 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 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 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, these kind of Chatham House 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 3 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 it— you don't have to prepare slides. All you have to do, it's 3 or 4 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 recognize 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 presentations 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 trust trusted environment. And I've got to say, you learned 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 they've used, 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 a biolinear regression or a 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 thinking patterns that we naturally fall into would be interesting.

Yeah, you 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 practice 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've got 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 their 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 story 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 gonna provide more value to your organization. But 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 why 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.

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 vomits, what I naturally go to. Oh, there's a white space. I can put another graph there because somebody might need it. Uh, it doesn't add any value. It just adds noise, but it looks semi-pretty. Uh, so for me, that's one of the anti-patterns that I need to unlearn. Excellent. All right. And, uh, and the book's out. So, you've been coaching and teaching this for quite a while now. You've done that, that hard, 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 7 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 a competition, I tend not to do things. For me, it's if I don't have competition or I don't have homework that'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 not sure I ever 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 the 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 being 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 5 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 ABC thing behind how you created the story of the company as well, which is good. Excellent. All right, everybody go to Amazon, buy the book.

The 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.

Book? There, 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 toolkit. 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.com. Aya.