Back

The Translator in the Room: Sitting Between Users, Business, and Engineering

4 MINS

The Translator in the Room: Sitting Between Users, Business, and Engineering

I've always been the person teams rely on, occasionally roll their eyes at, and still call when things go sideways. After two decades doing this, I've made peace with the role: a good product person is, more than anything, a translator. The hard part isn't having opinions. It's making three groups who use different words for the same thing finally agree on what they're building.

Everyone is optimising for something different

Engineering optimises for correctness and maintainability. Business optimises for revenue and timelines. Users optimise for getting through their day with minimum friction. None of these are wrong. They're just different objective functions, and left unmanaged they quietly pull the product in three directions at once.

My job is to hold all three in the same sentence. When I write a requirement, I'm really writing three documents: the "why" for engineering, the "how" for the business, and the "so what" for the user. If any one of those is missing, the feature ships and disappoints someone, usually the user, because they weren't in the room.

Good translation is mostly good questions

The fastest way to lose a roadmap is to accept the first version of a request. "We need a dashboard" is not a requirement; it's the end of someone's thinking, handed to you as the start of yours.

"What decision will this help you make?" turns a feature request back into a problem.
"What happens if we don't build it?" separates the urgent from the merely loud.
"Who's the unhappy user here?" finds the edge case before it finds you. Most of the value I add happens in the gap between what someone asked for and what they actually needed. Closing that gap is the whole job.

Clarity is a kindness

In a fast-moving startup, ambiguity is expensive. Every unclear decision gets re-litigated in three meetings and built twice. So I treat clarity as a deliverable: a crisp spec, an explicit trade-off, a single owner. It's not bureaucracy, it's the thing that lets a small team move fast without tripping over itself.

When people say a roadmap "feels calm," it's almost never because there's less work. It's because the decisions underneath it are legible. Everyone knows the why, the how, and the so-what, and nobody is guessing.

Why I still love the messy middle

It would be easier to pick a side, go deep technical, or go pure business. But the interesting problems live in the overlap, in the "can I steal you for a second" moments where a funnel drop-off, a feature trade-off, and a real user's frustration all turn out to be the same issue wearing three costumes.

That's where I do my best work: turning fun, messy problems into clear decisions, staying close to the problem, and shipping things that actually move the needle. The translation never really ends, and honestly, I wouldn't want it to.

Background

Noor skipped presentations and built real AI products.

Noor Tabbalat was part of the April 2026 cohort at Curious PM, alongside 18 other talented participants.