Contact us

What makes a good data product? What five years taught our team

FELD M Blog Illustration Cogs
Table of contents

Over the last five years, we've developed a practical way to think about data products: a pyramid that sorts them by purpose, and a lifecycle that carries them from idea to retirement. This post walks you through both.

In a recent talk on data literacy, we used the idea of a hero's journey to make the concept easier to grasp. One slide mattered most: it showed where communication tends to break down between specialists and stakeholders.

In short, the mental model shifts at every step, from collection to processing to the moment someone reads a dashboard. (Evelyn Münster is a great resource if you want to go deeper, and she inspired this visual.)

Where problems arise when working with data: encoding and decoding

Where do problems arise? When working with data, there are two places where things reliably go wrong: encoding and decoding.

After the talk, someone asked: "Do people actually understand what we mean by data product?" More often than not, the answer is no, especially when data literacy and organizational maturity are still new ground. With that in mind:

 

What is a data product?

A data product is a solution designed to address a specific problem using data. It might be a recommendation engine, a predictive model, or an interactive report. The goal is always the same: turn raw data into something useful, actionable, and meaningful for the people who use it.

Which is to say: a data product is not an isolated deliverable like a dashboard or a dataset. It's a tangible outcome. When done right, it creates measurable impact, whether by improving a process, enabling better decisions, or supporting an entirely new service.

That distinction is why at FELD M we have a whole team dedicated to this. Because too many data initiatives get stuck in pilot phases or never deliver results. We've seen it time and again: well-meaning efforts that never made it into production, burning resources, and eroding trust in data and tech along the way. So we focus not just on building things right, but on building the right things.

 

Why data projects often fall short

The usual suspects are:

  • No clear objectives: Without a well-defined goal, projects drift and never deliver.
  • Poor data quality: Inaccurate or incomplete data undermines any analysis, and fixing it late is costly. Early investment in clean, well-structured data pays off.
  • Not enough stakeholder engagement: Without buy-in from the people who matter, it's really hard to reach the adoption and implementation stage.
  • Misalignment with business needs: If a solutions doesn't address a real problem, it's not going to get used.
  • Weak project management: Without proper oversight, projects blow through budgets and timelines without delivering value. Structure and discipline matter from day one.

In his seminar on designing human-centered data products, Brian O'Neill put it well: ask who gets a sleepless night if this problem isn't solved. Those are the problems worth working on. It's the question we bring to every client meeting!

 

What makes a good data product?

A good data product is more than a technical artifact. It's FAIR(ER):

  • Findable: Easily located by the users who need it.
  • Accessible: Available to authorized users without unnecessary barriers.
  • Interoperable: Able to work smoothly with other systems and data sources.
  • Reusable: Designed for use in multiple contexts or by different teams.
  • Evaluable: Its performance and impact can be measured.
  • Reproducible: The same conditions produce consistent results.

Together, these principles keep data products not just functional, but sustainable and valuable over time.

Beyond those properties, whether a data product is worth building comes down to three qualities that all good products share:

  • Desirable: It meets a genuine need among stakeholders.
  • Usable: It's intuitive and practical. People want to use it.
  • Feasible: It can be built and maintained efficiently, within the limits of time, budget, and legal requirements.

 

The data product pyramid: A structured way of looking at things

Data products take many forms, but they generally fall into three categories. What separates them is their purpose, their complexity, and how directly they support decisions or action. Think of them as building blocks that grow in sophistication and in the value stakeholders see as you move up the pyramid.

The data product pyramid: foundational, analytical, and smart products

So, let's go step-by-step through the pyramid:

 

1. Foundational products: Building blocks for reuse and scale

These are the datasets and services that make everything else possible. Foundational products don't deliver insights directly. They're what make reliable, scalable, and efficient data use possible across the organization.

Examples: Cleaned and curated datasets; standardized APIs or data pipelines that provide consistent access to key sources; master data services or semantic layers that keep business terms and metrics clearly defined.

Why they matter: Without a strong foundation, advanced use cases become brittle. Foundational products ensure consistency, data quality, and reusability, so teams can build without starting from scratch each time. They cut duplicated effort and build trust in the data landscape.

 

2. Analytical products: From data to insight

These products support internal decision-making by turning raw data into understandable, often visual formats. Business teams, analysts, and domain experts use them to monitor performance, spot trends, or investigate issues.

Examples: Interactive dashboards for marketing performance; self-service reporting tools that let teams explore KPIs and drill into specific areas.

Why they matter: Analytical products give teams timely, relevant insights without making them dig through raw data. Done well, they bring clarity, speed up decisions, and support more strategic thinking. But they only work when they're aligned with real business questions and backed by strong foundational data.

 

3. Smart products: Data-powered action and automation

Smart data products are where insight turns directly into action, often automatically. They embed data-driven intelligence into business processes, tools, or customer-facing systems.

Examples: Personalization engines that tailor content or recommendations in real time; predictive models that forecast customer churn or demand; optimization tools that adjust their output as inputs change.

Why they matter: Smart products directly make or shape decisions. Because they integrate directly into workflows, platforms, and user experiences, often in real time, technical, business, and legal stakeholders need to work closely together on feasibility, compliance, and effectiveness.

 

The data product lifecycle: From idea to impact

Building a data product is a journey:

  • Genesis: Explore the problem, gather requirements, and define what matters most.
  • Build: Develop a minimum viable product (MVP) and iterate with stakeholder feedback.
  • Production: Launch, maintain, and monitor the product in a real-world environment.
  • Retirement: Evaluate ongoing value. If a product no longer serves its purpose, retire it. Not every dashboard or dataset should live forever.

Managing this lifecycle well is what keeps data products delivering value and adapting as business needs change.

 

Our approach at FELD M

We combine expertise in data engineering, data science, and business intelligence to create data products that are:

  • User-centric: Designed with the end user in mind, for real usability and adoption.
  • Business-aligned: Built around specific business objectives and challenges.
  • Technically sound: Built on robust, scalable technologies.
  • Iteratively developed: Refined through continuous feedback and improvement.

We ground our work in design thinking and agile principles:

The Double Diamond approach and agile learning circles at FELD M

A larger version of this image lives on our data products page.

  • Double diamond approach: We explore the business problem deeply before jumping to solutions. That means challenging assumptions and asking the hard questions, so we're sure we're solving the right issue.
  • Agile learning circles: We work in short iterations, building prototypes and gathering feedback early and often. This keeps us aligned with our customers' needs and avoids costly missteps.
  • High standards, practical approach: We aim for lasting, high-quality outcomes. That means tailoring our work to each client's budget, timeline, and needs. It also means staying open to revisiting the core problem as we go.

 

Summary

For us, data products are about creating measurable business value by solving the right problems with the right solutions.

We bring structure and transparency to every engagement: clear objectives before we build, prototypes you can react to early, and a lifecycle that's managed rather than left to drift.

Got a data product that's stuck? Let's talk.

 

Further reading

Case studies

Related blog posts
You may also be interested in Password rotation for Adobe Analytics FTP/SFTP – What do I actually need to do? Read More
Back to Overview