When I first started leading a data science team, my first thought was to review the roadmap with the team and come up with a revised roadmap for the team and the company in matters related to data science.

However, as I started interfacing with the team members of the data science team, one thing that came up repeatedly was that despite shipping some ‘good’ machine learning models, the adoption of those models among business stakeholder teams was almost zero. As per the team, there was just no enthusiasm for any machine learning models. In the last year alone, the team developed a propensity model, booking projection curve, demand forecasting, etc.

This situation is quite common in many companies. Data science teams come up with models and deploy them, only to find a tepid response from the corresponding business teams. In this article, I will review my findings of what leads to low adoption and how we can change so that we increase adoption among business stakeholder teams.

Back to my story —Being from growth product management, understanding friction in product adoption has been my favorite problem to solve. In fact, the mental models that I used to solve growth problems, have been my go-to models to solve some ‘wicked’ problems in life. The adoption of data science models by internal stakeholders seemed like a great problem to tackle. All I needed was to treat the business stakeholders as the users of our product and the model that the team was developing as the product features. It proved to be significantly more difficult than I thought but an interesting experience nevertheless.

The first task that I took was to do a qualitative study and understand the friction behind the adoption. To gain a deeper understanding, the team and I did interviews with all business stakeholders and their team members. What I learned from the exercise can be summarized below:

1. I do not know ‘how’ this model works: Many business stakeholders raised concerns that they do not know how this model worked. My team was surprised, “Why do they need to know, they are business teams, aren’t they supposed to rely on our expertise?”. Right? Wrong! Data science models unlike their rule-based counterparts are not perceived similarly. Here business teams bring tons of insights, in absence of which the model is nothing but garbage-in and garbage-out. If you are not including your business stakeholders in your exploration phase, you will hit friction. The worst is that the team will not verbalize this in words. This is why data science leaders need to empathize with their users — business team members to understand the root cause.
2. I do not know ‘if’ the model works: Some business stakeholders raised doubts about whether the model was even working, “We used it but I do not know if this model works, hence we don't use it that often. Besides the leads that the model says are good and the leads that it says are not good are both equally good when we analyzed it”.
3. De-humanization: Some teams (even though not directly in those words) did feel that model was intentionally created to replace their role in the company. Now, this was tough — I did not expect something like this.
4. The education problem: Many business teams said that they were never informed about how to use the model. Now, this is not unique to the data science model, it can happen anytime your team is focusing more on shipping features rather than achieving the business outcomes.
5. We can do more due diligence when we look at a client profile: Now this is similar or somewhat related to point #2 (I do not know ‘if’ the model works), where business teams do not feel that the model is looking at the ‘right’ features.
6. We don't need it: Some business teams said that they didn't need the feature. Now this may seem surprising but this, in my findings, resulted from two issues:
   a) A model pushed down to them that did not solve the pain points that they were most grappling with.
   b) A few resisted changing their process to accommodate the model — We can call them resistors. Like it or not, you will find such people in each organization, and in many cases, we all happen to be in that camp for one process change or the other. Classification of team members in the right bucket — we will talk about what those buckets are will lead to an easier path to adoption.

Most of these findings are true for other companies as well, which is why it is not surprising that most data science projects fail to see the light.

With all these insights, the team started working on identifying possible solutions. It all boiled down to these steps that each data science team can adopt to increase alignment of stakeholders:

• Understand the Adoption curve — Not everyone will be the champion of your ideas but identifying the ones who are the champions and the ones who could be the early joiners is important. It is equally important that we strategize the order of approaching the different buckets. Many times, we try to onboard resistors first, and since they are actively trying to block the project, for whatever reason, the project meets resistance much early in the process even before it has gained the required critical mass to create momentum. I will discuss this in detail in another article, but in nutshell, bring the champions and enthusiasts first on board, laggards will follow when they have no choice left. At most companies, enthusiasts outnumber the laggards.

• Make them stakeholders as you are developing the model: People feel associated with the models that they have participated in from the beginning. This is also called the ‘Ikea effect’. Do not surprise them with your model. The more involved they have been, the more adoption you will see. If you can’t relate to it yet, ask yourself how sometimes even when you incorporate someone’s suggestion as small as changing the font on the slide makes the other person buy-in to your idea? This is nothing but the ‘ikea effect’ in effect. Ignore this and go straight into the meeting with the model at your own peril.
• Explain the model: Nothing hurts more than the explainability problem in data science. But in this case, I am not talking about whether the model is explainable or not, which is altogether a different problem, but whether you have educated your audience on how the model works, what are the various features used, and given enough context/background before thrusting the features on them. The more you explain, the more the adoption you will see. People, especially analytically intuitive people, hate accepting something just because one told them so.
• Report accuracy by backtesting or validating the model often: Data science models are credence goods. The more people trust the model the more adoption you will see. To increase trust, backtest your model and report the validity and the accuracy of the model frequently. This increases the credibility of the model and the pressure on the team. When possible also show the
  Trust is directly proportional to acceptance which is directly proportional to adoption which is in turn directly proportional to more inputs and ideas. This feeds into the model creating a virtuous cycle of a culture change in the organization.
• Tinker, tweak, and adjust: Can't stress enough the importance of treating data science models as iterative rather than a one‐off. V0 does not create as much value as V4. Unfortunately, V4 is less glamorous because you already pushed out the propensity model, now what. The data science team is many times incentivized for exploring new, which leads to the problem of Hoping for A and rewarding for B. Team in turn starts focusing on Output rather than the outcome i.e. we focused on shipping the model out of the door, not on solving the problem that we started with. Data science or business problems that we encounter in practical settings are often messy that takes back and forth between hypotheses, analysis, and synthesis, each time deepening our understanding of the problem space so keep iterating.
• Pitch the model as an augmenter rather than a replacer: Never ever pitch a model as a replacement of a team’s work. This hardly ever works and rarely if ever a model is truly a replacer of some skilled work. So highlight this early on that the model is meant to augment the humans — assisting them in doing their role better. This will reduce the fear in their minds and lead to much better adoption.
• Educate your business team on how to use the model: The biggest difference between a programmer and a data scientist that I see is that data scientist has to do much more than just coding, and a big part of their repertoire is to educate their business stakeholders and socialize the usage of data and analytics in the company. So if your team is not already doing so, make it a point that you educate your business teams on what problem statement you are solving, why it is worth solving, what insights you gain from the data, what impact you will create if you had solved the problem, and then talk about the solution — Machine learning should be presented as a tool rather than the end in itself (though if your team finds it fascinating, by all means, do use the lever). Use the art of storytelling to create a compelling narration and the whole team will be walking with you.

My team and I are on a learning journey every single day through this challenge but the more I understand the more fascinating this problem space looks. Do reach out to me on Linkedin and let me know how you solved the adoption problem in your company.

‍

Read our other articles on Product Leadership, Product Growth, Pricing & Monetization strategy, and AI/ML here.