Verify the Problem Behind the Request

Treat a requested feature as a proposed solution, not proof of the problem or the right approach.

Decision rule

Before recommending or committing to an unvalidated feature solution, establish who has the problem, what they cannot do today, and what outcome would resolve it. Compare solutions against that outcome and the product's intended audience.

Apply the rule

1. Separate the requested solution from the underlying problem. Preserve the requester's wording and source when available; distinguish observed difficulty from an inferred need.
2. Inspect available feedback, current behavior, workarounds, and accepted product direction. Establish the affected user, use case, friction, and desired change. A request from a different audience is evidence to assess, not an automatic roadmap commitment.
3. Ask only for missing information that could change the problem or solution. Useful questions are: What are you trying to accomplish? What stops you now? What would be different if this were solved? Label an unverified problem as a hypothesis rather than inventing customer evidence.
4. Compare the requested feature with the smallest viable alternative, including an existing capability when relevant. Recommend the option that addresses the established problem within current constraints; the original request may still be best.
5. Return the problem, supporting evidence or uncertainty, recommended solution, and any decision the user must settle. Resolve consequential requirements through the mode's requirements handoff before implementation.

Limits and neighboring owners