Given the unique nature of ML systems (focus on data and algorithms), product managers often get caught up in getting the metrics right and forgetting about many of the important things that can make or break a product.
Here are a few examples of how I’ve seen ML products go astray for reasons other than the model’s performance.
This post was written by Ben Dickson, a seasoned engineer, tech blogger, and mentor at our AI/ML Simulator for Product Managers.
Technical considerations
One team was working on a product that required near-real-time object recognition, but they had not considered where the machine learning model would run. For example, if it were to run on the cloud, they would have to consider possible network outages, the delay caused by the roundtrip of sending the data to the server and receiving the response. They also hadn’t considered the scale issues with having thousands or possibly millions of people using the product. On the other hand, if it was going to run on an edge device, they hadn’t taken the resource limitations it would impose on the model (memory, compute, etc.).
Having the best-performing model will not serve you well if it doesn’t meet the technical requirements of the product’s environment.
Practical considerations
In one project, the team was creating a customer churn prevention system. They had trained a machine learning model that predicted with 90% accuracy which customers would churn within the next month. The sales team was then supposed to use this prediction to reach out to the flagged customers and ask them to do an interview and offer them a discount.
However, after the ML product team talked to the sales team, they realized that one month was too little time. The sales team needed at least two months to be able to turn the customer around. Therefore, the model was not very useful and they had to restructure their dataset and retrain the model.
Without a deep understanding of the problem’s nature and the target intervention, ML predictions often become useless.
Legal and regulatory considerations
In one project, the machine learning team fine-tuned a model based on data from ShareGPT. The model performed very well, but it had to be scrapped because the terms of service of OpenAI prohibit the commercial use of models that have been trained on data collected from its models (ShareGPT data comes from ChatGPT).
Always make sure you have full knowledge of the license permissions of the models and data you use in your products.
In another case, the machine learning team was working on a deep learning model for evaluating loans in a financial product. However, regulations required them that if they reject a loan, they must be able to explain the reason to the customer. The deep learning model was not useful because it was an uninterpretable black box. The team ended up training a decision tree–based model that was not as performant as the DL model but was fully transparent and explainable.
Always make sure to understand the regulatory environment of your application and industry and to communicate it to the machine learning team.
Financial considerations
One of the things that often falls through the cracks is the costs associated with using machine learning at scale. Will it be cost-effective? How does it affect your unit economy?
For example, say you’re deploying an LLM-powered assistant in your e-commerce application to help users fill their shopping carts through a conversational interface. What is the cost-per-token of the model you’re using? What is the average number of tokens per conversation between the customer and the assistant? What is the average revenue gained from an AI-assisted shopping experience? Does it cover the costs of the model? If not, can you adjust your application to use a less expensive model?
Timing considerations
Say your ML-powered product or feature aims to meet a new safety regulation that will become effective in three months. Will you be able to train, test, and deploy the model at scale by that time? Timing considerations can have important implications for the type of model you use. For example, time shortage might force you to consider using ready-made online services instead of training your own models (with the option of creating your own models in the future).
As the product manager, make sure to have a full understanding of the entire scope of the product and its environment. Talk to stakeholders and subject matter experts, discuss the non-technical aspects of the product with the machine learning team, and make sure everyone understands the constraints and goals.
In summary
- Ultimately, effective ML product management requires a holistic understanding of the product’s ecosystem, achieved through robust communication and collaboration across all stakeholders.
- Successful ML products require more than just model accuracy; they must align with technical infrastructure realities, practical user workflows, and operational timelines.
- Product managers must consider legal and regulatory issues, ensuring data/model licensing compliance and meeting industry-specific requirements like model explainability.
- Careful consideration of financial viability, including the costs of scaling ML solutions, and strict adherence to project timelines are critical for overall product success.
All posts from the series
- How to choose your first AI/ML project: a guide
- How to discover potential AI applications in your business
- How we turned around an ML product by looking differently at the data
- Large language models: foundations for building AI-powered products
- Improve Retention by using ML/AI: what to do and what not to do
- Basic guide to improving product quality with LLM
- Advanced methods for improving product quality with LLM: RAG
- Why an ideal ML model is not enough to build a business around ML
- What to build and not to build in AI
- How to use AI for product and market research