A data-driven company is where decisions are based on last-minute, actionable insights as opposed to gut feelings or biases. According to Forrester Research, this new kind of company harnesses digital insights to optimize products, services, and operations and will grow 27% annually (40% for startups). Read on to get an insight on how you can build such a company from the culture and process point of view.
How do you start building a data-driven company with modern business analytics practices?
You start by nurturing your team's "data literacy". Don't get me wrong, not everyone in your organization has to become a data scientist though. Think about the human language. When we refer to language-literacy we are talking about reading, writing, and comprehension skills. That’s right, first, we have to learn how to read letters before we can read words, interpret sentences and comprehend books. But we don’t all need to have a degree in linguistics or philology or author best-selling novels for that. In business analytics, first, we learn how to read numbers in a report, then we start interpreting those numbers, and finally, we extract meaningful insights. "Data literacy" is just about that process. It is not about coding, building data pipelines or sophisticated prediction models, or sophisticated machine learning algorithms. It is the ability to read, work with, analyze and argue with data. Just like language literacy became ubiquitous, "data literacy" is evolving into an essential skill for almost every role in every organization.
Next, you encourage behavior like diving deep and understanding the underlying cause of every change in the business. Bias for action leads to the best results when individuals combine it with curiosity and deep understanding.
This will happen if the data-literate data-consumers can independently ask and answer the "Why?" questions. Meaning: there's no need for a data analyst to answer questions like Why is the performance dropping? Where is the problem? How can I dive deeper to investigate and take countermeasures?
There's a good mental model for this practice, called the 5 whys, by Sakichi Toyoda. It is a simple technique that asks you to identify the root cause of any challenge, by asking "Why?" over and over again, 5 times in a row. After surfacing a challenge, ask “why” it happened, and then continue asking “why” for each answer or explanation that was given. Consider a situation when teams are looking at the bottom of sales performances that fell below expectations. When they realize the reason is an increased customer churn, they can ask:
Why is that? The answer: customers raised many complaints. While we fixed their issues, we didn't address the root cause and that led to a bad user experience;
Why didn't we fix the root cause? The answer: product management didn't prioritize the fix of the issues on the roadmap;
Why is that? The answer: no one quantified the size of the issue, thus product management had no sense of urgency;
Why is that? The answer: product management has no access to structured, curated customer support data, so they're forced to "fly blindly".
At this point, the product managers reach the root of the problem and are well equipped to turn around the story. They can put in place a dashboard showing metrics, like Net Promoter Score, Churn Rate, Retention Rate, just to name a few. Next time, any of these metrics fell below threshold values, product managers can act immediately.
Of course, to be able to apply this technique, you need to explore the data beyond the limits of a report where the first problem was noticed. This means that all the customer support data must be accessible to the product teams. This is where data democratization comes into the picture. The team should be able to formulate and answer questions like: what's the correlation between churned customers and the number of complaints? What are the main reasons for the complaints? How many complaints are submitted grouped by topics? What is the lifetime of a topic in the sea of customer complaints? What are the top 3 complaint clusters and how many customers are affected by those? What is the correlation between a new release and customer sentiment? This means the team has to have access to data from all parts of the organization. At the very same time data privacy regulations, like HIPAA in the U.S and GDPR in Europe must also be fulfilled. You can achieve this by anonymization of "Personally Identifiable Information" (PII in short) and by establishing access control and access audit. This and data quality assurance are the focus of a data-governance practice. Hmmm, data quality assurance, you ask? Yes, that is all about making sure that statistical outliers and missing data are handled before it leads to bad reports and bad conclusions.
The shift of responsibilities during the Data-Driven Transformation
The key is to start shifting the main responsibility of your data engineering and analytics teams from report-creation to the building of a self-service data platform. Such a platform abstracts away data governance concerns (eg. data quality, data privacy) from the end-users. Using the platform, data-literate teams can focus on extracting business value from the data, without being distracted by the intricacies of data integration and resource management.
You can measure success by the reduction of "time to insight" (the time needed between the formulation of the question and the answer). The target is to go from weeks (sometimes months) to just minutes.
Thus data consumer teams, like product management, operations, customer success, sales, and marketing will be responsible for creating their insights, Remember: they should be able to ask 5 times the "Why" question before making a decision. Team members must feel comfortable formulating questions in a data language and interpreting the answers. They might establish the role of a "subject matter expert", who wears an extra hat, the one of a liaison with central data teams in case special needs emerge.
In our example from above, the Data Producer is the "customer support team", which owns the customer support data. They should offer for consumption a "curated data set", that is free of statistical error, missing or duplicated data.
They should start looking at their customer interaction data as an internal "Data Product" that contains insights of interest for other internal teams. The role of a data-product manager emerges, who manages these data sets as a product, with quality criteria and lifecycle, just like any other digital product.
New concepts, like DataOps and Data Meshes, are capturing and further evolving these ideas to new levels.
DataOps - similarly to DevOps - is focusing on automating the repetitive tasks of data processing (eg. data ingestion, integration, and cleansing). Just like DevOps changed the face of IT-Operations, DataOps will also enable new levels of efficiencies to create more insights, much faster.
Data Meshes are a decentralized practice, the next evolutionary step to scale up an insight-driven culture beyond hundreds of data sets and thousands of metrics.
Summarising the steps you need to take to put in place an insight-driven practice and culture in your organization: 1.) it all starts with "data democratization". Provide access to everything and every employee, while fulfilling the data privacy and regulatory requirements; 2.) ensure "data literacy" in all teams (marketing, sales, operations, etc.) and encourage data deep dives before bias for action kicks in; 3.) shift the responsibility of the data teams from report creation to the building and operation of a self-service data platform. This will abstract away the complexity of data governance and data integration so that data consumers can focus on insight generation; 4.) make sure that data producers start looking at their data as an internal product, that is embedded in the fabric of the business and independently consumed by external departments.