Repositioning data - Importance of the first use case

Repositioning data in traditional organisations is not easy, however, is extremely important to thrive in a competitive environment. The days when data was used retrospectively to look at what has happened is giving way to using data to predict what is about to happen and thus, creating competitive advantage for those who understand and appreciate this, and are prepared. In my previous post, I mentioned about some of the things to consider for someone who wants to re-position the role data teams play in their organisations.

For someone who has made up their mind to embark on this journey, one of the first questions that comes up is "where to start". While there are several facets to this questions, this post deals with the "what", i.e. what do I solve for. Choosing the first use case that brings out the value of using data differently, can be extremely important in an environment where one can expect an overwhelming degree of inertia. Inertia can take several forms and will come from both outside and within the data teams. Some things I have heard or felt…

"data teams should concentrate on fixing the data issues first before embarking on lofty goals of using AI"

"our data quality is poor, so any AI on that data will be poor as well"

"we do not have a proper view of customer yet"

In my experience, any organisation that did not start off digitally and has been in business for long enough, does not have squeaky clean data, and placing this as a pre-requisite would mean one would never make the transition to something new. There is just no PERFECT state, so its good to stop worrying about being perfect with data before taking this on.

Nonetheless, choosing the first use case correctly and executing on it can play an important role towards building momentum, which is necessary to break through the barriers of traditional thinking.

Below are some options as one goes about selecting the use case..

1. Option 1: Ask business units around the company (internal customers) for problems to solve using data
2. Option 2: Ask senior management on the problems that are top of mind for them
3. Option 3: Spend time exploring and create a shortlist of problems that if solved, will create a significant commercial impact for the company

Business units do not really know which problems can be solved using data, so they will try to carve out part of a problem that they think is a data problem. It will generally be something to do with data quality or dashboards which do not work properly. It's not their fault if they come up with such problem statements, it's simply because data teams that they have worked with have only helped them with such issues. The bigger picture that data can be used to solve almost all of the problems that they are dealing with, is not immediately apparent to most. It will require time, and a set of successful initiatives, before they start discussing their most complex problems with data teams. Hence, Option 1 is not the most optimal to go with.

Option 2, which involves getting inputs from senior management can work in specific situations. Option 2 has a much higher chance of success, where data does not sit with technology or IT in the organisational structure, but sits within a commercial arm of business. Another necessary condition for Option 2 is where the director / senior management believes in the value of data, and actively promotes ideas to re-position data. If these conditions are not met, Option 2 can have negative consequences. It can create a certain amount of pressure that is not required. Pressure is not bad, as it can be a motivator for the team, however, if your in-house data team is taking up a project like this, I would believe they want to push themselves, so this additional expectation management is not the best use of time and effort at the beginning.

When I started on the journey of re-positioning data, some of the team who had an understanding of business levers, scanned the business to understand some of the core problems. In large organisations, there are a significant number of problems that can be identified through chats and informal discussions with different parts of the business. Option 3 is a thus a variant of Option 1, where you chat about problems facing business teams, without bringing data into the picture, cause most problems can be converted into data problems, where data plays a significant role in the solution. Once you are on the journey to identify use cases, create a way to evaluate if the problem is the right problem to take up. A typical evaluation will consider some of the below:

Is a probability based solution approach good for this i.e. if it’s about how much to bill a customer, a pattern based solution approach may not work

Is the problem difficult to solve using deterministic approaches i.e. if it cannot be solved easily, there is a higher traction for an acceptable solution based on patterns

Is there significant data that can be accessed easily i.e. if core data is based on survey responses, better to avoid such initiatives

There can be many other parameters that can be considered to understand if a particular problem is a good problem to solve for, e.g. ability for automation, decisions at scale etc., however, let me not get into these for the first use case.

There is also significant material online that details use cases by industry vertical that can be solved using machine learning. A prioritised shortlist of such use cases can be put together based on a combination of your understanding of your business's problems as well as your research. Then select the one that makes the most sense, and that the team feels passionate about. You may sometimes think about hedging your bets and going for multiple use cases in parallel, however, that is unlikely to work, as it will lead to less focus and an inability to iterate on a problem, which means that you are more likely to give up on the problem statement without sufficient effort. I think Option 3 is best to identify the first use case.

Once you have identified the problem to go for, and if it’s a problem others have solved, then it will be a question of time and effort before you will solve it. The key is not to fear or be disillusioned if you do not see success immediately. In fact, if you are a team attempting to use data differently, i.e. to problem solve, chances are that you would not have all the technical and problem solving skills necessary to make that happen, so it is going to be a challenge. Welcome the challenge, create your hypothesis and go about solving, pivot to a different approach if you need to. One of the most critical success factors is the team, make sure you bring the best people from your area into the team. Best people in this scenario are those who love a challenge, have independent thinking, are motivated to create something interesting, and are willing to try multiple approaches.

...

Over time, as you establish your brand within the organisation, the approach to identify use cases will change, as there will be wider acceptance of data teams as problem solvers. My journey on solving that first use case, was not an easy one as we did not have all of the right skills and approaches, but it was also one of the most enjoyable experiences as we were trying something that was new and unexplored, and doing this with a team who were individually and collectively amazing. The next post will be about the type of team one should bring in for such an initiative.

Hope you enjoyed reading!!