Most data teams do not have a prioritization problem. They have a criteria problem. Initiatives get selected because they are on the strategy document from January, because a senior stakeholder pushed hard in a meeting, or because the team is excited about the technical challenge. None of these criteria answer the question a CEO or CFO actually needs answered: which investment will return the most value relative to what it costs?
There is a way to answer that question with numbers rather than politics.
Why the current process produces the wrong answer
The standard approach to data initiative prioritization is some version of a backlog grooming session: stakeholders submit requests, the team scores them on impact and feasibility, and the highest scores win. The problem is that both dimensions are estimated, and both estimates are optimistic.
Impact is usually measured as "how much value could this create?" which is a forward-looking projection with no baseline. If the marketing attribution model gets rebuilt, how much better will decisions get? Nobody knows, so everyone rounds up.
Feasibility is measured as technical complexity, which misses the ongoing cost. Building a product takes weeks. Maintaining it takes years. The build cost is visible; the maintenance cost is invisible in the scoring model. So the team picks initiatives that look cheap to build and expensive to own.
The result is a portfolio that grows in size and cost every quarter, with no mechanism to ever make it smaller.
A different set of questions
Instead of asking "what is the value of this initiative?" and "how hard is it to build?", there are two questions that produce better decisions.
First: how much organizational time is this capability going to free?
If the marketing team is spending four to six hours per day on manual campaign data work, building reports, quality-checking numbers, reconciling discrepancies between sources, and a capability exists that can automate 90% of that, the value is concrete. It is not a projection. It is a current cost that will be recovered. Multiply the hours per week by the number of people and the fully-loaded cost per hour, and you have a number that survives a budget meeting.
This is a different conversation than "the marketing attribution model will improve campaign performance." One is speculation; the other is a cost the organization is already paying.
Second: what is this capability going to add to the team's ongoing maintenance burden?
Every product a data team ships creates a permanent obligation. Pipelines break. Schemas change. Business needs evolve. Users need support. A product that scores high on the first question, saves significant time for the business, can still be the wrong choice if the team is already at capacity maintaining what it has built.
The question is not just "what does this save?" but "can we afford what this will cost to keep running, given everything else we are already running?"
How this changes the decision
When these two filters are applied to competing initiatives, the ranking almost always looks different from the stakeholder-weighted backlog.
Initiatives that score well on business time savings but add low maintenance load move to the top. These are typically capabilities that simplify something that is currently messy, replacing a workaround with a clean product, automating a manual step that exists because of a gap in the current infrastructure.
Initiatives that score high on stakeholder excitement but are ambiguous on time savings and high on maintenance load move to the bottom, or to an exploratory phase where the first question to answer is whether the projected savings are real before significant investment is made.
Initiatives that would push the team's maintenance capacity beyond what they can sustainably support do not get approved regardless of business value, because a team operating beyond capacity delivers neither the new initiative nor the existing portfolio reliably.
The capability versus initiative distinction
There is one more shift worth making in how initiatives are framed. Most data strategies list initiatives: build a new attribution model, create a self-service analytics layer, build a product performance dashboard. These are outputs. They describe what gets built.
Capabilities describe what becomes possible. Steer 90% of marketing campaigns automatically. Let product managers identify conversion bottlenecks without an analyst. Give finance a single number for customer acquisition cost that everyone trusts.
The difference matters because capabilities are measurable against the two questions above, and initiatives are not. You cannot easily calculate how much time a "new attribution model" will free. You can calculate how much time per week the marketing team currently spends building manual attribution reports.
Starting from the capability, what needs to become possible, and what is it costing the organization that it is not possible today, produces the business time savings number that makes the prioritization decision defensible.
Making the trade-off explicit
Every initiative that gets added to the data team's workload is a choice to not add something else, or to keep something existing that may no longer deserve the maintenance cost.
Most organizations never make this trade-off explicit. The portfolio grows. The team gets stretched. New initiatives get added without anything being removed. And eventually the team is spending most of its time maintaining products that generate a fraction of the value they were built to deliver, with no capacity left for the initiatives that would actually move the business.
The two-filter prioritization process only works if it is also paired with the discipline to sunset products that no longer earn their maintenance cost. That is a harder conversation. But it is the same conversation: what is this costing us, and what is it returning? If the answer to the first question is higher than the second, the decision makes itself.
Starting the conversation
If your next data initiative has not been evaluated against these two questions, what does it save in business time, and what does it add to the maintenance burden, it is worth running that analysis before the build begins.
In 30 minutes, we can run those numbers for the two or three initiatives currently at the top of your roadmap and see whether the current priority order holds. Book that conversation here.