The commoditization of machine learning has happened at an unprecedented rate so much so that it is difficult to find a company — big or small, David or Goliath, that is not exploring Machine learning as a means to stay relevant in this rapidly changing business environment.

In an attempt to stay relevant, firms have started putting the ‘machine learning’ keyword on their product page, in their investment deck, and also in their domain name — no wonder ‘.ai’ domain name sells so expensive — I know that because I thought of purchasing one for my lemonade stall. Anguilla, the owner of all .ai TLD, would not complain because every time a .ai name is registered or renewed, the island collects a $50-a-year fee, which goes mostly to the government treasury (Source).

This has led to the rise of data science arms in most companies driving product ideas and improvement. As a result, data science teams are becoming a strategic arm of the company and most companies claim themselves to be data-driven.

But like anything else, this has a downside when we start finding means to fit data science into everything and soon firms forget whether they are a ‘Business enabled Technology’ or ‘Technology-enabled Business’. At times we prioritize the problem that fits the solution that we have than solving the problem that the team needs to solve for the user.

Worse, we forget, Machine learning like its rule-based and now largely ignored counterpart, is also a tool. Some wise person rightly said, “When you have a hammer in your hand everything around you will appear a nail”

To illustrate this point, suppose the business ask is to increase the quarterly revenue by increasing user conversion. Product funnel from Unregistered users walking into the product to them buying the product can be broken down into many sub-steps. Now one of the steps could involve improving the ‘search experience’ that leads to more people finding the right product and adding them into the cart — but then it could also be making the payment page seamless, however, when it is data science team deciding what steps to take, in all likelihood they will prefer investing on an algorithm such Learning to a Rank to improve the search experience.

Now, I cannot suggest completely avoiding the use AI/ML on investment decks but I can surely recommend that leaders use ML only when it creates value because choosing the wrong tool from the toolbox destroys value.

In light of the above, in this article, we will talk about two important aspects of strategically using data science to solve business problems. This will be relevant for those who either lead a data science team at their firm or interface regularly with the team as a product or a business leader— Framing a business problem as a machine learning problem and then conveying the solution back to the business users.

At my firm, I lead the Business Intelligence Decision Systems that is responsible for descriptive analytics, predictive analytics, and prescriptive analytics and augments human decision making through various models — at times machine learning-based. Regularly, I find myself interfacing with the business teams to understand their pain points, which not surprisingly is often highly ambiguous. In fact, a bit of ambiguity is a sign of a healthy workplace because then it allows enough opportunity to:
a) Choose the playing field — where do you want to play, why?
b) Choose the rules of the game so that you can allow your team to exercise their creativity

Before settling on using machine learning as a means to solve the problem, think of the problem that we are trying to solve.

‍

‍

Typical questions to ask are — What exactly is the problem that we are trying to solve? Does it need to be solved at all? Why — Does solving the problem help your moat — your competitive advantage? By how much? How sustainable is the advantage? What does the ROI look like? These questions help evaluate firms focus on the most important aspect that is the essence of their existence.

In short, solving the right problem is more important than solving a problem right away.

Here is a caveat, do not keep discussing these questions — The goal is not to over-analyze it to an extent that you take your sports car out of the garage only when all the lights in the city are green. I remember the time when my previous team was planning on a major business transition and the leaders came up with 200 open questions. Unfortunately, most of these questions were so open-ended that the team spent weeks trying to get answers with no luck. While it is okay to register as many known unknowns as possible, don’t let that be the reason to keep your car in the garage. Unfortunately, there is no acid test to quantify how much analysis is too much so I will leave it to your best judgment.

Once you have evaluated that, the next thing to evaluate is how do we want to solve the problem, this is where we look into our toolbox and we all sincerely hope that you have more than just one kind of tool in your toolbox.

If you have multiple ways to solve a problem, then we would need some way to reduce to a possible set of approaches. Typical questions that I use to narrow down possible options are: What time horizon we are working with for the MVP and for the full-scaled solution, what do the key business metrics look like — this is extremely important to understand because Business metrics and model performance metrics (model need not be ML and could very well be rule-based) typically are directionally aligned but have different slopes, which if not discussed between the business and technology stakeholders may lead to unmet expectations, what is the ‘elbow point of return’ beyond which the diminishing rate of return is not worth investing.

Once business stakeholders and technology teams are aligned on the problem that they are solving and the outcome, the technology team can explore the trade-off between the rule-based and the machine-learning-based approaches. The typical rule I suggest is to prefer the rule-based over the ML-based just because it is cheaper to maintain and easier to explain to business teams.

Once we have narrowed it down to Machine learning as a means to solving the problem, we can take the steps to translate our business problem into a mathematical construct that machine learning can solve.

Now that we know the perils of applying machine learning tool to every business problem, in the next article, we will discuss the core topic of framing a business problem as a machine learning problem and also the last mile of the machine learning project, which is to convey the solution to the business users.

‍

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

‍