The System Worked. I Couldn’t Endorse the Experience.

October 20, 2026 · Micah Stroud
system worked experience didnt

At Sony PlayStation, I reviewed an early version of what would become PS VR2.

Wearing it made me dizzy. The UI we were testing felt much like the TV version. The overall experience felt clunky and uncomfortable.

My sign-off was required for an area of the product system. Technically, that part worked.

But I couldn’t separate that technical success from the experience customers would have around it.

I shared what I experienced and my assessment with the team that owned the product. They weren’t happy with the feedback.

I was told we had to accept the timing and limitations so the product could ship on schedule.

I understood those constraints. I still thought the problems were serious enough to challenge them. I pushed for more time and iteration before signing off.

I was nudged into giving the approval because the part of the system I was responsible for technically worked.

After that feedback, the team stopped talking and working with me. I had become an obstacle to go around instead of a partner to work with.

When the product shipped, I saw customers raising concerns that echoed what I had experienced.

There was no satisfaction in that. The feedback had been available internally, while there was still an opportunity to discuss it.

By the time I got involved, decisions had been made and promises had been shared that the team treated as fixed. My review could confirm whether my area worked. Challenging the larger experience put me outside the boundaries of the conversation.

That’s the problem I keep coming back to.

A product can pass through a series of legitimate approvals, each covering a part that works, while the experience connecting those parts remains uncomfortable.

My signature answered a narrow question. My concerns raised a larger one. We had a process for collecting the signature. We didn’t find an effective way to act on the concerns.

I would still raise them.

But I’d want the distinction made explicit: what does this approval establish, what remains unresolved, and who owns the decision to ship with those issues?

When every team has signed off on its part, who signs off on the experience the customer actually gets?