Who should own remote UI: engineering, product or growth?

Build, buy & decideOpinionNov 1, 20263 min readMiniwall team

Part of the series: Ways to change a live app without shipping a release

Don't give remote UI to one team. Split it into four decisions and give each to whoever is best placed to make it: engineering owns the platform and its guardrails, product and growth own what the screens say and when they change, and one shared number keeps both honest. When it goes wrong, it's usually because one team owns everything, or because nobody owns the in-between.

This is an opinion. We haven't observed enough teams to claim a pattern, so we'll mark what is reasoning and keep the rest short.

"Who owns it" is four questions

People ask the question as if ownership were one thing. In practice you have to decide four different things, and the right owner is different for each.

Decision	What it covers	Natural owner
The building blocks	Which components exist, how they look, what they can do	Engineering and design
The content	What each screen says, to whom, and when it changes	Product and growth
The release rules	Who can publish, what needs review, how to roll back	Shared, written down
The failure plan	What the app does when a screen won't load, and who is called	Engineering

Swipe sideways to see every column.

The first and last are about safety, so they belong with the people who are on call. The middle two are about speed and judgment, so they belong with the people who know what the customer needs to see.

What goes wrong in each direction

Engineering owns all of it. Every wording change becomes a ticket again, which was the problem you were trying to remove. The platform exists, but the queue just moved.

Growth owns all of it. Changes go live fast and nobody checks that they still work on an old app version, with a screen reader, or in a language nobody on the team reads. It works until the first bad Friday.

Nobody owns it. The component set stops growing, old screens linger, and the person who knew how it works has moved on. This is the quiet failure, and we'd say the most common one.

Make the boundary a rule, not a habit

The split only works if it's enforced by something other than goodwill. Three things help:

Limit who can publish. Not everyone who can draft should be able to go live.
Give engineering a veto on what the platform can do, not on every sentence on a screen.
Share one number. Pick a measure both sides care about, for example the share of changes that went live within a day, and look at it together.

A small test

Pick a change you made last month. Can you answer, without arguing, who asked for it, who approved it, who published it, and who would have fixed it if it had broken? If two of those are the same person and that person is a bottleneck, or if one of them is "nobody", that's where to start.

When one team really should own it

A very small team doesn't need this table. If three people build and ship everything, the split is overhead. It starts to matter when changes cross teams, which is usually when somebody says "I'm waiting on engineering" or "I don't know who changed that".