Leonardo Perkunic Case study · EN

Product Owner · Judgment · Cross-functional · Outcome

A stalled rollout, and the question that moved it

Real work at ViewAR (AR indoor navigation). The enterprise customer is referred to as a global beverage manufacturer for confidentiality. My role: Product Owner, full product responsibility.

00 · Available in English only (nur auf Englisch verfügbar)

01Context

ViewAR builds augmented-reality indoor navigation: you hold up your phone and it guides you through a large space turn by turn, on top of a digital twin of the building. The customer wanted to run it in live production, not a pilot. Their requirement was hard and specific: navigation accurate to within 10 centimeters, exactly what we advertised.

02The problem

They tested on their production floor and kept reporting the same thing: the accuracy wasn't there. Engineering investigated and couldn't reproduce the error on our side. Their read was that the fault sat in the initial scan, the Matterport capture we build the digital twin from, not in our software.

So it stalled. Sales and CS said engineering had to fix it. Engineering said the other two had to deliver something first. It went back and forth for nearly three months with no resolution. There was a Head of Product at the time, before me and for about a month into it, whose stance was: sales and CS owe us input first, until then we do nothing.

03A different question

Everyone was arguing the same one: whose fault is this, and who owes what first.

The standoff wasn't really about the bug. It was about the boundary between the teams. Each side was defending its edge, not us, them first, and as long as that was the question nobody was going to get to the truth. I stopped asking who owed whom and asked what it would actually take to fix it.

04Going to see it

So I drove to the customer and walked onto the production floor myself. The first thing it settled: the bug was real. That had been heavily disputed internally, and seeing it live ended the argument. Then I could watch how it actually behaved in their space, not in a debugging session back at the office.

05What it actually was: both sides

The honest answer was that both sides were right, and that is exactly what the standoff had hidden.

Neither team could see this alone, because each had already decided it was the other's problem. The scan fix wasn't enough by itself, and neither was the engineering fix. It took both.

06Outcome

Back at the office I drove it until it worked: the scan corrected so the adjacent captures shared one height reference, the navigation bug fixed. Both fixes had to land, and they did.

10 cm

navigation accuracy restored in live production, the requirement met and one of our core sales claims kept.

Live

the rollout went into the customer's production environment, unblocked after nearly three months of standoff.

This wasn't a side project. We needed this deal to make our ARR target realistic at all, which is what made a months-long standoff on it so costly.

07Where I was slow, and what I take from it

I didn't come to this clear-headed. Early on I let the Head of Product's framing pull me in, and for a while I bought the silo view myself: us versus them, they owe us first. It took me time to get free of it and to see how critical the situation actually was. Once I was properly onboarded and had the whole picture, the call was obvious: we solve this or it breaks.

That's the part I keep. The silo framing is contagious, and I caught it before I broke out of it. When a cross-functional problem stalls on whose fault it is, the framing itself is the trap, and the fastest way out is first-hand ground truth. Positions hold up fine in a meeting room. They don't survive contact with what you can see on the floor.