Whenever we read about success or failure in data science, the ‘last mile’ is often mentioned. And usually in the same breath as “this is when projects go to s***!”.
It’s that all-important step where you take insights obtained via analytics/machine learning and place them in the hands of the customer. You believe these insights can help them make better decisions … decisions that eventually lead to real business benefits.
Deep down, there’s a sliver of doubt. What if you’ve provided insights to a problem your customer doesn’t care enough about?
A trip down memory lane
Back in first year civil engineering, our seen-it-all-before professor would throw new students a challenge. Two towns, separated by a fast-flowing river, and we need a bridge … a toothpick bridge.
“Any kind of toothpick bridge. Truss? Cantilever? Arch? You decide …”
“Make assumptions!” he’d growl in response to the howls of protests at almost zero information. No google in those days!
The models that students brought in the following week ranged from terrible to half-decent, boring to downright wacky. The professor, with a wry half-smile, would first ask “Do you guys trust any of these designs?”.
And then he’d pull out a steel ball bearing, place it at just the right spot and sure enough, one by one everyone’s structure would collapse.
Why don’t they trust us?
From an engineer’s point of view, last-mile success is a structurally stable bridge. But civil engineering is also a mature discipline. It has well-defined processes that will get you to an output … unless things go very wrong.
Data science, for the most part, is probabilistic. Where predictions are concerned, we extract knowledge from data and then try desperately to make a more educated guess about the future.
We tend to say “Mr Customer, you’re likely to get a bridge — we just don’t know what kind and we don’t know how strong it’s going to be. But we think you should cross it because we’ve … done the work!”
To many customers, it is a black box. Magic happens but what kind of alchemy? Is it sleight of hand? No one is certain.
And the unsaid question usually is “Do we trust that black box? And the people who front it?”.
Trust and uncertainty in the problem statement
“There’s an old saying in business: if don’t ask the right questions, then how can you expect to get the right answers? For any given product or service, customer expectations, aspirations and requirements are often locked up in the customer’s mind.” ~ Forbes ~ ‘Why Business Fails To Travel The ‘Last Mile’ Of Analytics’
That question of trust goes back to the beginning. A data science-type business problem, as the customer sees it, can take many forms and evolve over multiple iterations.
What the customer usually tells you is what they think they want at a particular point in time. But if they don’t know you, they might not quite tell you enough at first… or give you the context needed to understand the nature of the problem.
So realistically, that first version of the problem you hear is unlikely to be the problem you need to solve.
See how this one morphs for example.
- Week 1: Can your system predict when hardware will fail? Okay.
- Week 3: Can your system complete its predictions in 30 minutes? Okay, but why 30 minutes?
- Week 6: How much network traffic is impacted when hardware fails? That’s a bit more work but do-able.
- Week 9: Actually, we know high network traffic causes hardware failures. Can you predict when traffic will spike enough to cause failures? Why didn’t you tell us to include traffic in the first place?
- Week 14: We already have a hardware refresh program. If we use your predictions, is it going to be cheaper? <thinking to ourselves> How the hell do we recover our costs??
Ultimately, every day we get to spend with our (internal or external) customer is one step closer to knowing what the real problem is.
Finding a way to get to that dirty underbelly as quickly and intimately as possible means the difficult task of always trying to imagine being in our customer’s shoes … and then asking questions of the supplier with the intent to feel viscerally.
- What is the supplier doing?
- Do they really understand our problem?
- Is this all working??
And this is where storyboarding, with its ability to frame questions and answers in a way that invites dialogue, can come in handy for data science.
What storyboarding means to us
A few years ago, plagued by poor communications and outcomes, data science latched on to the concept of telling stories with data.
Having seen first-hand our audiences being overwhelmed by data-driven dialogue, we had to look for alternatives. And we found the WHY of using visuals and narratives as described by Brent Dykes in his “Essential data science skills” article simply too compelling to ignore.
It’s one thing carving out time to learn a new skill but how does one find motivation? For that, we went to the film industry … possibly the true masters of visual storytelling.
So we read Studio Binder’s guide to storyboarding and then went through its repository of movie favourites in storyboard form. And in all honesty, the thought of trying to wrangle a customer’s problem on a sketchpad first was a lot more inspiring!
Of course, that still left us with how to effectively work data into a storyboard for an audience of C-levels, engineers, managers and others. Thankfully, we found Nancy Duarte and gobbled up her ideas on humanising data.
For us, storyboards have now become guideposts for the path we and our customers need to take.
Five benefits of storyboarding in data science
1. Storyboarding helps you validate that there is a problem
One of the early mistakes we made was starting our storyboarding process during data analysis. Too late … unless you’re confident you understand the problem as the customer sees it.
Now we start with the goal of making sure we can first see the problem via data, which isn’t always as easy as it sounds. But it gives us confidence that the problem is tangible.
2. Storyboarding helps you reach common problem understanding with the customer
By replaying the problem back to the customer in your words, they get to understand your process, and you get to understand theirs.
You also have the opportunity to refine the problem and the customer will likely sense that you’re genuinely trying to understand and acknowledge their pain.
3. Storyboarding shows them that you are doing something
Customers usually want to know that something is happening. A picture at a time, with a hint of progress, can do wonders.
More importantly, as they see what you’re doing, that black box becomes less of a black box.
4. Storyboarding with early financials will give you a sense of how to get to a sound business case eventually
We need to find out quickly what makes the customer tick, and preferably as far away from the finish line as possible.
Introducing cost estimates is a surefire way to get an early gauge of how bad the problem is, how much your customer cares about it and how off track you potentially are!
5. Storyboards can be tailored to reach different stakeholders
Like horses for courses, the same storyboards may not necessarily work for different tiers of audience in your customer domain. And that’s why it’s critical to use tools that allow multiple storyboards off the same underlying data.
How much energy does this all take?
Make no mistake, it is time consuming and exhausting. We’re in effect front-loading effort in the hope of more certain future gains. Clarifying the problem extensively never meant that all the other work of data cleaning, transformation, model building and machine learning application stops.
But it does give us the opportunity to self-correct before the last mile … without too much collateral damage.
And helps us build the all-important narrative and business case brick-by-brick with our customer.
So maybe leave the insights for now and uncover the black box first
“All his life has he looked away… to the future, to the horizon. Never his mind on where he was… what he was doing” — Yoda
The reality is, even if the business problem was defined adequately, any usable insight is unlikely to work if decision makers don’t believe the process of how we got there. And that usually happens if they aren’t part of the journey in the first place.
But if we participate in the customer’s version of the process, we give ourselves a chance. We might just end up spending enough time with them to allow trust and respect to naturally build up.
Of course, the quality of our work had better be decent and the numbers must work.
And then, they might just cross that bridge on your say-so …