Data Products Need Funding. Not Projects.

Executive summary:

Accelerate value creation of your Data Product Strategy, with these 3 key principles:

• Data Products need continuous funding, not one-off project funding.
• Those who benefit should provide the funding, together.
• Data Product Owners need autonomy to align roadmaps with strategic priorities.

Your data product strategy is not failing because of your technology. It is not failing because of your talent. It is hitting a wall because you are trying to run a product organisation on a project budget. These two models are fundamentally incompatible.

It is easy to look the part by having a shiny new cloud platform. A polished data strategy deck. A handful of high-value data products identified. Maybe even a few people proudly carrying the title of Data Product Owner. On paper, you are a data-driven powerhouse with big data mesh ambitions.

But if the funding model hasn't changed, everything else is just window dressing.

Most organisations figure this out eighteen months too late, after the platform has been built, the Data Product Owners have been hired, and the backlog has mysteriously started looking like a list of project deliverables.

It is a pattern we at Datashift encounter frequently, especially in asset-heavy, capital-intensive industries (think utilities, infrastructure, and manufacturing) where the investment logic that built the core business is now being asked to accommodate something it was never designed for: data products

Why project funding works almost everywhere except data

Project-based funding exists for a reason. You define scope, secure budget approval, deliver the outcome, and close the initiative.

That model works perfectly well when the thing you are building has a clear endpoint. Expanding a production line. Rolling out smart meters across a region. Migrating an on-prem ERP system to the cloud.

Data products are the opposite. A dataset containing customer transactions has limited value on day one. But maintained consistently, connected to the right consumers, and actively managed over time, it becomes the foundation for pricing optimisation, churn prevention, and customer lifetime value modelling simultaneously.

Neglect it for two quarters and the risk is not that it becomes unused. The risk is that people continue using it without realising it is no longer reliable.

That is not an asset you build once and depreciate over time. It is an asset that either compounds in value through continuous investment or quietly deteriorates underneath critical business decisions.

You cannot build a garden on a construction timeline. And you cannot grow a data product on a project budget.

When the PMO becomes your de facto Data Strategist

Because every business initiative carves out its own slice of budget for “data”, the data roadmap slowly becomes shaped by active projects instead of long-term product strategy.

After a while, the backlog starts reading less like a product roadmap and more like a portfolio overview from the PMO.

Each epic neatly maps to whichever programme currently has funding approval. The team knows exactly which deliverables need to ship before the project closes because once the budget disappears, the work stops.

The work gets delivered. Pipelines get built. Dashboards go live. Your project stakeholders move on.

But the products themselves never really mature.

There is no continuity between initiatives, no long-term roadmap with product increments, no real ownership beyond the lifespan of the project. Every new sponsor brings a different priority, a different deadline, and the team changes direction again.

So instead of improving and extending existing products, organisations quietly end up rebuilding variations of the same thing over and over again.

The answer is not better project management. It is a different model entirely - one where data products are treated as persistent business assets with a named owner, a long-term roadmap, and accountability that survives the closure of any individual project.

The Data Product Owner: A Hero Without a Sword

You can assign the title of Data Product Owner to your best people, but without a shift in funding and governance, you have given them responsibility without the tools to exercise it. A genuine Data Product Owner does not manage a gantt chart of projects on behalf of whoever is paying.

Their job is to be a value architect. They make autonomous prioritisation decisions based on cross-domain value: business impact, reusability, strategic fit, total cost of ownership. They are accountable not to a single sponsor but to the value the product brings to the whole company. To do this, they need a product roadmap rather than a project plan. A roadmap acts as a living contract. It gives Finance & leadership the transparency they need while giving the data team the flexibility to pivot when business requirements change.

In practice, that means a Data Product Owner can look a business director in the eye and say:

« your request is valid, but it is not the highest value thing we can build right now for the organisation ».

And that decision needs to stick.

That requires a fundamentally different mandate than what most organisations are willing to give.

Ask yourself this: do my Data Product Owners have the authority to say no to a business domain that is partly funding the product? If not, you do not have a real product model and your Data Product Owners are at risk of being tossed around by stakeholders with conflicting priorities.

So, Who Pays for the Data Products?

The most common objection that we hear at this point is:

"If it’s not linked to a project, where does the money come from?"

That is the wrong question. But it is also a symptom of a very real dynamic.

Everybody wants a Customer 360 data product. No department wants to pay for it alone. So what happens? Nothing. Or worse - something. A department with enough budget and enough pain builds a partial version that serves their use case and nobody else's. The foundational work gets skipped because no single team can justify the full investment, even though the full investment would benefit ten teams simultaneously.

This is the free-rider problem applied to data infrastructure. And it has a predictable outcome: the most valuable, most cross-functional data products - the ones that would generate the most compounding value across the organisation - are exactly the ones that never get properly built.

Shared products require shared investment

There is a tipping point, though.

Once a shared data product reaches sufficient maturity - once it is reliable, documented, and actively consumed by multiple domains - the return on investment becomes undeniable.

We have seen this play out more than once at clients. Three different internal teams built their own customer segmentation logic because nobody funded the shared version. Each rebuild cost six months of engineering time. The shared product would have cost the same once - and served all three departments.

At some point, the cost of (re)building fragmented versions across departments starts to exceed the cost of funding the shared asset centrally. That is the conversation worth having, not a debate about which department owns the budget line.

Shared products need shared funding. That can take different forms:

• A central data platform budget combined with domain contributions
• Strategic programmes co-funding multiple shared products
• Portfolio-level investment models instead of isolated project budgets

The mechanics matter less than the principle: stop asking who pays for it. Start asking who benefits from it - and structure the funding accordingly.

Where to start

Do not try to redesign the entire operating model overnight.

Start with one product that already matters to multiple domains. Something people rely on today. Map who consumes it. Map who funds it.

If five teams depend on it but only one is paying for it, you have just identified your free-rider problem in concrete terms. That is not a data argument. That is a business case.

Use that gap to start a different conversation with finance and business leadership, not as a conversation about data strategy, but about duplicated investment, operational inefficiency, and the hidden cost of rebuilding the same capabilities every two years because the original project funding expired.

Because ultimately, that is the real question organisations need to answer: Are you funding long-lived data assets? Or are you repeatedly funding temporary deliverables and hoping they somehow behave like products afterward?

‍