I've been serving as Product Owner on a European public-sector project — cross-border, the kind of work where EU rules and institutions are the environment you operate in — and it's been an education in a different kind of data work entirely. On a commercial build, governance and compliance often feel like friction: the constraints you route around to get to the value. On an EU public project, I've learned, the constraints aren't friction around the work. They are the work. And that reframing changed how I do the whole job.

A different centre of gravity

On a typical commercial data project, the centre of gravity is value delivery — build the thing that helps the business, and treat compliance as a boundary you stay inside while you do. The governance is real, but it's the fence, not the field.

On this project, the centre of gravity moved. Handling personal data under GDPR, in a public and cross-border context, with the transparency and accountability expectations that come with public money and public trust — that isn't the fence around the work. It's a huge part of the substance of it. The question stopped being "how do we deliver value while staying compliant" and became something more integrated: "how do we deliver value in a way that is fundamentally, demonstrably respectful of people's data rights — because that respect is itself a core part of what we're here to deliver." When you're handling citizens' data with public accountability, doing it rightly isn't a constraint on the mission. It's part of the mission.

That's a genuinely different posture, and it took me a while to stop treating the governance as an obstacle and start treating it as the point.

What GDPR actually asks of a Product Owner

As Product Owner, I sit between what the project wants to achieve and what the team builds, and GDPR reshapes that whole conversation. The regulation's principles stop being abstract legal text and become concrete product decisions I'm responsible for:

  • Purpose and data minimisation become backlog decisions. GDPR says you collect personal data for a specific, legitimate purpose and no more than you need. As PO, that means every "wouldn't it be useful to also capture..." has to pass a real test: do we have a legitimate purpose for this, or are we hoarding data because it might be handy? "It might be useful later" — the default instinct of every data project — is precisely the instinct GDPR asks you to discipline, and enforcing that discipline in the backlog is my job.
  • The rights of the individual become features, not afterthoughts. People whose data you hold have rights — to access it, to have it corrected, to have it erased. Under GDPR those aren't nice-to-haves bolted on at the end; they're requirements the product has to actually support, which means they live in the backlog as real work, prioritised like anything else. Building for the data subject's rights is building the product.
  • Transparency and accountability shape how you document, not just what you build. In a public, accountable context you have to be able to show what you did with data and why — the decisions, the justifications, the safeguards. That turns documentation and traceability from a chore into a first-class deliverable, because "we can demonstrate we handled this properly" is part of what the project owes.

Each of these is a place where a legal principle becomes a product decision that lands on the PO's desk. GDPR didn't make my job harder around the edges. It reshaped the middle of it.

The many-masters problem

There's a second thing that makes EU public-sector product ownership its own sport: the sheer multiplicity of stakeholders and the weight of their differing expectations. A commercial project usually has a reasonably clear line of who wants what and who decides. A cross-border public project has many masters — different national contexts, institutional stakeholders, public accountability, formal expectations about process and transparency — and reconciling them is a large part of the role.

This is where the Product Owner job becomes, once again, fundamentally about communication and translation — my recurring discovery, now in a higher-stakes setting. Standing between many stakeholders with different languages, priorities, and constraints, and finding the path that serves the mission while honouring the rules and keeping enough of everyone aligned to actually make progress — that's the daily work, and it's more diplomacy than it is backlog management. The technical delivery is almost the easy part. The hard part is the human and institutional negotiation around it.

On a commercial build, compliance is the fence you stay inside. On an EU public project, respecting people's data rights is the field you're playing on — and the Product Owner's job is less "maximise value within the rules" than "deliver value in a way that treats the rules, and the people they protect, as part of the value."

What it's teaching me

Two things are sticking, and I suspect they'll outlast this project. The first is a genuinely changed relationship with governance. I arrived, like a lot of engineers, half-treating compliance as bureaucracy — the tax you pay to do the real work. This project has taught me to see it as substance: that handling people's data respectfully and accountably is not a constraint on doing good data work, it's a defining feature of doing it well. That's a lesson I can feel reshaping how I'll approach governance everywhere, not just here.

The second is, predictably by now, that the role's real difficulty and real value are in the communication — the translation between many stakeholders, the negotiation between the mission and the rules, the making of a shared path where there were competing expectations. I keep discovering that whatever technical role I'm nominally in, the actual job is standing between people and making them understood. On an EU project, under GDPR, with public accountability, that's truer and higher-stakes than anywhere I've been. And it's confirmed something I only suspected: that the work I'm best suited to, and most drawn to, is exactly this — the human, communicative, translational heart of getting complex data work done rightly, among people who need to be brought along. The governance isn't in the way of that work. It's the deep end of it.