One customer asks for a feature: check whether it belongs in the shared product

A customer asks for a new approval screen. They need it soon, and the account team wants to give them a clear answer. Should you add it to the product backlog, change an existing setting or arrange work specifically for that customer?

These routes carry different responsibilities. A shared product is a capability maintained for a wider group of customers. Configuration uses supported settings within that product. Customer-specific work is designed for one account’s circumstances and needs its own delivery and support agreement.

If you are moving into product work, learning to distinguish these routes is useful. Start with the task behind the request, then examine what would need to change. You can give a helpful response without promising a feature or a date before the team understands it.

Why this question is getting attention

In Mind the Product’s 19 October 2026 article on Forward Deployed Product Managers, Caroline Clark describes product people working closely with customers and feeding relevant learning back into the core product. That proximity raises a practical question: which part of a customer’s request should become a capability others can use?

You do not need that job title to face the same choice. Product Owners, developers, delivery leads and support colleagues all encounter requests that mix a real need with a proposed solution. This guide offers a small review you can use in that conversation.

Write down the task before choosing a route

Ask the requester to show a recent instance: what were they doing, where did it become difficult and what did they do instead? Separate their observation from your interpretation. “The regional lead retypes the approval details” is more useful to investigate than “the customer needs a custom screen”.

The GOV.UK Service Manual’s guidance on learning user needs recommends grounding needs in research and focusing on the problem rather than a particular solution. It also includes people who provide or support the service. That is established guidance, updated in March 2017, rather than a new product trend.

Record who experiences the problem within the account. A senior sponsor’s request is important context, but the person doing the task may have different constraints. Include those users before turning an account-level request into a specification.

Check three possible routes

A worked example: one screen, three different changes

Illustrative example: a maintenance-work tracking product receives a request from a customer with several depots. The customer asks for a “depot approval screen” because supervisors need a clearer way to review completed jobs.

Maya, a new Product Owner, reviews the task with a supervisor, an account colleague and a developer. The proposed screen bundles three requests:

• Use the label “depot lead”. In this example, the product already supports changing a role’s displayed label without changing its permissions. The team proposes testing that configuration with the customer.
• Require an additional approval for some jobs. The existing workflow does not support the requested conditional step. Maya records the underlying need and checks related evidence before recommending whether it belongs in the shared product.
• Produce a file in the customer’s billing format. The layout follows that customer’s internal system. The team assesses it as a separate account-specific integration, with an owner and support arrangements still to agree.

The request can now be discussed as three decisions. The label change does not commit the team to a new approval engine. Investigating the approval need does not promise its delivery. The billing connection does not become a standard product feature merely because it appears on the same screen.

Maya can explain the position plainly: “We can test the existing label setting. We need to investigate the approval rule before proposing a product change. The billing export needs a separate scope and support decision.” She agrees when the customer will receive the next update.

Use a short request review note

Use “not yet known” where evidence is missing. Keep the request linked to the account record and relevant research, so another colleague can understand the recommendation without relying on your memory.

Before your next customer call, pick one request and separate its underlying need from its local wording. Ask a developer and a customer-facing colleague to suggest the route independently. Discuss where their answers differ, then agree the evidence needed for the next decision.