Companies need consistent definitions, usable data, and data-driven decision-making before machine learning can provide much value.
2
For business data, teams should start with the business question and check whether a SQL query already answers it before building a model.
3
The safest way to adopt fast-changing MLOps tools is to keep data in a central, portable store and avoid locking the company into one provider.
Summary
Joe Reis argues that machine learning usually fails because companies have not solved the data and organizational problems required for ordinary business intelligence. Teams may disagree about what counts as a customer, maintain competing reports, or lack clean and governed data. Adding a model to that environment creates little value. Reis recommends starting with a business question, identifying the required data, and checking whether a query already answers it. Machine learning is useful when a company needs cheap predictions at high volume and can get feedback quickly, such as workflow automation, image classification, or personalization. He also discusses the convergence of data warehouses and data lakes, the growing role of managed services, and the rapid turnover of MLOps tools. His practical advice is to keep data in portable storage, preserve exit options, and learn software engineering principles rather than chasing each new framework.
The operations around a model are harder than the algorithm
Reis says his early AutoML work showed him that the algorithm was often the easier part. Teams of mathematics PhDs worked on ensemble-learning methods, while others had to engineer features, ingest data, host models, and handle everything before and after model creation. He eventually focused on data engineering because these surrounding systems created harder problems than choosing an algorithm. He also argues that machine learning is a team problem. Data scientists, data engineers, software engineers, DevOps, and sometimes SRE all contribute, so one person rarely carries a model from idea to production alone.
Weak BI foundations make machine learning projects fail
Reis connects machine learning failure to organizational habits. In companies without a data-driven culture, departments may use competing reports and disagree about basic definitions such as what a customer is. Those disagreements produce inconsistent reporting and make it hard to decide which questions the data can answer. Data quality and governance problems then carry into machine learning. Reis describes attempts to add machine learning to a flimsy BI foundation as an oil-and-water mixture. If a company barely uses Excel to make decisions, it will struggle to understand the data, frame useful problems, and judge model results.
Cloud services can reduce the infrastructure needed for a first ML system
For companies that already do BI reasonably well, Reis says a full stack replacement is not always necessary. Cloud platforms such as AWS, Google Cloud, and Azure make the pipeline from stored data to machine learning easier. He gives SageMaker Studio and data in S3 with Athena as examples of a fairly complete path. In his view, the off-the-shelf pipelining problem is becoming more solved in the major clouds. The remaining work is deciding which business problems are worth solving and making sure the data supports those problems.
Data warehouses and data lakes are moving toward the same use cases
Reis agrees that data warehouses and data lakes are converging. He describes a shift in the early and middle 2010s toward data lakes, followed by renewed interest in cloud data warehouses. Snowflake is his example of a company selling across clouds while addressing both warehouse and lake use cases, including unstructured data in newer announcements. He expects warehouses to exist alongside fast event-ingestion systems for workloads that need low-latency data. He also says teams should define what real time means, since systems called real time may use micro-batching behind the scenes.
Machine learning is useful when predictions are cheap and feedback is fast
Reis recommends starting with workflows or applications where predictions can be made cheaply and evaluated quickly. Automating a mundane internal task, responding to user behavior, or personalizing an application can provide rapid feedback. He gives credit scoring with a five-year default horizon as a poor starting point because the business must wait too long to learn whether the model works. High-volume classification and prediction tasks are better candidates. He stresses that every business needs a case-by-case assessment, and the first project should connect to a real business outcome.
Many tabular ML problems are really data or query problems
Reis is especially skeptical about applying machine learning to tabular business data without examining the question first. A customer-return example shows the problem: if customers who return products go to the return page, a query may answer the question directly. He says that in his experience, eight or nine out of ten questions encountered in AutoML work on BI data could be answered with a single query. Teams should begin with the business question, identify the relevant sources and fields, check data quality, join the data, and then ask whether a model is still needed.
Portable data and optionality matter in a fast-changing tooling market
Reis describes MLOps tooling as a crowded and immature market. He expects frameworks, companies, and architectural patterns to change, so teams should avoid religious commitments to one tool. His practical advice is to keep data in a central object store rather than a proprietary data store when possible, and to look for exit options before adopting a service. This reduces the cost of replacing a tool if a company disappears or the market consolidates. He sees open-source and managed tools as useful choices, but says their total ownership and opportunity costs need to be considered.
Learning software engineering principles is more useful than chasing every new framework
Reis recommends understanding first principles instead of focusing only on the latest model-training technology. He points to software engineering, coding practices, and DevOps as foundations that help data scientists work in MLOps. He also recommends Josh Tobin's Full-Stack Deep Learning course as a resource for understanding the machine learning operations space. Reis says the model-training language or framework matters less than being able to containerize and deploy the result. He is direct about the limits of current tooling and expects today's MLOps architectures to look different in two years.
