Your Data Stack Shouldn’t Come First
- Dave Findlay
- Jun 18
- 3 min read
It’s easy to get excited about technology....
but in order to have a successful data function, your data stack shouldn’t come first.
The modern data stack is sleek, powerful, and constantly evolving. New technologies
promise better pipelines, faster queries, smoother integrations. So it’s no surprise that many data programs begin by architecting the stack — building infrastructure before anything else.
But that’s often where things go off the rails.
We’ve seen companies sink months into designing scalable, elegant architectures... only to realize too late that they haven’t solved a real problem for the business.
If you’re not solving a problem, you’re building a monument.
The most common misstep we see is starting with platforms instead of people.
That usually sounds like:
"We’re rolling out Snowflake and dbt."
"We’re building a data lake with reverse ETL."
"We’re implementing a modern BI tool so people can self-serve."
Those are all fine components — but they’re not a strategy.
If no one trusts the data, or knows how to use the tool, or feels like their job got easier... it doesn’t matter how modern your stack is.
Start with the pain. Design with the people. Then build.
That’s why we use a structured discovery process built around ten practical questions.
These questions are designed to surface business context, reveal pain points, and expose hidden opportunities before we write a single line of code.
This process does more than gather information — it builds trust. It gives business partners a voice early in the process, which makes them more likely to engage later. By the time we start prototyping, we’re not guessing. We’re designing around real needs that have been heard, understood, and prioritized.
Now, you don't need to make it through all of these questions verbatim. The are simply meant as conversation starters. Often times I only make it through half of these before the flood gates open and the feedback starts flowing.
Once we’ve defined what success looks like for actual users, we define our initiatives, prioritize and go back to get feedback. Only then do we start thinking about the underlying tech — and even then, we ask: what’s the lightest way to support this?
That’s where delivery gets fast, focused, and actually useful.
The stack is there to serve the strategy, not to define it.
Before you build anything, ask:
Who is this for?
What will this help them do better?f
Because a scalable, elegant data stack that doesn’t solve a business problem… isn’t scalable or elegant at all.
At Fuse, we believe a great data strategy only matters if it leads to action.
If you’re ready to move from planning to execution — and build solutions your team will actually use — let’s talk.
