A while back, I worked with a company whose data workflow was entirely manual. Every month, someone would collect exports from the accounting team, master them by hand, map everything together, and produce reports. The entire dataset was around 10 megabytes.
They knew this process was fragile and time-consuming, so they brought in a vendor. The vendor pitched them an enterprise-grade data platform — automated pipelines, the ability to combine data sources, a visual interface where even non-technical people could inspect the code and execution. For them it sounded like a perfect solution.
The problem was that the company didn't have a single technical person who could actually oversee any of this. And the ability to look at code and pipeline execution doesn't help much if nobody on the team can interpret what they're seeing — something that wasn't obvious to them at the time of purchase.
When they brought me in to handle the implementation and I found out which platform had been chosen — this wasn't discussed with me from the start — I immediately knew it was far too much for what this team actually needed. The external data sources still had to be exported manually regardless, because that part couldn't be automated for reasons outside anyone's control. The only thing that changed was that the mastering and mapping was now automated. Which is genuinely useful — but a simple script could have done the same job without the enterprise infrastructure running at several hundred euros a month.
But by that point, the decision had already been made and the contracts were signed. All I could do was implement it in a way that kept the monthly costs as low as possible.
I keep seeing variations of this pattern. A company feels the pain of messy data, someone pitches a tool that promises to fix it, and the purchase happens before anyone has clearly defined what the problem actually is. It usually ends up as an expensive solution to the wrong question.
After going through enough of these situations, I started noticing that there are a few questions that, when answered honestly up front, tend to prevent this kind of outcome. None of them are particularly hard to answer — the problem is that most companies just don't ask them before making the purchase.
1. What decisions do you want to make better?
This is the one that gets skipped most often, and it's the most important one. If you can't name the specific decisions that better data would improve, you're buying technology for its own sake.
It's tempting to think in terms of "we need better reporting" or "we need a dashboard." But those are outputs, not outcomes. The real question is: what decisions are currently being made based on gut feeling, outdated numbers, or incomplete information — and which of those decisions actually matter for the business?
At the company with the 10MB data warehouse, the answer would have been something like "we need to agree on how we calculate cost across our portfolio." That's a conversation, not a technology purchase.
2. What data do you need for those decisions?
Once you know which decisions you're trying to improve, you can work backwards to what data you actually need. Not all the data you have — just the data that feeds into those specific decisions.
This sounds obvious, but in practice most companies approach it the other way around. They start with the data they have and try to figure out what to do with it. That's how you end up with dashboards full of metrics that nobody acts on, because nobody asked for them.
3. Where does that data live today?
Often the data you need already exists somewhere in the company. It might be in a spreadsheet someone maintains manually, in a system that nobody has direct access to, or in someone's head.
Before buying a new tool to collect or centralize data, it's worth mapping out what you already have and where it sits. Sometimes the problem isn't missing data — it's missing access to data that's already there somewhere.
4. Who uses it and how often?
A report that ten people rely on every day is a fundamentally different problem than a report one person checks once a quarter. The investment, the infrastructure, and the urgency are completely different.
Understanding who actually uses the data — and how often — helps you right-size the solution. Not everything needs a real-time dashboard. Some things are perfectly fine as a monthly export.
5. What would change if this investment actually worked?
This one forces you to define what success looks like before you spend money. If you can't clearly describe what would be different in six months after a successful implementation — how your team works differently, what decisions get easier, what processes go away — then the investment probably isn't ready yet.
It's not about building a business case with projected ROI. It's about being honest with yourself about whether you can articulate the outcome you're buying.
What if you can't answer the first two?
If your company can't clearly say which decisions it wants to improve and what data it needs to improve them, then buying a tool is premature. The first step is to have those conversations internally — across teams, between the people who make decisions and the people who work with data.
Some organizations can do this on their own — if cross-team conversations already happen naturally and someone can facilitate the alignment. Many can't, and that's where bringing in someone from the outside helps — not to own the process permanently, but to get it started. The goal is always to build that capability internally, not to create a dependency.
Either way, the conversations come before the technology. Every time.
Not sure where your company stands?
The Data Maturity Assessment takes two minutes and gives you a starting point.
Take the Assessment →