You don't have a data problem. You have a question problem.
A stakeholder once walked into a project kickoff with a deck already built — slide three had the solution on it: a recommendation engine. The business problem, buried in the appendix, was that sales conversion had dropped 18% over two quarters. Nobody asked why. Six weeks were spent on data pipelines, embedding models, and similarity scoring before someone pulled the CRM data and noticed the drop was concentrated in mid-market accounts recently reassigned to a new sales team. The problem wasn't product discovery. It was onboarding. A recommendation engine was never going to move that number, and the team had just spent six weeks proving it the expensive way.
That changed how I start every ML project — not with the data, not with the model, with a more uncomfortable question: is the thing we're being asked to build actually connected to the outcome we're being asked to improve? If it builds perfectly, does the number we care about actually move? When you can't answer that with confidence before the project starts, you're not doing machine learning. You're doing expensive prototyping toward a hypothesis nobody has verified.
Every ML project involves two distinct translations, and both can go wrong independently. The first is translating a business outcome into a well-posed problem — an explicit causal claim about which mechanism, if modified, would produce the desired result. The second is translating that well-posed problem into an ML task. Most teams are reasonably careful about the second. Almost none are careful enough about the first. The causal model is almost never made explicit; it's assumed, usually by whoever proposed the solution, and carried forward like undocumented debt. Everything built on top of it is technically sound. The foundation is a guess.
| What teams skip: business outcome → well-posed problem | What teams focus on: well-posed problem → ML task |
| The causal claim. If we intervene on X, does Y move? What's the actual mechanism driving the outcome? Is there even weak evidence the link exists? Who in the business can falsify this assumption? | Task framing — classification, regression, retrieval, generation. Label definition and quality. Feature availability at inference time. Evaluation metric and baseline. |
The signs of a poorly framed question are recognisable before any data is pulled, and they show up in language, not technical red flags. The solution is named before the problem — a stakeholder opens with "we need an LLM" or "we want a recommendation engine," and the ML team is being asked to justify a conclusion rather than reach one. The metric and the outcome are not the same thing — a team asked to maximise click-through rate, when the business actually wants revenue, is optimising a proxy that can actively harm the real objective. When the metric handed down is a proxy, and proxies always are, the distance between the proxy and the actual outcome needs to be interrogated before the first model is trained, not discovered after deployment when the numbers move in the wrong direction despite the metric improving.
The discipline this requires is simple to state and hard to practise under deadline pressure: ask the uncomfortable question before touching the data, not after the pipeline is built. Six weeks spent verifying a causal link is six weeks well spent. Six weeks spent building toward a link nobody verified is six weeks spent proving, expensively, what a single CRM query would have shown on day one.
Further reading: Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NeurIPS. · Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. · Pearl, J. & Mackenzie, D. (2018). The Book of Why. Basic Books. · Huyen, C. (2022). Designing Machine Learning Systems. O'Reilly, Ch. 2.