Driving adoption in data science solutions

Have you ever seen or participated in a project where a great tool was developed and then no one ever used it? It’s a story that is repeated time and time again: when a project is delivered and adoption is not as high as would have been desired. How is it possible if the solution works perfectly and fully meets the specifications?

Maybe because the interface looked confusing to the final users, maybe because they didn´t perceive the value that it would bring, maybe because the users didn’t feel confident about what the solution was doing in the back-end. Or maybe, it is a combination of all these, plus many other reasons.

Successful data solutions must ensure the involvement of all parties in the development phase or risk becoming “a cool demo collecting dust in a drawer”. Human-centred solutions make all parties feel involved and proud of the process, which naturally drives adoption.

This article includes some steps and thoughts about what’s needed to ensure that a tool has widespread adoption once it’s finished. And by adoption I don’t mean making the use of the tool compulsory (which could also get 100% adoption!) but adoption because the users feel involved in the creation process and see value in the solution.

The focus of the solution

First, we need to define what a good tool is. Sometimes it’s defined as a tool that works well technically: never crashing, short response time, etc. But that’s only one narrow definition of a good tool. Another one, which I prefer, could be: a good tool is one that serves the business purposes of both the company and the users.

Then the question is: how can we develop a tool that maximises the business value? The solution is to take care of the technical side of the development process as well as the human and the business side at the same time, and during all the steps of the process. As we’ll see, the trade-off when choosing whether to focus on the technical or the human/business side of the project doesn’t really exist: keeping all people in mind during the development phases leads to better solutions overall.

Now you may be thinking: this is just what the agile principles (link) say. And that is true. While their main goal is to develop the best tool for performing the specific job that’s needed, many of the practices followed during the process are the same ones that should be followed for better adoption. The goal is not exactly the same as the one discussed in this article, but the way to achieve them is very similar, as we will see.

How to develop meaningful solutions

The starting point should be to understand the tool’s users. Ask the people who are actually going to use the tool: what are your day-to-day problems? Where do you think that there is margin for improvement? Additionally, involve yourself in their processes to really know what they are dealing with; listening to someone’s problem is not the same as actually seeing the problem with your own eyes. This step of the project is crucial, make informed decisions and do not rush them, doing it well the first time saves time and money in the long run.

Once we know the first version of what we want to develop, we need to start actually developing it. As the agile principles say, we should deliver working software frequently and welcome changing requirements. Expectations evolve with business needs, and data driven teams must adapt quickly to ensure they are driving value where needed. Even if no new suggestions are made, keeping everyone updated about the development process is an investment that’s useful in and of itself. A high focus should always be kept on the validation of this code: it’s a two way process, the code should be delivered, the stakeholders should test it, and then feedback should be sent. Otherwise this is rendered almost useless.

If communication with the end user is constant from the beginning and everyone makes sure that they are on the same page, then the requirements are less likely to change. Then if something is found along the way, via constant delivery, it’s corrected early. What’s often most highlighted about this is that it makes the tool better -which is indeed true- but it’s just as important to note that it also helps make everyone feel that they own the solution, so they’ll want to use it, and they’ll also want other people within the organisation to use it.

So in summary, we should involve everyone during the development of the tool and listen to what they think. This way we will get adoption not only by them, but also by everyone in the company.

Highlights for data science solutions

Although in the title I talked about data science solutions, so far everything could apply to any technical (or non-technical) solution. So where does the difference lie when applying this for data science solutions? There are plenty of different factors, and I’d like to highlight these two:

• Fear of being substituted by an AI that does your job: this is something that I’ve seen in quite a few projects, where the humans who are going to be helped by the AI are scared that they will be replaced. To overcome this they need to understand perfectly what the AI can and cannot do, and why although it’s a great help, it isn’t a substitute for humans. If the users are scared of the tool, adoption will be impossible.
• The results of these projects are fully dependent on the quality of the data, and this data needs to be provided and explained by humans. Very often, different people and departments need to collaborate in order to get all the data required for a project, so we must involve those people from the beginning and explain the importance of the task.

In summary, the way to get adoption for data science solutions is through constant communication where everyone listens to each other: periodic meetings to explain the status of the project and receive feedback, individual meetings with different stakeholders/departments, and always being reachable by anyone who might have relevant feedback (which is everyone!). This helps develop these projects faster and with better results, both in terms of the quality of the product delivered and in terms of the use of this product.