You’re in the board room, slides at the ready as you begin to recite your well-rehearsed run-through of the numbers to the lead team.
Your charts are impeccable - you are, after all, well-versed in the kinds of data storytelling techniques taught by Cole Nussbaumer-Knaflic, Stephanie Evergreen, and Kat Greenbrook. You’ve checked the data more times than you care to remember, so you know you won’t trip up over any of the detail.
You begin to narrate the situation for the audience, when you start to notice something strange.
People are frowning.
Did you get ketchup on your collar during lunch? No, that can’t be it - you checked yourself in the mirror before you came into the room.
Maybe they can’t hear you at the back? That’s not it either - even the CFO, who’s sitting right next to you, is wearing a scowl on her face.
You pause halfway through your presentation, and make a strategic decision.
“Any questions at this point?” you ask.
The CFO nods.
“Yes”, she says. “Shouldn’t we be looking at last year’s numbers?”
And then you realise the problem: you’re telling the wrong story.
As A… I Want… So That…
If your audience isn’t seeing what they expected, then they’re probably going to tell you about it. But here’s the thing: if you wait until the big presentation before you find this out, then you’ve waited way too long.
I’m giving a talk at posit::conf(2024) in a few weeks, where I’ll be talking about the three components that underpin a mature data culture. One of those components in proficiency, which I define as delivering quality at pace, but I point out that being proficient isn’t sufficient.
My story above is an example of why: you might be extremely proficient at data storytelling, but if you’re telling the wrong story then what’s the point?
Understanding the needs of your intended audience is one of the very first things you’ll need to do when preparing a piece of analysis, and storytelling plays an important role here too. Before you delve into the data, you should ask yourself three key questions:
- Who is my customer or intended audience?
- What do they want?
- Why do they want it?
If you have any familiarity with agile methodologies, then you’ll recognise these questions form the basis of a typical user story.
Unlike your presentation in the board room, you’re not telling a data story here. The clue’s in the name: you’re telling the user’s story. Writing a good user story lowers the risk of producing wasteful work - in other words, work with little or no value for your intended audience. But writing a good user story isn’t easy, so let’s tackle the three parts.
Who?
The first and most important question you need to answer is: who is my customer?
This might seem obvious: it’s the person who’s asked you to do the work! But a lot of the time that person is your line manager, and they might have received the request from someone else in the business. And that person approached your manager because they’re part of a project that requires some post-implementation analysis.
You get the idea: the customer can be elusive sometimes, so don’t assume it’s simply the person who approached you first.
But let’s say you’ve followed the thread and finally identified the person (or people) who will gain business value from this work you’ve been asked to do. Does that mean you know who your customer is now?
Whether you know them personally or not, you need to know a few things about this customer in relation to the work you’ll be undertaking. For example, how data literate are they? How familiar are they with business context surrounding the data you’ll be working with? Can they be expected to understand a lot of the jargon that’s familiar to your other colleagues?
There are many ways to understand your customer’s identity, from personas to empathy mapping to gemba walks, but the important thing is that you identify who they are in the fullest sense as a first step.
What?
The matter of what your customer wants can be even more elusive than their identity. This is because people often tell us they want one thing, when in fact they really want something else.
When you first write your user story, you might simply repeat the user’s request here: they want to see the quarterly financial results for the last financial year, or they want to see customer attrition for the previous quarter and so on. But you need to know the context behind this request to ensure that you’re delivering the maximum amount of value.
Understanding context comes from asking “why?”, and we’ll come back to that.
But there’s another impediment to understanding what your customer wants: they’re not usually very specific about it.
Consider, for example, a request to see customer attrition for the previous quarter. Do you and your customer have a shared understanding of what constitutes attrition? Do they mean the previous financial quarter or simply the last three months? Are they interested in all customers or just a specific segment?
You probably won’t include this level of detail in the user story itself, but having as much information upfront as possible will increase your chances of writing a more accurate user story. As with everything up to this point, it involves asking the right questions.
Why?
Last but not least, it’s crucial that you understand the reason behind this request in the first place. Sometimes, the customer hasn’t thought this through themselves so you’ll need to work it through with them.
Asking why can seem confronting to some, so be tactful about it. You want to maximise the value you’re delivering and eliminate any wasteful work, so reassure them it’s not simply a stalling tactic or a way of questioning the legitimacy of the request - although, on occasion, it turns out it’s actually not worth pursuing (or can’t be pursued in any case).
Understanding the reason behind the request can sometimes transform the nature of the request. For an analytical project, it can also shape the final product: is this a dataset, a dashboard, a presentation etc.?
Finally, don’t be afraid to revisit these conversations with the customer even after the user story has been drafted. As Alistair Cockburn, one of the co-signees of the Manifesto for Agile Software Development put it, “a user story is a promise for a conversation.”
Fundamentally, you’re writing a story from the perspective of the person (or people) who will derive value from your work. Although the user story itself is only three lines long, developing a deep understanding its three dimensions - who, what, and why - will lower the risk of telling the wrong story at the end. And everyone likes a happy ending.