Read Time: 17 minutes
You’re halfway through your first coffee on Monday morning when the email lands.
The COO has a new priority for the data team. By 9.30, you’re in a planning meeting being asked when you can start.
You ask the obvious question: what should come off the roadmap to make room?
“It’s all priority,” apparently. Nothing can be taken off the roadmap or pushed to a later date. The platform migration, regulatory work and VP dashboard are all still urgent.
Someone’s got a weird understanding of the word “priority”...
In classic fashion, when everything is labelled a priority, nothing actually is prioritised.
I hear the same tension from data leaders all the time–there is no good answer…
A direct “no” can piss off the executive asking and make you look difficult or unable to deliver.
Another “yes” spreads the same people across more work. Everything takes longer, mistakes creep in and the same stakeholders ask why the data team is so slow.
Many organisations have adopted agile ceremonies without the trade-offs that make agile work. If a new priority arrives and nothing comes off the roadmap, the team isn’t agile. It’s overloaded.
The trick isn’t to say no more forcefully. It’s to make the cost of yes visible: “We can build that dashboard. It means pausing the demand forecasting model, which is projected to save £1.2m this year. Do you want to make that swap?”
That’s saying no without saying no. You’re helping stakeholders decide what happens now, what waits and what the business chooses not to do.
And look, the new idea may be good. The question is whether it’s a better use of time and money than the work it would displace. That’s value-driven prioritisation: making trade-offs visible so leadership can make an informed choice.
Doing this type of analysis was always important, but companies just didn’t bother with it. It was simply easier to fly under the radar when capital was cheap and growth often mattered more than profitability. The zero-interest-rate policy (ZIRP) era is over. Profitability and value are back at the centre.
After years of spending on cloud platforms, data teams, transformation programmes and now AI pilots, boards and C-suites are asking a fair, if exasperated, question: what have we actually got back?
AI makes this worse. Prototypes take days (even hours) to build, creating more plausible projects without creating more delivery or change capacity.
The stakes are personal as well as operational. If delivery keeps slowing while the function still looks expensive, budget and headcount will come under pressure. It affects your longer-term trajectory too: whether you are trusted with bigger decisions or left managing an expensive service desk.
And look, this isn’t an argument against technology or a claim that the data team should own the benefit. Technical judgement is essential. It’s just that it needs to sit alongside a method for turning technology requests into business problems, and then into comparable investment choices.
Because in the end, everything comes down to a ‘show me the money’ mentality for executives!
Yet despite that perspective, stakeholders rarely arrive with a neatly defined business problem. They arrive with a request - “can you pull me some data on X?” - or a solution - “we should be recommending products to customers, with AI”. First get underneath it: what is happening in the business, for whom, and what should change? Until you can describe the problem without naming the technology, you don’t have a use case.
(Scoping out the use case is a whole different article. It just so happens that Dylan wrote about this last week.)
Even then, you have only established that the idea is sensible. It may still be too small, too expensive or less valuable than something else. That value pressure test is where data and AI teams are still weak.
Over more than a decade of client and in-house delivery, I’ve seen both versions. Here are two of them.
At a previous employer, our global data and analytics centre of excellence worked like an internal consultancy. Business units brought us data work; we scoped, staffed and delivered it.
Too often, a senior conversation became weeks of proposal work before we discovered the project was a dead end. Or worse, after we had already completed an initial phase.
So when one business unit arrived with well-scoped projects, defined problems and a business case for each, it felt different. Better still, the work meant more headcount and budget for our team.
…They pulled the plug a few months in.
The business case, it turned out, had been assembled quickly and nobody had pressure-tested it. A few months insomeone from the BU side revisited the maths. The work would cost more to build and run than the benefit it could return.
This cost everyone time and money. The business unit was cross-charged for the work we had already done. It cost us as well: we had hired contractors for the project, and our permanent team had spent months on it rather than going after other work that could actually have added value. At best, the cross-charge helped us break even, but the opportunity cost remained.
And none of this required sophisticated analysis. It was back-of-the-envelope arithmetic that they had not done, and that we, just as damningly, had not challenged them to do.
It simply came down to the fact that nobody had checked whether it was worth the money.
And, weirdly, stopping after a few months was the best possible outcome. Leaders often fall for the sunk-cost fallacy and keep going. The more dangerous result would have looked like success: something that worked, was used and delivered a benefit, but still cost more than it returned. We would have spent far more money reaching an ROI-negative outcome.
Killing a weak project early is good governance. Successfully delivering an ROI-negative one is still value destruction (despite how nicely it is framed on the person’s CV…).
Years later, I worked with a multi-billion-pound consumer business whose CFO asked the question every data leader now gets asked: “What should we do with AI?”
First we had to reframe it. “What should we do with AI?” is a solution looking for problems; the useful question is “which business problems are worth solving, and for each one, is the right intervention BI, analytics, ML, an LLM, or a process change that needs no technology at all?” No amount of value sizing rescues a technology in search of a problem. But that only got us to a set of sensible use cases. It didn’t tell us where to put the money.
Over roughly four weeks, working with the CFO, the finance director and business unit heads, we built a portfolio view: 24 candidate use cases, each expressed as a business problem. In the end, 11 survived first contact on feasibility and data readiness, and we recommended 4 for immediate focus/ implementation. Each had a one-page investment case:
Rough five-year value
Total expected cost
Feasibility
Blockers
How it related to transformation work already in flight
And crucially, the explicit list of things the use case would not do (especially important in this world of “AI can do everything…”)
Most of the seven feasible options we did not recommend for immediate focus were still expected to be ROI-positive. They missed the cut because their expected return was lower once dependencies and timing were taken into account, or because they conflicted with strategic initiatives already under way. They were not bad ideas, but were weaker choices for the money and would have detracted from the other builds.
Another important difference from the failed case: the assumptions were validated and corroborated by the data team, the business owners, and Finance. Each target had a named business sponsor who was prepared to be held accountable for it. They were still estimates, obviously, but they were not figures any one team had invented on its own.
While the engagement started with the CFO asking about Generative AI, in the end, three of the four initiatives we recommended had no LLM component at all. They were more familiar data and analytics work: marketing-mix modelling, predictive support for capital-investment decisions and demand forecasting. The fourth was an internal LLM assistant.
That was the point of the value lens. It helped us prioritise the strongest opportunities and gave us a defensible way to say no to a long list of plausible GenAI proofs of concept that seemed sexy but were unlikely to be good uses of time and money.
Comparing the two scenarios, the failed initiative had the sort of bullshit business case that is only slightly more sophisticated than sticking your finger in the air: nobody had verified the assumptions, properly signed off on them, or expected to be held accountable for the result. The better-governed portfolio still used rough arithmetic, but every assumption was visible, challengeable and owned.
The problem with business cases is that sometimes you get a case of corporate bystander effect: everybody assumes somebody else has checked the maths.
For data teams, that often means being asked only how long the work will take and how much it will cost, while assuming somebody else owns the value side. Sometimes they do, sometimes they don’t, and sometimes they do, but it’s wrong. In the latter case, the data team may be the only ones able to challenge a (technically-rooted) assumption that makes no sense.
There is a question I ask at the start of almost every project, or when I get brought into one halfway through: “How are we measuring success?” Often, the first answer is some version of “that is a great question”, which is usually a polite way of saying, “I have no idea, but I agree with the implication that we need an answer.” Sometimes being the first person to ask is all it takes to get the wheels moving.
This does not mean a business case needs to be perfect, or that you should spend longer researching it than it would take to do the work. You will make assumptions with incomplete information and some of them will be wrong. That is fine.
The important thing is that everyone involved shares the same definition of measurable success, can see the assumptions and knows who owns finding out whether any of it happened.
Before getting into any formula, I should be clear that making an outcome measurable does not automatically make it financially valuable.
“Improve forecast accuracy by 8%” is a measurement target. It means nothing to a CFO until you can show what changes in the business—perhaps less waste, fewer stockouts or less working capital tied up in inventory—and who will change the ordering process to make that happen.
At a high level, the financial part of the benefit has to feed into revenue, cost or risk. When the benefit is revenue, compare incremental contribution after the costs of serving it, not top-line sales. Here is the cheat sheet I use:
Risk does not always need to be forced into a precise financial number. Sometimes safety incidents, regulatory breaches, outage time, or another direct indicator is the more honest measure (though those can also sometimes be quantified).
Avoided future costs are easy to miss because they can look insignificant in today’s accounts. Perhaps your cloud-storage bill is small because you only started collecting product telemetry recently, but the rollout plan means it will be costing you five figures per month within 12 months. Optimizing it now may barely move this quarter’s cost line; it can still prevent a very real cost that is already heading towards you.
Most teams stop at the metric, or at the operational change it is meant to produce. To turn that into an investment case, keep tracing:
A named business owner should validate the assumptions and commit to making the operational change happen. If a link is missing, or nobody is prepared to own the change, you have a metric or a value hypothesis, not yet an investment case. Put the expected benefit beside the full cost before deciding whether the work merits funding.
Then capture the baseline before you build. Agree on the metric, source and period; instrument it if it does not exist; or name who will collect it manually, whether through a system export, survey or end-user interviews.
This is not a GenAI-specific problem. Saved time is not automatically money: it creates business value only when somebody commits to putting that released capacity somewhere.
…Unfortunately, saved time is often the biggest benefit people refer to.
Given a CFO will challenge a spreadsheet that multiplies hours by salary and calls the result money, use this approach to quantify realised capacity:
The non-negotiable rule is that you cannot count the same hour twice.
If a support team uses £1m of realized capacity to spend more time with customers and that reduces churn by £2m, the value is the £2m churn effect. You do not also claim £1m of labour saving unless £1m has actually come out of the P&L or a credible future hiring plan.
The work can create several kinds of value, but every saved hour needs one agreed destination in the model.
“But we can’t know the value before we build it” is the objection I hear most, and it is half right.
Of course you cannot know it. The question is whether you can get close enough—enve just to the right number of digits—to make a better choice than you would have made with no estimate at all.
The arithmetic is not complicated. As a first-pass screen, use the same agreed time horizon to estimate the incremental financial value if the initiative works and the full cost of building, implementing, changing the surrounding process and running it. Then calculate (value - cost) / cost.
That tells you whether something appears to pay for itself. It does not tell you whether it should beat the other ideas fighting for the same budget. For that, you need to know whether it is a better use than the alternatives–and what gets delayed or dropped if it goes ahead. What makes that comparison work in practice is a handful of habits:
Start from the business owner’s assumptions - You are not the expert here. The value case is built with the stakeholder, from numbers they can put their name to. My favourite shortcut is asking, in effect, “can I copy your homework?”—if a business team has ever justified headcount or budget for this problem, the value logic already exists. Borrow it, then pressure-test it.
Start with a “Shitty First Draft” - Stakeholders often will not fill in a blank spreadsheet. Give them something wrong to correct: “I assumed 500 support requests a day, two minutes each, with 60% simple enough to automate.” They will fix your numbers faster than they will invent the model themselves. Remember, this is a provisional range and corrections are the start of validation, not the end. Co-ownership comes when the stakeholder confirms the assumptions and puts their name to the range, with Finance corroborating material cases.
Do not turn the portfolio into an algorithm - This approach is an art and a science; the prioritisation spreadsheet gives everybody the same evidence to argue about; it does not make the decision. Use cost, value and confidence to organise the conversation, not to pretend that an initiative scoring 52 automatically beats one scoring 48.
Keep value and confidence separate - A £5m estimate built on tested assumptions is not the same as £5m built on optimism. Keep the value visible, add a simple green, amber or red view of the evidence behind it, use weighted values, and ask whose assumptions are stronger.
Use the gaps to narrow the debate - If one initiative is two orders of magnitude more valuable than another, the gap may settle most of the argument. When candidates are close, strategy, timing and judgement take over.
Marketing teams already work this way. Several channels may be ROI-positive, but budgets are finite so they put the money where they expect it to work hardest. The analogy is only about scarcity: data initiatives are lumpier and more dependent, so the portfolio cannot be optimised one dollar at a time.
Use lanes, not one giant ranking - Treat mandatory and keep-the-lights-on work as constraints; tie shared foundations to the downstream value or risk they unlock; cap experiments at the cost of buying the next piece of evidence; and compare discretionary investments on value. Deliberately balance small, certain wins with larger, less certain bets. The portfolio owner should record any leadership override: why it was made, who approved it and what gets displaced.
When candidates are close, context can decide. A highly ranked customer-facing initiative may need to wait until an in-flight rebrand is finished. Surfacing that information is part of the decision, not an exception to it.
The person backing a lower-priority option must then explain what outweighs the visible difference and what should be displaced. That is how the data team says no without being obstructive: it points to executive-approved trade-offs and asks the business to choose.
Check the foundations before you promise the value - This is one of the biggest oversights most teams have because missing foundations change the maths. If the use case needs data, process or ownership work first, include that cost and delay. Sometimes it drops down the list; sometimes the value is large enough to pay for the foundational work too. That is why I often pair discovery with a maturity assessment: one finds the opportunities, the other shows where the roadmap has to start before the organisation can realise them.
To see how that works in practice, here is a deliberately simplified, hypothetical comparison over a common three-year horizon:
Demand forecasting model: £3m incremental contribution; £600k direct delivery and running cost; amber confidence; depends on reliable inventory data.
Inventory-data foundation: £400k full cost; green confidence in scope; no honest standalone ROI; unlocks the forecasting model and reduces reconciliation risk; needs the same two data engineers.
Decision: treat them as one linked investment with a £1m combined cost. Fund the foundation first, move the model back one quarter and record that delay rather than pretending both can start now.
The foundation does not need an invented standalone benefit. Its cost and delay belong inside the higher-value use case it enables.
None of this is going to produce finance-grade numbers at the start, and it isn’t meant to. You are trying to make the assumptions, owners and trade-offs visible enough for a CFO to decide where the next dollar goes and where it does not. Once you can do that, you stop being an order-taker who estimates delivery cost and start becoming a partner in deciding what is worth doing at all.
This depends on your role in the data team.
A CDO or Head of Data can change how the whole portfolio gets funded. A manager or product lead can change how individual initiatives are shaped and compared. An individual contributor may not control either of those things, but can still be the person who asks the question everybody else has avoided.
Start at a portfolio level. You can begin with three operating changes, without launching a year-long transformation programme:
Add a funding gate after discovery - A request can enter discovery before its value is known. It does not enter funded delivery without a rough value hypothesis, total expected cost, a confidence rating and supporting evidence, a named business owner and a named audience who will actually use the result. “We don’t know what it is worth yet” is an acceptable answer but it means the work is not ready for delivery.
Make prioritisation comparative - Put every candidate initiative in the same portfolio view: value, total cost, evidence, readiness, strategic fit, timing, owner and recommendation. The format matters less than making the trade-offs visible.
Recheck the economics at every checkpoint - The assumptions were rough on purpose, so revisit them as you learn. Descoping or killing an initiative whose value case has collapsed is the system working, not failing.
You may not control the whole investment portfolio, but you do control the quality of the choice being put in front of the people above you. For each initiative, ask what measurable outcome changes, which financial driver that affects, who owns capturing it, what the full cost is and what valuable work will wait if this goes ahead. Then show the trade-off rather than presenting the initiative in isolation. This is saying no without saying no at the level where most work actually gets shaped.
During a training engagement with a Fortune 50 client, one data product manager used this approach to avoid roughly six months of engineering work, worth around $200,000.
The team was rolling the same product out country by country, with each market requiring local data integration and custom development. Before the next rollout, the product manager asked: “Who will use this feature here, and what will they do with it?”
The local operating model barely used the underlying process. Perhaps a handful of people would look at the feature. He proposed removing it from scope, and the business agreed.
That singular question avoided roughly six months of engineering work—worth $200,000 in contractor fees—and brought the next valuable market forward by six months. No CDO mandate or company-wide process prompted it.
One data product manager simply challenged an inherited assumption before the team built against it.
There are two reasons to care even if none of this is formally in your job description. First, this is the skill set you need if you want to move into more senior roles. Second, you are usually the person who suffers most when “no” is not in the data team’s vocabulary: the context-switching, rushed work, mistakes and impossible delivery dates land on you.
If you are in the meeting, ask the questions:
“How will we measure success?”
“Who will use this?”
“What happens if we do not build it?”
“What should we pause to make room?”
Frame it around delivery risk and the outcome, not as a challenge to someone’s authority. If the room is not safe for a direct question, raise it with your manager or product lead afterwards.
Mandate can be an output of working this way, but only when leaders value the challenge and make trade-offs explicit. You do not get trusted with more strategic work only because your models are good. You build that trust by telling the truth about value, one ticket and one awkward-but-useful question at a time.
There is a more selfish career point within this whole article too.
Let’s say you eventually decide you want to leave for an organisation that is more business-focused and genuinely value-driven. You are not going to make that move with a CV whose entire story is, “I acted as an order-taker and shipped technical solutions whether or not they solved a business problem.” You need examples of the work you challenged, the waste you prevented, the choices you improved and the value you helped create or measure. You can start building those examples before your organisation gives you the perfect mandate.
If your organisation works nothing like this, you will not fix the culture in a quarter. You may also hit a natural ceiling in what one team can change. Start smaller: ask how success will be measured, put a rough estimate in front of the stakeholder instead of waiting for them to fill in a blank spreadsheet, and show what a new priority would displace. Make one avoided piece of work visible. Each of those steps makes the next one easier.
A positive ROI tells you an idea may be worth doing. It does not tell you whether it is the best use of the next dollar or the next six months. Rough numbers, agreed early and compared openly, let you say no to ROI-positive work because something better exists—and give the business a reason to trust you with the next, bigger decision.
Nick Zervoudis is the founder of Value from Data & AI. Drawing on more than a decade of client and in-house delivery, he helps organisations identify, prioritise and measure the value of data and AI investments through consulting and practical team-training programmes. He also runs a free community for data and product professionals who want to work in a more value-driven, product-led way. Follow him on LinkedIn or subscribe on Substack. To discuss portfolio discovery, value mapping or team training, get in touch.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.