Main idea

Customers are excellent at describing what they live through: a pain, a constraint, a context, a frustration, a business obligation. They are far less reliable when they propose the answer, because proposing assumes knowing the product, its constraints and the other uses it serves.

An incoming request is therefore not a work item: it is a signal. It can feed the queue, and that isn't automatic — it can stay in a signals database, be linked to other requests, resurface later, never resurface, fail to match the product strategy, fail to fit the roadmap, concern too isolated a case, or be interesting without being important. None of these outcomes is a loss of information.

Why it matters

This protects the product from a quiet drift: a company that pours every request into its queue lets its strategy be written by the order of arrival of the customers who speak loudest.

It also changes what should be kept from an exchange. The proposed solution is the most perishable part; what deserves keeping is the situation described, which stays comparable to other exchanges years later.

Nuances and limits

Some customers know the product better than the team and propose sound answers — often advanced users, or highly regulated industries. Dismissing their proposal on principle then costs more than it protects.

And a contract can turn a request into a commitment: the room for interpretation is gone, whatever the quality of the solution requested.

Layer added by "Session source: what your documents don't capture" (2026-07-20). What you learn from a request is almost never legible in the request itself. An isolated remark at the end of a call teaches nothing; it is dozens of fragments accumulated over months that reveal that a customer isn't after the feature they name, but is trying to reduce a risk, preserve control, avoid an internal tension or work around a constraint in their organization. The learning material is therefore the accumulation, not the unit — which presupposes a place where fragments too small to justify a ticket can still be deposited.

Open questions

• How do you tell a customer their request has been heard without letting them believe it is planned?