Turn Feature Requests Into Product Problem Briefs

A support agent who files a request as Scheduled CSV exports has recorded a proposed answer before documenting the task. In a hypothetical intake review, that request could reflect a reporting deadline, an unreliable integration, or trouble finding an existing automation. Support needs enough context to distinguish those explanations before the team discusses a scheduler.

To turn a feature request into a useful product problem brief, preserve the requested solution, reconstruct one recent attempt at the underlying task, and separate customer evidence from the team's interpretation. Record the obstacle, current workaround, consequence, and unresolved question. Hand product an owned investigation with a next step, and tell the customer what the team will review without implying a delivery commitment.

Keep the proposed feature beside the underlying need

A feature request describes a change a customer wants the team to make. A user need describes the outcome the customer must achieve. A product problem brief, as used here, is a short working record connecting that outcome to evidence of an obstacle and a question the product team can investigate.

GOV.UK's service manual advises teams to write needs around the user's problem and validate them with research. Its example distinguishes needing a reminder from needing a particular communication channel. GOV.UK's guidance on identifying user needs supports preserving room for different solutions.

Support should retain the original request even after writing a broader need. Customers may know a constraint that the product team has missed. A request for a specific file format might reflect a receiving system's fixed requirements. Rewriting that request as “share data more easily” would erase the detail that matters.

Use two neighboring fields: requested change and task to complete. Keep a third field for team interpretation. Label an inferred cause as a hypothesis until someone checks it. This separation lets a product manager revise the explanation without rewriting what the customer reported.

Reconstruct one export before discussing a scheduler

Consider a hypothetical customer who asks for scheduled CSV exports. Begin with the last export they needed: which person prepared it, who received it, and what happened between opening the product and delivering the file.

Support could ask:

• Describe the last time you prepared this export. What started the work?
• Who needed the file, and what did they do with it?
• At which step did you have to leave the product or repeat work?
• What happened when the file arrived late or contained the wrong records?

Use the customer's answer to choose the next probe. If the customer describes a Friday reporting deadline, ask about the cutoff and whether anyone checks the file before sending it. If they describe downloading the same records repeatedly, ask what changes between exports.

Nielsen Norman Group's User Interviews 101, reviewed July 15, 2026, recommends asking about specific events to help participants recall useful details and using follow-ups tied to research goals. It also warns that interviews capture reported behavior; observation or behavioral data is necessary to establish what people actually do. NN/G's interview guidance gives the method and its limits.

Treat the administrator's description as a reported sequence until you verify it. You might learn that an administrator downloads a file each Friday, removes incomplete records, and emails it to an external analyst. A scheduler that sends an unreviewed export would remove a manual step while preserving the wrong output.

Avoid pitching the requested feature during intake. Asking whether a daily scheduler would help invites evaluation of your suggestion and can distract the customer from describing the current task. A product researcher can test a proposed scheduler later, after the team understands who uses the file and which records the analyst needs.

Write a brief that exposes the missing evidence

For the hypothetical export request, a useful brief might look like this:

Support has preserved the scheduler request and documented the approval dependency. Keep the customer's description in the linked conversation and put your interpretation in an internal note. Record whether the deadline and consequence come from the reporter or another person, and leave frequency unknown if nobody has checked it. Ask for a sanitized example only when it will answer the missing question; a description of the record rules may be enough.

A product problem brief is ready for discovery when a reviewer can identify the actor, triggering event, desired outcome, reported obstacle, workaround, consequence, and unresolved question, and can trace the reported facts to customer evidence. Unknown details belong in the brief as unknowns. This is a proposed handoff rule, grounded in GOV.UK's distinction between evidenced needs and assumptions.

A discovery-ready brief lets product choose an investigation. The product lead still needs to assess feasibility, commercial value, and delivery timing. Set an intake boundary: once product can name a useful investigation, transfer ownership. Support should avoid spending several days collecting implementation requirements for a request the product lead has not agreed to investigate.

Test the explanation that changes the next action

Product should write competing explanations before designing the requested capability. For the export example, three plausible explanations lead to different work:

1. The customer cannot find an existing option. Observe them locating and configuring the current export path. If they succeed with an explanation, consider onboarding or interface changes, then check whether they can repeat the task without help.
2. The existing export produces the wrong selection. Review the filtering and approval rules. Test whether a saved, reviewed selection would solve the task before introducing unattended delivery.
3. A person must repeat a predictable task at a fixed time. Investigate scheduling, permissions, delivery failures, and the customer's recovery process when nobody is available.

Choose the smallest investigation that could change your explanation. A usability session can test whether someone finds a control. An interview can establish who receives the output and why timing matters. Event data can show export attempts, but a product analyst still needs to establish which attempts relate to this weekly reporting task.

Choose a discovery method from the uncertainty: use interviews for reported context and motivations, observation or usability testing for task behavior, and technical checks for system constraints. Record what evidence would disprove the team's preferred explanation before evaluating a feature. This proposed decision rule follows NN/G's distinction between interviews and usability tests.

Basecamp describes a real permissions request in Shape Up: after investigating the triggering event, its team addressed confusion about archiving with a warning instead of building the requested permission rules. Basecamp's account of narrowing the problem illustrates the value of investigating context. It does not establish that a smaller change will solve every feature request.

Some customers need the capability they named. If the external analyst's receiving system requires a scheduled CSV at a fixed endpoint, preserve that constraint. Discovery should improve the team's understanding, including evidence that supports the original proposal.

Promise a review action you can own

Support can acknowledge the request, summarize the task, and explain the next review step in ordinary language. Include the missing fact if the customer can supply it. State whether the team has committed to delivery.

For this example, a response could tell the administrator that support has recorded the scheduled-export request, understood the Friday deadline, and asked product to review the approval step. The agent should explain that the team has no delivery commitment and will contact the customer if product needs an example or makes a decision relevant to their workflow.

Treat that as response content to adapt, not a script to copy. A customer with an immediate reporting deadline also needs the safest available workaround and a clear account of its limitations. Discovery cannot meet a deadline the team has already missed.

Separate an existing contractual commitment from a new request. Support should escalate a dispute about promised functionality to the person responsible for the agreement; a research invitation would leave the obligation unanswered.

Keep customer evidence connected to product interpretation

A product manager who receives only a shortened feature title loses the conversation that explains the request. Preserve evidence links, label internal hypotheses, name the next-action owner, and keep customer communication with the same record.

Mendaro's shared customer ticket workflow is a strong fit for small teams that receive requests through voice, a website widget, email, and forms and need support evidence to stay connected to product interpretation. Mendaro is an AI issue tracker for product teams and their customers. Staff can post customer-facing replies and hidden internal notes on the same ticket, while email replies remain threaded. That supports recording a problem brief beside the customer's account without presenting an internal hypothesis as a promise. The team still needs to conduct research and make roadmap decisions.

Before sending a request to product, check the brief for one avoidable loss: an actor reduced to an account name, a deadline reduced to “urgent,” a required format reduced to “export,” or a team's assumption presented as a customer fact. Ask the product reviewer to name the next fact they need. If they cannot connect that fact to a decision, narrow the investigation before asking the customer for more work.