No Data Product Stands Alone

A workshop whiteboard comparing three investments: more variables, a shared patient identifier and a new dataset.

Why I stopped treating prioritisation as a scoring exercise

The hardest prioritisation meetings weren’t the ones with weak ideas. They were the ones where every proposal had a good case behind it.

For years, I thought my job was to decide which should come first and, like many product managers, I relied on frameworks such as RICE and WSJF to compare competing requests.

Don’t get me wrong: they remain useful tools, particularly when the work you’re comparing is largely independent. The frameworks weren’t the problem. I was asking them to solve a question they weren’t designed to solve.

Instead of comparing individual requests, I was really trying to work out where limited investment would have the greatest effect across the portfolio.

Once I saw it that way, the problem looked different.

The pattern

After a while, I noticed the same thing happening in planning meetings. Every backlog contained a list of perfectly sensible requests: another dataset to release, more variables, better documentation, improvements to data quality.

None of those ideas was wrong. In fact, most had a strong case, which made the decisions so difficult.

The discussion almost always focused on the request itself.

Which proposal would benefit the most researchers? Which delivered the greatest value? Which should receive the next investment?

They were all logical questions, and for a long time I didn’t see any reason to ask different ones.

What changed wasn’t a new framework. It was spending more time with researchers.

I stopped thinking about features and started thinking about research questions.

Researchers described the problems they were trying to solve, not necessarily the investment that would solve them. Sometimes another dataset was the answer. Just as often, the real obstacle was how easily existing data could be linked, understood or combined.

Looking through an economic lens

I began to notice that some investments created value far beyond the product they were made in.

I eventually realised an economic idea explained what I was seeing.

Some products are more valuable because of what they enable elsewhere. Economists call these complements. A printer without ink has little value. A games console without games is simply a piece of hardware. Neither creates its full value independently because each relies on something else.

The same can be true of data products.

The most valuable investment isn’t always the one that creates new value. Sometimes it’s the one that unlocks value that’s already there.

Looking at the portfolio through that lens changed the question I was asking.

Instead of deciding which proposal should come next, I started asking:

Where will the next investment make the biggest difference?

When the obvious choice isn’t the right one

One planning exercise made this particularly clear.

We had more than 150 data assets and funding to improve only around 30 that year.

Three proposals were competing for the next investment.

One would extend an existing clinical dataset with additional variables.

Another would introduce a shared patient identifier across multiple datasets, making them much easier to link.

The third would bring in a completely new external dataset.

On paper, the first proposal looked like the obvious choice. Researchers had asked for the additional variables, the scope was well understood, and the benefits were easy to explain.

But the more we talked to researchers, the clearer it became that the extra variables weren’t the real constraint.

They already had valuable datasets. They struggled to combine them.

Until they solved that problem, adding more information to one dataset would make only a marginal difference.

Everything changed once the datasets could be linked reliably.

The identifier didn’t just improve one product. It increased the usefulness of several datasets at once. And once researchers could combine those datasets, the additional variables became more valuable too.

The priorities changed, not because the first proposal had become a bad idea, but because the second created value across the portfolio.

That was when I realised an investment could create most of its value somewhere other than the product receiving it.

Shipping isn’t the expensive part

I had to rethink another assumption.

For a long time, I treated delivery as the biggest investment. Once a product was released to users, it was easy to think the hard part was over.

In reality, that’s when the long-term commitment begins.

Pipelines need maintaining. Documentation falls out of date. Governance changes. Data quality issues emerge. Researchers ask questions nobody anticipated when the product was designed.

A roadmap doesn’t just commit you to building something. It commits you to looking after it, often for much longer than anyone expects.

Two products may cost roughly the same to build and have completely different costs to own.

One might require years of support, documentation updates and maintenance. Another might need very little attention.

That changed prioritisation too.

Every decision to invest in one product wasn’t simply a choice about delivery. It was also a decision to take on its future cost, and to delay something else.

Opportunity cost had entered the roadmap whether we called it that or not.

The questions I kept coming back to

Eventually I realised the framework wasn’t where the most important decisions were being made.

Those decisions happened earlier, in conversations with researchers, engineers and subject matter experts.

By the time we started scoring proposals, we’d already uncovered most of the real trade-offs.

And the same three questions kept coming up.

Can we actually deliver this, or is there a dependency we need to solve first?

If we build it, where will most of the benefit appear: in the product itself, or across the wider portfolio?

And once the data asset is released, are we willing to own it for the next five years, not just the next five months?

Those questions didn’t give me the answer, but they usually made the real trade-off much easier to see.

Not every investment has the same purpose

Just as I thought I’d found a better way to think about prioritisation, another assumption started to unravel.

I had begun to see every decision as an investment problem, so it seemed reasonable to compare every proposal using the same criteria.

Working in healthcare and research showed me why that doesn’t always work.

Some investments improve products. Others remove constraints or increase the value of the wider portfolio. Those decisions suit economic thinking because they’re fundamentally about making the best use of scarce resources.

But some work exists for a different reason.

Supporting research into a rare disease, improving representation in datasets or enabling nationally important research may never produce the highest return if judged only by demand, adoption or portfolio value.

Their purpose isn’t simply to maximise product value.

It’s to fulfil the organisation’s broader mission.

That’s a different question from which framework to use.

It’s about deciding what you’re trying to optimise in the first place.

Looking back

What I eventually realised is that prioritisation is difficult precisely because most of the ideas are good.

RICE and WSJF still have a place. I still find them useful when comparing options within an area where the investment decision has already been made.

But they don’t answer the earlier question: where should we invest in the first place?

What they can’t tell you is where investment will have the greatest effect across a portfolio, or when return isn’t the point at all.

Not every investment is trying to maximise the same thing.

Pretend otherwise, and you’ll optimise your way into the wrong priorities, cleanly and confidently.

So the question I now ask isn’t:

What’s the best idea on the list?

It’s:

Where does the next pound of investment do the most good?

Sometimes that’s product value. Sometimes it’s public value.

And if your prioritisation framework can’t tell the difference, the problem probably isn’t the score.

It’s what you’re optimising for.

Comments

Leave a Reply

Discover more from Data with Purpose

Subscribe now to keep reading and get access to the full archive.

Continue reading