Is it an application problem, or a data problem? Getting that wrong at the start is why some technology projects run over before they've properly begun.
Strategic Technology Consultant Jerome Jones has spent fourteen years across strategy and leadership roles, and recently returned to hands-on building through AI-accelerated development. In his latest piece, he breaks down the one question we ask in discovery to tell an application problem from a data problem, and why AI is raising the stakes on getting it right.
Over the last couple of years, we kept running into the same problem on B2B technology projects.
A client would come to us with a clear goal: free up analyst time, automate a manual process, replace a clunky Excel workflow. They'd ask for a dashboard or a tool. We'd scope it, start building.
And then it would get complicated. The data wasn't where we expected. Different teams had different numbers. We'd spend more time wrangling sources than building features. Projects ran over. Clients got frustrated. So did we.
For a while we assumed this was just how it went. Complex clients, messy data.
But when we looked more carefully, we realised we'd been misclassifying the problem from the start.
Two different types of project
Here's the distinction we landed on.
In application-centric thinking, the database serves the application. You start with "what are we building?", the screens, features and user journeys. The database is just storage.
In data-centric thinking, applications serve the data. You start with "what data do we have, and what state does it need to be in?" Applications are just one way to consume it. Getting messy spreadsheets into a trusted warehouse has value on its own, even if someone exports it straight back to Excel.
Neither is wrong. But they need completely different approaches.
The question we started asking
We introduced a diagnostic into our discovery process:
"If we guaranteed the data was accurate and accessible, but built no new interface, would that still be valuable?"
If the answer is "then what's the point?", it's an application problem. Build the tool.
If the answer is "yes, that would help enormously", it's a data problem, regardless of how the request was framed.
When we looked at our pipeline through this lens, roughly three quarters of the projects were data problems. Most B2B information businesses give the second answer when you push on it. They're data businesses. Their competitive advantage is the data, not the interface.
Why it matters more now
AI is raising the stakes.
An application built on unreliable data was always a problem. An AI agent built on unreliable data is a liability. When AI is summarising, recommending or acting, the quality of the underlying data becomes critical in ways it wasn't before.
What we changed
We started classifying projects earlier. We built the diagnostic into how we scope. We invested in data-centric skills alongside our application development strengths.
It's not complicated. But it took us a while to see it clearly.
