The Stakeholder Is Not the Customer

Imagine a hypothetical homepage request: put this launch at the top for everyone.

Stakeholder and customer describe roles in this decision, not two classes of people. The person making the request may also be a customer. They may hold better customer evidence than the PM and understand a business obligation the product team has missed.

The distinction concerns what the request can establish. It tells us that something matters to the organization. It does not yet tell us why the proposed placement is valuable to every customer.

That gap is easy to mishandle. A product team can treat the request as an instruction and make organizational urgency look like customer evidence. Or it can defend its process, ask for more research, and discard the legitimate fact inside the request.

Product judgment has to preserve both: the fact that makes the request urgent and the uncertainty about the customer.

A solution contains information

Product teams sometimes answer a feature request with, “Tell me the problem, not the solution.” The instinct is reasonable. A team that accepts every proposed mechanism eventually becomes an implementation queue.

The response can also throw away useful context. “Put it at the top for everyone” says that ordinary distribution does not feel dependable enough. Perhaps the launch carries a commitment that can only be honored during a short window. Perhaps the organization has made a large bet and needs a plausible audience to encounter it before early behavioral signals exist. The placement is a proposed solution, but the concern behind it is product information.

Ask what the stakeholder needs the product to make true before deciding how much authority the proposed solution deserves.

The purpose is to identify which part of the ask deserves authority, without turning translation into a ritual for making the request smaller. A deadline may be fixed. An obligation may be non-negotiable. A belief about audience interest may still be a hypothesis. Those conditions can appear together in one sentence while requiring different product responses.

The stakeholder may also bring direct customer evidence. A support leader can see a recurring failure the dashboard has not captured. A sales partner may understand why an important segment cannot complete a task. That evidence should enter the decision at its actual strength. The PM does not gain superior customer knowledge merely by changing the wording of the request.

The proposed solution may contain expertise too. Someone close to the launch may know why a particular surface or moment matters. Before substituting a different mechanism, the PM should understand why this one felt necessary. Translation is collaborative. It is not a license for product to recode another function's intent into language only product can approve.

The discipline is narrower: keep the source of each claim visible. What does the organization know about its own commitment? What does it know about the customer? What is it inferring because time is short?

Translate before negotiating the mechanism

For the homepage example, the organizational fact might be: the company needs likely audiences to have a real chance to encounter this launch during a limited window, before the product has much behavioral evidence about it.

That sentence is still open to challenge. “Likely audiences” needs support. “A real chance” needs a product meaning. The lack of early behavior may be genuine, or the existing discovery system may already provide enough exposure. Translation does not resolve those questions. It puts them where the team can inspect them.

The working record can stay compact:

1. Read the solution for the organizational fact it contains. Preserve the original ask, the timing, and any obligation that makes the request urgent.
2. Translate that fact into a condition the product may need to create. Separate direct customer evidence from the assumptions the team is making under uncertainty.
3. Give the mechanism only the authority its reason earns. Name the scope of the choice and the observation that would make the team revisit it.

Here, authority means permission for a mechanism to override ordinary product behavior, not organizational rank. A hard obligation can justify broad authority. A belief about audience interest may justify a test. When those reasons stay blended, the customer hypothesis can quietly borrow the force of the obligation.

The stakeholder should still recognize the original need after translation, while the people closest to the customer and system can challenge its implications. If either side disappears, the team has replaced one opaque instruction with another.

Suppose the evidence supports likely audience fit but not universal relevance. One bounded response could ensure that eligible profiles encounter the launch once during the window, then return later placement to the normal personalized experience. The intervention would serve the organizational need for initial awareness without claiming that every customer wants repeated exposure.

This bounded example carries only the translation argument. I have written separately about the deeper governance of promotion in personalized products. The point here is what changed before the team selected the mechanism. The original request hid a business fact, a customer hypothesis, and a proposed level of authority inside one instruction. Translation separated them.

It also keeps the resulting evidence honest. Starts after guaranteed exposure can show what people did once the product created awareness. They cannot, by themselves, prove that the title would have earned the same attention through ordinary discovery.

Some requests deserve direct authority

A translation step can become product theater if the real purpose is to delay an answer the team dislikes. Some requests should govern the experience directly.

A safety interruption may need to reach everyone. A contract can require a specific placement. A live event may create customer value precisely because the audience encounters a shared moment together. In those cases, broad authority is part of the reason for the request.

The product team should say so plainly. It can honor the constraint, identify the customer tradeoff, and proceed without inventing a relevance argument. More research should not become a polite way to avoid a legitimate decision.

The same clarity helps when the request remains a hypothesis. The stakeholder can see that the intent survived even if the mechanism changed. The team can explain what it believes about the customer and which part it still needs to learn. Disagreement moves away from whether product is “supporting the launch” and toward the claim that actually controls the choice.

The hypothetical request began as a placement for everyone. After translation, the team can inspect the organizational fact driving it, the customer condition it is meant to create, and the authority the chosen mechanism is allowed to exercise. That is what the original instruction left hidden.

---

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.