I've just passed the Professional Scrum Product Owner exam — PSPO — which means I am now, officially and on paper, a certified Product Owner. And I want to write about it honestly, because it's a slightly different kind of certification from the technical ones I've been collecting, and it's taught me something specific about the gap between knowing about a role and being able to do it. The title of this post is the whole point: passing PSPO makes you a Product Owner on paper, and paper is a long way from the room.

Why a data engineer is studying product ownership

First, the honest "why," because it's a bit of a swerve from my recent trajectory. I've spent this era deep in the technical — Azure, IoT, streaming, the engineering of data platforms. Product ownership is a different discipline entirely: it's about deciding what to build and why, representing the people who'll use a thing, owning the priorities, standing in the space between the stakeholders who want things and the team who builds them.

And I've realised, doing this work, that the technical questions are increasingly not the ones that decide whether a project succeeds. The projects that go wrong rarely go wrong because the engineering was too hard. They go wrong because the wrong thing got built, or the priorities were muddled, or nobody was genuinely representing the people the thing was for. That's Product Owner territory, and I've found myself drawn toward it — partly because it's where the real leverage is, and partly, I suspect, because it's fundamentally about communication and translation between people, which is where I keep discovering my actual centre of gravity lies.

What the exam actually tests

PSPO, to its credit, is a well-designed exam, and studying for it was genuinely worthwhile as a way to systematise how I think about building the right thing. It tests real understanding of the Product Owner's role in Scrum — value, prioritisation, the backlog as a living expression of what matters, the discipline of maximising the value a team delivers rather than just the volume of it. It rewards understanding the principles over memorising the ceremonies, which is exactly right, because the ceremonies without the principles are cargo-cult Scrum.

So I don't want to be dismissive of it. As a forcing function to properly learn the frame — to move from "I've been near Scrum" to "I understand what a Product Owner is actually for" — it did its job, and I think about value and prioritisation more clearly for having done it.

The gap the certificate can't close

But here's the thing, and it's the reason for the title. The Product Owner role, more than almost any technical one, is made of things an exam fundamentally cannot test.

  • It's about judgement under real ambiguity. The hard part of prioritisation isn't knowing that you should prioritise by value — the exam covers that. It's making the actual call when two important things compete, the information is incomplete, and real people will be disappointed either way. No multiple-choice question reaches that.
  • It's about standing your ground with stakeholders. A Product Owner has to say "no" and "not yet" to people who outrank them and want their thing first. That's a matter of nerve, relationships, and credibility earned over time — and there is no way to certify whether you can actually hold the line in a tense room.
  • It's about representing users you have to genuinely understand. The role is only as good as your real grasp of the people the product is for, and that comes from listening, contact, and empathy, not from a syllabus. The exam can check you know you should represent users. It cannot check whether you actually understand any.

So PSPO gave me the vocabulary and the frame, and I value it. What it couldn't give me — what nothing but doing the role can — is the judgement, the nerve, and the earned understanding of real people that separate someone who can describe product ownership from someone who can do it. I have the first. The second is ahead of me.

A technical certification proves you can do a thing under exam conditions, and exam conditions aren't wildly unlike real conditions. A role certification proves you understand the idea of a role — and the role itself lives almost entirely in the human judgement the exam had to leave out.

Where this leaves me

I'm genuinely glad I did it, with clear eyes about what it is. I'm a Product Owner on paper — I understand the discipline, I can speak its language, I've internalised what the role is for. And I'm under no illusion that this makes me a good one, because being a good one is a practice, learned in real rooms with real stakeholders and real users and real consequences, none of which fit in an exam.

If anything, the honest gap between the certificate and the capability is motivating. It tells me exactly where the real learning is: not in more study, but in doing the role, badly at first, and getting better through the specific, unteachable experience of standing in that space between what people want and what a team can build. The paper is a starting line, not a finish. But it's a starting line I'm quietly excited to be standing at — because the direction it points, toward the human and communicative heart of building the right things, feels a lot like where I've been heading all along.