# Request Clarification Brief

## When to use

Use this template when a request is still vague, solution-biased, politically loaded, or too early for direct PRD drafting. It helps turn messy input into a clearer problem definition and a more useful next step.

## Input needed

Prefer to gather the minimum useful context:

- original ask or quote
- who raised it
- why it surfaced now
- likely target user or stakeholder
- any known business context or pressure
- known constraints or deadlines

If 1-2 critical premises would materially change the framing, ask about those first.

## Output goal

Produce a short clarification brief that separates the ask, the likely underlying problem, the uncertainty, and the best next move.

---

# Request Clarification Brief

## 1. Original ask

- What was actually requested?
- Quote or paraphrase the request faithfully.
- Who raised it?

## 2. Likely intent behind the ask

- What outcome might the requester actually care about?
- Is this about growth, retention, monetization, differentiation, operational pressure, stakeholder optics, or something else?

## 3. Problem vs proposed solution

### Likely problem

- What problem seems to be underneath the ask?

### Proposed solution already embedded

- What part of the request is already assuming a solution?
- Is that assumption safe, premature, or questionable?

## 4. Target user / stakeholder / scenario

- Who is affected?
- In what moment, workflow, or context does this matter?
- What scenario seems most important right now?

## 5. What we know vs what we are assuming

### Known

- Facts already available

### Assumptions

- What still looks inferred rather than confirmed?

## 6. Critical gaps

- Which missing facts would most change the framing?
- What needs confirmation before stronger evaluation or design?

## 7. Initial judgment

- How should this request be framed right now?
- Is it a real user problem, a business request, a perceived gap, or a pre-baked solution looking for justification?

## 8. Recommended next step

Choose the most useful next move:

- clarify with stakeholder
- evaluate feature value
- compare options
- draft a lightweight PRD
- defer pending evidence

### Immediate action

- What should happen next?
- Who needs to be involved?

---

## Misuse guard

Do not treat this as a form to fill.
If the brief still cannot answer what problem is being clarified, who is affected, and what the next move should be, the structure is not helping.

## Notes for use

A strong clarification brief should:

- preserve the original ask without getting trapped by its wording
- separate problem from solution early
- make uncertainty visible instead of pretending the request is already clear
- point to the right next workflow
