How to Find the Right Machine Learning Problem: The PIERS Framework

The most common mistake: starting with the technology

"We have data, let's apply machine learning" is one of the most reliable predictors of a wasted budget. The correct starting point runs the other way: "We have problem X, which costs us $Y a year. Can machine learning solve it more effectively than what we do today?" That single reversal of order — problem first, technology second — is arguably the single biggest determinant of whether an ML initiative delivers value.

A simple five-letter framework, PIERS, makes this discipline concrete and repeatable: Pain (what genuinely hurts), Impact (what solving it is worth), Evidence (do the data exist to support it), Repeatability (does it happen often enough to justify automation), and Solvability (can ML actually do it better than the alternatives). A problem is a strong ML candidate only if the honest answer to all five is yes.

Step 1: map the business's pain points systematically

Before evaluating anything against PIERS, generate a real list of candidate problems. Bring department heads together — sales, marketing, support, logistics, finance — for a one-hour session and have each name their top three recurring pain points, with a rough monthly cost estimate and a note on how often each occurs. A typical output looks like this:

A single session like this typically surfaces fifteen to thirty candidate problems — far more than any business should try to solve at once, which is exactly why the filtering step that follows matters.

Step 2: filter with the ML-suitability checklist

Not every business problem belongs to machine learning. Six conditions make a strong positive signal:

• Historical data exists. ML learns from examples; a genuinely new problem with no track record cannot be modelled yet. A churn model needs years of who-left-and-who-stayed data; a brand-new product launch has none.
• The problem recurs frequently. A process that happens once a month is rarely worth automating with ML — do it manually. A process that happens hundreds of times a day pays back the investment quickly.
• Real patterns exist. ML finds regularities. High-spending customers tend to share identifiable characteristics; a lottery draw does not, and no amount of data will change that.
• The decision can be automated. ML can classify, forecast and recommend, but it cannot sign a contract or conduct an emotionally sensitive negotiation. Classifying a support ticket as routine or complex is automatable; negotiating with a major enterprise client is not.
• The cost of an occasional wrong answer is acceptable. Even a strong model is typically 85–95% accurate, not 100%. A wrong product recommendation is a minor inconvenience; a wrong medical diagnosis without human review is not — high-stakes domains need a human-in-the-loop by design, not as an afterthought.
• Humans currently do the task by rule, not by pure intuition. If the process can be described as a set of criteria, ML can plausibly learn it. Loan approval follows criteria (income, history); logo design does not.

Conversely, a problem is a poor fit if there is no usable data, it happens rarely, it requires genuine creative or emotional judgement, every instance is unique with no repeating pattern, or the business has zero tolerance for error and no capacity for human review.

Step 3: classify surviving problems by ML task type

Once a shortlist survives the filter, matching each problem to a standard ML task type clarifies both feasibility and the kind of team needed to solve it:

Step 4: rank by value versus complexity

With a shortlist of ML-suitable, classified problems, plot each on a simple 2x2 matrix: business value on one axis, implementation complexity on the other. Problems that are both high-value and low-complexity are "quick wins" and should generally come first, since they deliver proof of concept fastest. High-value, high-complexity problems are "major projects" worth pursuing once the organisation has a proven track record. Low-value problems — regardless of complexity — should generally be deprioritised, since even an easy win is not worth much if the underlying business impact is small. A companion article on prioritisation frameworks covers this ranking step in more depth using the RICE method.

Step 5: write the problem up properly before approaching a technical team

A well-specified ML problem brief should cover six elements: the problem name; the current state, including how it is solved today, what that costs, and current baseline metrics; the desired future state with target metrics and a definition of success in concrete numbers; the available data (source, volume, quality, whether a usable target variable exists); constraints (budget, timeline, minimum accuracy, regulatory requirements); and success criteria with a specific ROI and payback expectation.

Here is a fully worked example for a telecoms provider tackling customer churn: current state — 12% of customers leave annually, discovered only after the decision is made, at an average lifetime value of $300 per customer, implying roughly $1.8 million in annual losses across a 50,000-customer base. Desired state — a model predicts thirty days ahead which customers are likely to leave, with at least 75% recall, allowing proactive retention offers; if 40–50% of flagged customers are successfully retained, that implies $540,000–680,000 in annual savings net of retention costs. Data — three years of history across 50,000 customers, with plan type, tenure, support-contact frequency, payment delays and usage as features, roughly 95% complete, and 12,000 historical churn examples over the past two years to serve as a target variable. Constraints — a $15,000 budget, a three-month timeline to MVP, a minimum 70% precision requirement (to avoid wasting retention offers on customers who would have stayed anyway), and standard data-privacy compliance. Success criteria — the model runs in production, generates a monthly at-risk customer list, and retains at least 200 customers in year one, implying roughly a one-month payback period.

A brief this specific is what lets a technical team scope, quote and deliver a project with a realistic chance of success — vague briefs are one of the most common causes of ML projects that drift, overrun, or quietly get shelved.