The Empty Space Between Product, Design, and Engineering

A product team can have clear roles and still leave an important decision unowned. The work has been divided, people know what they are responsible for, and each part has someone who can explain it. What remains unclear is who can settle a choice that crosses those responsibilities.

I want the team to be able to explain what a customer can rely on across those separate pieces of work. A design may assume behavior that engineering cannot guarantee. Meeting that expectation may require a change from another team. Each discipline has something necessary to contribute, and the person responsible for their part may have limited authority over the rest.

For a simple illustration, a screen that says a request has been received may accurately describe what the software knows. Whether the customer can now leave and rely on the request being completed is a larger question. It involves what happens later, who learns about a failure, and whether support can help. The wording and the technical response both matter, but someone still has to resolve what the product is promising.

I want that decision to be visible while the team can still change the work. When it remains implicit, the person implementing a small part of the experience may end up making a commitment on behalf of people they have never spoken to. Asking them to use good judgment is reasonable. Expecting them to know every consequence across the organization is not.

Who can resolve the choice?

Putting a name beside a problem is useful only if there is a way for that person to get an answer. A product manager may be accountable for the experience while having no authority to change the service it depends on. A designer may identify a misleading message while being unable to change the behavior behind it. The person who notices the gap needs access to whoever can resolve it.

I don't think that means the product manager should inherit every decision that falls between functions. Engineering may be best placed to settle a reliability question. Support may understand a recovery route the team has overlooked. Product and design still need to understand what those answers mean for the customer. The work is to identify the actual choice and bring the relevant knowledge and authority to it.

I want someone to stay with the question until that happens. They need to know who can decide, what is still unresolved, and when the lack of an answer will affect the work. Following up does not give them authority over another team. It gives the unresolved decision a person who will bring it back rather than assume someone else has handled it.

Sometimes the answer will be that another team cannot take on the change. Its existing commitments may be just as important as the feature asking for help. At that point, the people responsible for priorities across the teams need to make a choice. They can move capacity, narrow the proposed experience, use an existing supported route, or delay the new work. Any customer obligation still has to be met. The person coordinating the dependency cannot create the missing capacity by following up more often.

This is where accountability can become unfair. Someone is held responsible for an outcome, yet the decisions and resources needed to deliver it remain elsewhere. If leaders want that person to own the result, they have to provide a practical way to resolve the dependencies. Otherwise, the assignment leaves them responsible for a conflict they cannot settle.

Make room for the decision

There is a real cost to bringing more people into the work. A designer may be supporting several teams. An engineer may be protecting a service other products depend on. Pulling either into another discussion takes time from something already agreed. I want the request for their attention to be specific enough that they can tell what needs their judgment and why it cannot be resolved within the existing work.

That also means leaving people room to make ordinary decisions within their expertise. Improving a message within agreed behavior should not require the same discussion as changing what a customer has been promised. The conversation needs to widen when a choice creates an obligation for someone else or changes how a failure will be handled. It should remain small enough to reach an answer.

An existing review can make room for this. Alongside the work that is ready, the team can identify the decisions still waiting on someone with authority to resolve them. A question that affects whether an experience is usable deserves attention before it disappears into a general dependency update. An established recovery process may already provide the answer; the team needs to check that people can actually use it before assuming new work is required.

I also want people to be able to raise these questions without automatically inheriting the work needed to fix them. If every person who identifies a gap becomes responsible for resolving it alone, asking a useful question becomes an expensive contribution. The response needs to include a decision about who can take the work on and what will make room for it.

When someone brings back a problem that no team can resolve within its current commitments, I expect the people who control those commitments to help make the choice. Asking for clearer ownership has to include being willing to change what people are being asked to deliver.

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.