The Familiar Playbook
Ask any machine learning engineer about supervised learning, and you'll likely hear a familiar story. It starts with a pile of labeled data—cat photos labeled "cat," spam emails flagged as "spam." You choose a model, feed it the data, and let it learn the patterns.
The goal is to create a function that can take a new, unlabeled piece of data and make an accurate prediction. We split our data into training and testing sets, tune hyperparameters, and measure success with metrics like accuracy or precision. This loop is the bedrock of modern AI, a powerful and well-understood process for teaching machines. It’s what gets all the attention in bootcamps and tutorials. The process is so refined that it can feel like an assembly line: data in, model out. But this focus on the 'how' often obscures the far more critical 'what' and 'why.'
The Step We Rush Past
The hidden detail, the step most often skipped or rushed, isn't a complex algorithm or a secret data-cleaning trick. It’s the meticulous, time-consuming, and decidedly unglamorous process of problem formulation. Before any data is touched, the most critical work is translating a vague business goal into a specific, measurable machine learning task. This is where projects go wrong. A business leader might say, "We need to reduce customer churn." An engineer, eager to build, might immediately start gathering data to predict which customers will leave. But the real questions are deeper. What defines 'churn'? A canceled subscription? A dormant account? How much time do we need to intervene? What action will we take based on the prediction? A model that predicts a customer will leave tomorrow is useless if the only intervention takes a week to implement.
Why a Great Model Fails
Skipping this rigorous formulation phase leads to models that are technically brilliant but practically useless. An engineer might build a model that predicts customer churn with 99% accuracy, only to discover it works by identifying customers whose credit cards have already expired. The model isn't wrong, but it’s not solving the business problem; it’s reporting an event that has already happened. This is a classic example of target leakage, where the model trains on information that won't be available at the time of prediction. The result is a model that performs beautifully in testing but falls apart in the real world. This failure isn't technical; it's a failure of translation. The team built a perfect answer to the wrong question because they didn't spend enough time defining what the right question was in the first place. This misalignment between the business problem and the technical solution is a recurring cause of failed AI projects.
Reframing the First Step
To avoid this pitfall, engineers and teams must treat problem formulation as a core part of the project, not just a preamble. It requires a cross-functional conversation between technical experts and domain experts. Before looking at data, ask: What decision will this model support? What is the ideal outcome? What are the constraints? For the churn example, a better-formulated problem might be: "Predict which active, high-value customers are at risk of non-renewal in the next 60 days, using only data available up to that point." This formulation is specific, measurable, and aligned with a potential business action. It defines the target population ('active, high-value'), the timeframe ('next 60 days'), and implicitly guards against leakage ('using only data available up to that point'). This process is more art than science, requiring deep thought about the business context, not just statistical patterns.
