For a stretch recently I stepped in as interim Product Owner for a data-stores team — six weeks holding the backlog, running the ceremonies, standing between the people who wanted things and the people who built them. I said yes partly out of curiosity: I'd been heads-down in ETL for months, and here was a chance to see the work from the other side of the table. What I learned in those six weeks reshaped how I think about my own career, so it's worth writing down.
The surprise: the technical part was the easy part
I'd assumed my main challenge would be keeping up with the technical detail — the pipelines, the architecture debates, the depth. It wasn't. Because I'd spent months in the guts of this kind of work, I could follow the engineering conversations fine, and knowing the work well enough to earn the team's respect turned out to be table stakes, not the job.
The actual job was translation. And it was harder, and more constant, than any technical problem in the sprint.
What a data Product Owner actually does all day
Stripped down, the role sat in the gap between two groups who genuinely struggle to hear each other:
- On one side, stakeholders who know what they want in business terms — "we need to be able to report on X by region" — and neither know nor should have to know what that costs in engineering.
- On the other, engineers who know exactly what's feasible, what's a nightmare, and what hidden dependency will turn a "small" request into three weeks — and who often can't, or don't, express that in terms a business stakeholder can weigh.
My whole day was carrying meaning across that gap without dropping it. Turning a vague business wish into something an engineer could actually build. Turning an engineer's "that's technically expensive because of the way the source system works" into a trade-off a stakeholder could make a real decision about. When that translation works, everyone thinks the project is just going smoothly. When it fails, you get the classic disaster: a team builds exactly what was asked for and it's not remotely what was needed, and both sides blame each other, and both are right.
A data team rarely fails because the engineering is too hard. It fails because a want got garbled on its way to becoming a build.
Why this landed so hard for me
Here's the personal bit. I came into data from corporate communication, and for a while I'd half-treated that background as a quirky origin story — interesting, not central. Six weeks as a Product Owner made it central.
Because translation is communication, done in a high-stakes technical setting. The skills that mattered most weren't the ones I'd been grinding on in the evenings. They were: asking the question that surfaces what someone actually needs versus what they first asked for; explaining a technical constraint so a non-technical person can genuinely weigh it rather than just accept it; noticing when two people are using the same word to mean different things and stopping to fix it before it becomes a built-in misunderstanding. That's my old field, wearing a new hat.
The technique that surfaced the gap
If there's one practical thing I took from the role, it's a way of running backlog refinement that drags the translation gap into the open before it becomes built code.
The move is embarrassingly simple: for anything non-trivial, I made the engineer and the stakeholder describe the same item back, in their own words, in the same room. The stakeholder said what outcome they needed and why. The engineer said what they understood they were being asked to build. And then we listened for the daylight between the two — because there was almost always daylight, and it was almost always invisible until it was spoken aloud.
Half the time the stakeholder wanted something subtly different from what they'd first written down, and hearing the engineer's interpretation was what surfaced it. The other half, the engineer had spotted a constraint, or a cheaper path, that the stakeholder needed to weigh. Five minutes of "say it back to each other" routinely saved a sprint of building the confidently-wrong thing.
It's not a clever technique. It's just refusing to let two people assume they mean the same thing by the same words. Which is, once again, my old field wearing a new hat — but it works, and I now run every non-trivial requirement through it.
What I'm taking back to my "real" job
I've handed the backlog back and returned to building, but I'm not the same about it. Two things stuck.
First, I now watch for the translation gap from the engineering side. When a requirement reaches me, I'm more alert to the possibility that it's already been garbled on the way — that the thing I've been asked to build isn't quite the thing that's needed — and I ask the clarifying question earlier instead of dutifully building the wrong thing.
Second, and bigger: those six weeks quietly told me something about where I'm probably heading. The parts of this profession I find most energising aren't purely technical — they're the ones that sit exactly on the seam between the technology and the people who need it. I don't have a grand plan yet. But I've stopped thinking of my communications background as the thing I left behind to do "real" data work. It might turn out to be the whole point.
If you get offered a stint like this — a chance to stand in the gap for a while — take it. You'll learn more about your own trajectory in six weeks than in six months of staying in your lane.