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.
# | Questions | How your partner should prepare |
1 | What is your role within the organization and what are your responsibilities? | Org chart, role description, how it’s evolved, and how you interact with data (e.g., viewer, creator, analyst) |
2 | What are your goals and what does success look like for you and your team? | Departmental/corporate objectives and how they're measured (KPIs, cadence) |
3 | How does data support your team today? | Examples of reports or tools used in your day-to-day |
4 | What needs to change to better position you for success? | Known pain points, blockers, and examples from other roles |
5 | What changes are happening that may support or hinder your data journey? | Info on org changes, upcoming projects, or process overhauls |
6 | Who do you rely on most when it comes to getting data? | A map of who helps with data requests and what that process looks like |
7 | What’s a recent decision your team made — and how confident were you in the data that supported it? | Real-world examples of decision moments and the supporting data |
8 | How do new team members learn how to access and use data today? | Onboarding materials or anecdotes — or the lack thereof |
9 | If we could solve one thing for you in the next 30 days, what would it be? | Your team’s most pressing data pain point — the one that would make the biggest difference quickly |
10 | What happens if we do nothing? | Honest view of the cost or consequence of leaving data capabilities as-is |
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.
