You have a lot on your plate!
As a data scientist you are expected to be both deeply technical but also business savvy. Most data scientists lack the business side, but there is a way to address that. This article will cover a process that acts as a proxy for years of business and consulting experience.
But first, let’s look at what is expected from the typical data scientist, whether explicitly or implicitly.
Build Complex Models
First and foremost, you were hired to build models. Models that can take in data and do something valuable with it that will change the course of your company for the better. If you can’t do this then you’re out of luck!
Create Business Value
This tends to be more of an implicit expectation. Suffice to say, if a colleague is producing business value, and you are not, guess which one gets the promotion? Oh, it’s not on your job description? You can bet senior management thinks it is.
Here’s a tough one. How do you get people to act on your data insights? Who owns making sure it happens? Your plate is already full but you have got to own this. Fear not, there is a process to follow, a step by step guide to make people act on your work.
As tools and methodologies evolve, you too are expected to evolve with them. Sure, there is the usual knowledge of R, Python, etc. but a technological nimbleness is becoming more of a requirement. Pretty fundamental to the role.
There’s a process for that
We’ll assume you have the model and technology parts covered, sort of basic requirements for the role. The data scientists that get promoted the fastest are those that have greater impact with the models that they build.
That doesn’t necessarily mean the models are bad if they are not successful, not at all. You can still have done phenomonal work and no one cares. The problem is how users interface with your model, i.e. the user interface. While there are obviously many ways for people to interact with you models, dashboards are one of the more popular ones. We’ll focus on dashboards for the purposes of illustrating an example.
It sucks that you have to care about that, what with all the other stuff you have to do. But this is the fork in the road that leads you to bright lights and an enriching future or the one that steadily sinks into the darkness of mediocraty and a vacuum of inspiration.
You’ll be stretched a bit by this process, much of it will be new, such as talking to people 😉 I jest, but a lot of the value to the process is opening the lines of communication between the various parties. Take a bit of time to read through the process and we’ll do a deeper dive following it. Keep in mind that the dashboard is the portal to your work.
Bridging users and business stakeholders
You’ll notice that the process beings with people and talking to them. There are two distinct groups being represented:
- Users: the people who end up opening your dashboard on a regular basis and taking action based on what they see.
- Stakeholders: anyone with an interest in the model and resultant dashboard. That can include your boss, senior management, IT, etc.
The reason for this is that these two groups are the biggest causes of analytics failure. So we need to bring them together, in a metaphorical sense. They need to be aligned. We do that and we get to profit.
Creating a visual requirements document
The biggest challenge is communication. People don’t speak the same language. Data scientists have a technical dictionary and executives have a business dictionary. There needs to be a mediating and averaging factor that both ends of the spectrum can understand.
Enter the wireframe. A greatly under-utilized tool from the UX world. A wireframe presents the outcomes of the model. “If it looks like this then we are good”. However, to make this work, there are a few vital ingredients:
- 1: A simple dashboard layout: learn more about it in EnterpriseDashboard Layout – Keeping It Simple
- 2: Storytelling
- 3: Each chart answers a question
- 4: Ideally there is an action associated with each chart
I codified this into a set of templates making sure to keep the technology abstracted and a focus on business value. Here is an example of what that can look like.
Wrapping it up
Per the process, once you have completed the wireframe it becomes the visual requirements document. You use this for getting feedback and interating on BEFORE starting any work on your model.
If you get there you are already doing great, but there’s much left to do. However, for most data scientists, this is plenty far and will be a great improvement. For large projects, there will be more people involved and assinging people to other parts of the process will be an option. So you don’t have to take it all on but it is recommended you get familiar with the remainder of the process.
Thank you for reading and please share with other data scientists so we can help our introverted friends 🙂