Getting Business Value from AI: Understand the Business Problem

Relating an AI solution back to a business need is often where AI falls down and fails to meet its objective of adding value to that business. Taking the example of machine learning, in the abstract it may be possible to build very good models which can predict the likelihood of customers to churn (leave a service or subscription). However, the problem may be that the business does not have a way of using these predictions, or the value they provide may be available more easily, cheaply or effectively from a different source. ML models (with the same applying to other flavors of AI, including Gen AI) are unlikely to add value by themselves just because they exist. Rather, they need to be able to solve an actual business problem.

To overcome this, the early stages of a project need to be approached like detective work: there is a trail of evidence from documentation and data, as well as interviews with various individuals, that together point to what the problem might be. There may well be different viewpoints on the perceived problem, with similarly diverse views being reflected in ideas of what the solution should be. This is where we, as the experts, should help the project to navigate this situation to settle on an appropriate solution.

But before we can do that, we need to put on our detective hats and get our magnifying glasses at the ready to understand the business problem. What does this process look like? It is never exactly the same, but an illustration of what it might typically look like is in Figure 1.

In the above figure, the first two steps are spent exploring the problem space, namely ‘Understanding the business problem’ and ‘Understanding the context’.

In terms of ‘Understanding the business problem’: here the objective is to try to understand the problem as much as possible, and to keep going until you feel as though you understand it inside and out.

It is likely that this starts at a fairly high level with senior business stakeholders (i.e. most likely those who are controlling the budget and are proposing the project). Then expect to move towards a more granular understanding of the problem when talking to the eventual users of whatever you are expecting to build as well as any relevant skilled practitioners. This process should help you to know the pain points of the various people in the business.

This view is then validated with a broader range of stakeholders and ideas of a fantasy ‘to-be’ state collected. An interesting question to ask stakeholders is “what they would like the solution to be if they could wave a magic wand”.

A key aspect here is to always validate what you are told; a great way of validation is to learn from ethnographic researchers and observe what actually happens in these business contexts. After taking on board the different perspectives, this now helps to get past any potential biases that there might be.

Understanding the business problem from a range of business perspectives is only one aspect. The practical data and engineering constraints also need to be understood too, and can be done in parallel. At its most simple level, this is about establishing what data is available and understanding the existing system(s) that the anticipated solution would need to fit into.

While collecting and assimilating this information, it is also a good idea to begin to map these learnings to a prototype solution design. Some of the questions that might be useful to consider at this stage might be:

• How can elements be built using existing or commonly understood (generative) AI models or approaches?
• What processing or logic would need to be applied to these algorithm outputs to make them usable?
• How can different data sources or model outputs be combined to improve the solution?

At this point, with a better understanding of the context, it can also be useful to go back to some of the business stakeholders with practical questions about how they perform their tasks, which would help with the solution, such as:

• What assumptions do skilled practitioners make in their roles performing such tasks?
• Are there any rules of thumb that skilled practitioners use to do their job?

The development of the solution will no doubt be an iterative process, with updates added as new information becomes available. However, it is a good idea to present something to the key stakeholders at as early a stage as is sensible to identify any misunderstandings and to ensure that feedback – constructive or otherwise – is gathered. It is at the point of having some sort of concrete design to share with stakeholders that some of the real and practical feedback (and obvious ‘gotchas’) can be surfaced.

With further iterations, and once a more mature version of the solution has been created, then there is a formal checkpoint step to get feedback on the current proposed solution (‘Validate the value of the solution’), with a key element being to validate the value that this solution offers.

How value is measured will depend on the use case, but essentially this relates to:

1. does it successfully address the business problem in question?;
2. is the performance acceptable?;
3. what is the cost relative to the existing approach?;
4. can it be done more easily, cheaply or effectively using different methods?

Based on this assessment, we can make a decision about the business benefit of further iteration of the proposed solution (‘Solution ideation and development ‘), or whether further iteration is required for understanding the systems and data, or business problem (‘Understand the business problem’ and ‘Understand the context’). Implicit in the steps mentioned in this section is the need to work closely with stakeholders, since without them it will have been virtually impossible to get this far. This is something that we will cover in more detail in the next article.

In order to be able to begin to get business value from AI, we first need to understand what exactly the business problem is that we are trying to address, and using this and information of the business context, we can then design possible solutions. In this article, we have identified examples of required steps as well as useful questions to ask, which will help to get us along that journey.

In this article, we have identified examples of required steps as well as useful questions to ask, which will help to get us along that journey.