From Data Projects to Data Products, Part 1: Why the Old Model Doesn’t Work
- Dave Findlay
- Oct 16
- 2 min read
Most data work is still run like a project.
You identify a need. You scope the effort. You assign people to deliver something. And then, when it’s done, you move on to the next thing.
But increasingly, this model is breaking down and there is growing distance between the business and the data team.
Because data is not a one-and-done initiative. It’s not something you “build and forget.” It’s an evolving asset and capability that needs to be maintained, improved, and adapted as business needs change.
In this two-part series, we’ll look at why the traditional data project model no longer works and how to start shifting toward a product mindset that’s better suited to today’s data-driven organizations.
The Trouble with Traditional Data Projects
Data projects tend to follow a waterfall mindset:
Define requirements
Build the pipeline or report
Deliver the output
Declare success
In theory, this sounds clean. But in practice, it often fails.
That’s because most data work:
Involves ambiguous and evolving requirements
Depends on upstream data sources that change over time
Requires feedback loops with users to be effective
Needs ongoing support and iteration to add value as business needs evolve
What starts as a “project” quickly becomes a permanent fixture. But since it wasn’t built or funded with longevity in mind, it begins to break down. The result is tech debt, poor user experience, and rising maintenance costs.
Introducing Data Products
Data products are created the same way as software products:
They serve a defined set of personas
They have a clear value proposition
They’re versioned, tested, and iterated
They’re owned by a team, not a one-time project group
A data product might consist of a series of pipelines, dashboards, or models, but it’s designed and packaged to be used, maintained, and improved over time, with benefit being delivered to a specific user group.
This shift mirrors what software teams have already embraced: durable, user-centered solutions require durable, user-centered teams.
Why Product Thinking Works Better
Moving to a product model offers several advantages:
Better alignment: Products are built to satisfy specific user needs (needs, not requirements), which means more relevant, useful outcomes.
Higher quality: Iteration leads to better design, fewer bugs, and more trusted results.
Sustainability: Ownership ensures that someone is responsible for keeping things working.
Strategic focus: Products are tied to business value and adoption, not just delivery deadlines.
This doesn’t mean we never run projects. But it means we stop pretending that all data work can be scoped, staffed, and delivered like a finite initiative. Instead, we invest in capabilities that grow over time.
In Part 2, we’ll look at what it takes to actually make this shift — from changing how teams are structured to how work is funded and prioritized.
At Fuse, we believe a great data strategy only matters if it leads to action.
