When to use this brief
Use the brief after an initial report has enough product relevance to review, but before an engineering issue is treated as committed work. It is suitable for recurring defects, severe single-customer failures, integration problems, regressions, and behavior that crosses support and engineering ownership.
Do not wait for every field to be complete. Mark missing information and assign the next evidence request. The brief should make uncertainty actionable rather than hiding it.
- Keep source links under the same access controls as the original system.
- Remove personal data that is not necessary to investigate the product behavior.
- Use representative examples and summarize total confirmed scope separately.
- Update the brief when engineering or customer evidence changes the problem boundary.
Copy the evidence brief
Replace each prompt with evidence or an explicit unknown. Keep links to authoritative source records instead of duplicating sensitive content into every destination system.
Problem title
[Affected user or role] cannot [expected outcome] when [condition].
Observed behavior
- Expected:
- Actual:
- First observed:
- Latest observed:
- Frequency:
Representative evidence
- Source record:
- Environment, version, plan, role:
- Screenshot, recording, log, trace, or request ID:
Reproduction
1.
2.
3.
- Reproducibility:
- Missing information:
Scope and impact
- Confirmed affected accounts or users:
- Suspected additional scope:
- Severity and workaround:
- Commercial or contractual context:
- Confidence:
Technical context
- Likely owner or product area:
- Related repository, release, issue, or incident:
- Hypotheses, clearly labeled:
Decision and verification
- Proposed next action:
- Decision owner:
- Acceptance criteria:
- Verification plan:
- Recurrence observation window:
- Affected-customer follow-up:How to complete the fields
Write the title and observed behavior in customer-centered language. Reproduction should be the shortest confirmed sequence, with environment and reliability. Scope should show both confirmed and suspected exposure, while confidence reflects the quality of the supporting evidence.
Technical context can include likely ownership, relevant code, releases, logs, and similar work. Label every root-cause statement as a hypothesis until technical evidence validates it. Acceptance criteria state the intended product behavior; the verification plan states how the team will prove that behavior after release.
Review the brief before creating external work
A reviewer should be able to understand the customer outcome, inspect representative evidence, see what remains unknown, evaluate scope and impact, and know how success will be tested. The destination and exact proposed action should also be visible before approval.
- The problem statement does not claim an unverified cause.
- Expected and actual behavior are testable.
- Reproduction gaps have a named next step.
- Impact values link to accounts, occurrences, and time windows.
- Acceptance criteria avoid prescribing an implementation unless required.
- Verification includes release availability and the original customer behavior.