Sony PlayStation
Product Owner · 2017–2021
Owning release quality and readiness for the PlayStation SDK.
Platform products fail differently.
The PlayStation SDK was not a single product. It was a collection of tightly integrated tools and libraries that game studios worldwide depended on to build and ship titles for PlayStation consoles. A failure in one component had downstream consequences across the entire ecosystem.
My primary responsibility was the PlayStation Raytracing graphics library — a core capability used by advanced graphics developers building AAA titles. The stakes were different from a typical software product: quality regressions didn't just frustrate users, they delayed game releases, damaged relationships with external studios, and carried significant reputational risk for the PlayStation platform.
Development was distributed across the UK and globally, with tight coupling between components and high expectations around stability.
Ownership without authority is still ownership.
My formal title was Senior QA Engineer. But the work required something closer to product ownership — defining what done meant, coordinating across teams with competing priorities, and making the call on whether a release was ready.
The bet I made early was that the most valuable thing I could do was create clarity. Ambiguous API behaviour, unclear acceptance criteria, and undefined failure modes were the root cause of most late-stage surprises. If I could eliminate that ambiguity upstream, the downstream work — testing, bug fixing, release coordination — would become more predictable.
That meant going beyond test execution. It meant influencing how requirements were written, how bugs were framed, and how release readiness was communicated to stakeholders who needed confidence, not caveats.
Clarity, coverage, coordination.
The work broke into three areas:
Test strategy and coverage
Defining validation plans and acceptance criteria for the raytracing library and related SDK components. Building automation frameworks to reduce manual regression effort and improve coverage reliability across releases. Owning API testing end to end.
Release coordination
Running daily scrum meetings as a coordination forum across the team. Serving as the primary liaison between QA, development, and external stakeholders. Providing release readiness inputs and risk assessments to program management. Preventing releases when validation was incomplete — and being willing to hold that line under pressure.
Documentation and developer experience
Writing consumer-facing documentation to reduce developer confusion around API behaviour and expected failure modes. Treating documentation as a product decision, not an afterthought. Built VR and mixed reality proof-of-concepts that explored new applications of PlayStation graphics technology beyond gaming.
Predictability as a product outcome.
Release confidence improved measurably. Faster turnaround on bug fixes came from clearer ownership and communication — developers knew exactly what was blocking release and why. Fewer late-stage surprises during integration meant teams could plan more accurately.
The broader shift was cultural: quality stopped being something that happened at the end of a sprint and became something that was designed in from the start. Acceptance criteria written at story level meant QA and development were aligned before a line of code was written.
What this experience gave me that I carry into every role since: platform products require coordination across many teams, not just feature delivery. Ownership often exists without formal authority, and influence must be earned through clarity and consistency. Release decisions become more conservative as brand risk increases — and that conservatism is the right call.