Introduction
"Building things that really matter." Nice slogan, right? But if you work in data, you probably know that it’s not that simple. So many of us build dashboards, reports, or tools that get hyped at first… then, weeks later, we realize they’re barely being used. It’s frustrating—puts a damper on the motivation, for sure. So, based on my experience the problem can be solved by following the mental shift from providing my effort as a service to building data solutions to their business problems.
There’s more to this shift than just wanting to feel good about my work, though. I recently wrote about the why behind Data Products and why they have more impact than just rolling out fancy dashboards or endless tables [link]. This post is the natural follow-up to that conversation. So if you’re already on board with the why, then the next question to ask is how to actually build Data Products that make a difference. That’s where we’re headed here.
Recap: It’s About the Value
To create a Data Product that matters, you have to think about its core value. Really, it’s about why anyone would need it in the first place. What is it helping users do? How will it make their work better or their lives easier? If you can nail down those answers, you’re halfway there. Finding that “sweet spot”—a mix of KPIs, visuals, or alerts that genuinely help—is what makes a Data Product valuable.
But still… how do you get there?
So, How Do You Do It?
Here's the process I like to follow to build Data Products that people actually find useful:
Start with User Group
Before diving into requirements or sketching out solutions, begin with a deep understanding of the user group who will be using (and benefiting from) your data product. This isn’t just about knowing their roles or departments but really understanding their day-to-day challenges, goals, and how they make decisions. Identifying who they are, what they need, and what barriers they face is the foundation for creating something truly valuable.
Meet with potential users, ask them to walk you through their typical workflows, and listen for insights that might not be obvious. Often, the data challenges they face go beyond just “not having enough data.” It could be about access, clarity, decision fatigue, or integrating data into existing processes. By getting a firsthand look at their experience, you’ll be better positioned to create a product that actually enhances their work and makes a measurable difference.
Starting here also helps you build a data product with a real, actionable purpose. It’s not just another dashboard or report; it’s a tool crafted around genuine user needs, with the potential to make a noticeable impact from day one.
Get Requirements
I know, I know. The phrase “take requirements” isn’t exactly thrilling, but the truth is that is one of the most misunderstood parts of the process. You have to know what your users actually need—and sometimes, what they don’t need. It’s easy to jump into data and solutions, but starting with a solid understanding of specific user needs lays the groundwork for everything else.
A common pitfall in this stage, that I am guilty of as well because I used to do it a lot, is instead of building an understanding of user’s specific challenges, taking a description of the final product. Sometimes this is client’s pitfall as well, when the requests coming are too technical than it should be. The customer should focus on describing well the problem/challenge he confronts, and not a solution that would help him. Having said that, you as data professional should help your client focus on the right things by making the right questions. Building a solid understanding of the situation is crucial.
So, this stage is about getting the right input from the right people.
Talk to Key Stakeholders – Figure out who will use this product and who will be affected by it.
Run a Discovery Session – Understand what they’re trying to solve. The real “why.”
Map Out Data Sources – Confirm the data you need is available and reliable.
Prioritize by Impact – Balance what’s feasible with what’s valuable, and keep the user’s workflow top of mind.
It’s useful to document all of this so that you have a “source of truth” as you move forward. I use a template to capture requirements, but a simple doc or form works too.
Build a Data Product
Once you’ve got a clear sense of the “what” and “why” behind the data product, you’re ready to start building. But here’s where it can get tricky: it’s easy to lose sight of that core value for users as you dive into the details. Its easier to avoid this, by keeping the value proposition in view at every stage and trying to avoid to build staff that aren’t necessary.
However, its easier said than done. As we head into 2025, there are a few key features every modern enterprise data platform should consider to stay ahead and avoid tech debt down the line. It is hard to find the balance between what its important, and what its not. There isn’t one answer fits all here. What’s important though, is to keep things as simple as possible and avoiding tech dept as much as possible.
Measuring Success (Is it Actually Working?)
So, this part is like tracking progress on what we have done. We need to know if the product is doing what it’s supposed to, right? Think of it like startup metrics; they check if they’re growing, retaining customers, etc., and we need to do the same for Data Products.
Here are a few things I’ve found worth keeping track of:
Adoption – Are users coming back to it?
Engagement – Are they interacting with it frequently, or is it just sitting there?
Outcomes – Is it helping them make decisions faster, get things done more efficiently, or proving useful in a way that saves time or money?
Feedback – This can be the most honest indicator. Are they happy with it, or is there a list of issues?
These are the signposts that show us whether we’re actually adding value or if we’re just building a shiny tool with little real impact.
Refine and Repeat
Building Data Products is rarely a one-and-done process. The products that are most effective are those that improve and adapt over time based on user feedback and what the metrics show. If you’re open to trying different things—whether that means involving different user group or adjusting features—you’ll be in a much better place to create something that users truly value.
Key Takeaways
So, how do you know when you’ve hit the mark with a Data Product? Here’s what to look for:
It’s Part of Their Routine – When people are naturally incorporating it into their workflow, that’s a good sign it’s useful.
It Shows Real Benefits – Ideally, you can show that it’s providing actual, tangible ROI.
You’re Continuously Improving It – The product gets better with each iteration, based on real needs and feedback.
And hey, if it’s not perfect right away, that’s okay. Sometimes it takes a few tweaks, maybe a total overhaul, or finding a slightly different focus to really make it work. It’s all part of the process, and ultimately, those are the products that end up making a difference.
So, that’s it. Building data products that really matter takes time, a bit of patience, and a lot of listening. But when you get it right? It’s worth it, and it shows.
And now, the next question coming in my mind is, in order to be agile, be modern (do not confuse with Modern Data Stack) and be focused on finding out the value proposition, what features should have a data product? [to be continued …]
