BRAC IT

Product Discovery
Back to Discovery Types
Glossary

When to use

  • The affected surface is narrow and already understood.
  • The team mainly needs rules, edge cases, acceptance criteria, and QA clarity.

When not to use

  • The problem itself is disputed or not validated.
  • Multiple teams, systems, approvals, or rollout groups are involved.

Start with

  • Confirm the exact requester need and affected screens, reports, rules, or records.
  • List edge cases, error states, and acceptance criteria before implementation planning.
  • Align QA examples with the requester and delivery lead.

Keep Flash Discovery short, ordered, and evidence-based.

Phase 1 — Intake

Understand the exact request, affected scope, root cause, and immediate escalation triggers.

T.1Playbook step

Intake & Context

Review the ticket, identify exact scope, and run root cause analysis.

Key output: Triage Note

Phase 2 — Validation

Confirm the happy path, edge cases, business rule, and boundaries with the requester and SME.

T.2Playbook step

Rules Validation

Run a focused requester sync to define the happy path, business rule, and edge cases.

Key output: Draft Requirements

Depends on: T.1 Triage Note completed

Phase 3 — Technical review

Map regression risk, QA coverage, effort, and environment readiness with Tech and QA.

T.3Playbook step

Tech & QA Impact

Review the draft requirements with Tech and QA and map the regression surface.

Key output: Regression Checklist

Depends on: T.2 Draft Requirements

Phase 4 — Handoff

Package the validated change as a signed-off user story ready for sprint planning.

T.4Playbook step

Delivery Handoff

Format the validated change into Given/When/Then acceptance criteria and obtain sign-off.

Key output: Ready User Story

Depends on: T.3 Regression Checklist

Move a small change from request to ready story in four focused steps.

Use this Flash Discovery route when the problem is understood and the remaining risk is in requirement detail, regression impact, or handoff quality.

Tactical
Who uses it

Business Analysts and Product Managers working with the requester, Tech Lead, QA, and an available domain SME.

Tactical
When to use it

Use for bounded, low-risk changes where the core problem is already understood and delivery is near-term.

Tactical
What it produces

A triage note, validated business rules, regression coverage, and a signed-off user story with acceptance criteria.

Tactical
How to use it

Complete T.1 through T.4 in order. Escalate immediately if financial, compliance, audit, or wider technical risk appears.

Capture this project context.

Initiative nameRequest sourceBusiness ownerBA / PM ownerTech LeadTarget dateSME availability and areaBrief description of the change and why it is needed
Protect the time box

The requester sync is deliberately short. Tactical Discovery clarifies a bounded request; it is not a substitute for a workshop on an uncertain product direction.

Write the rule before the story

Capture business logic in plain language and make edge cases explicit before translating the change into acceptance criteria.

Close both sides of the handoff

The business owner confirms intent and the Tech Lead confirms technical clarity before the story enters sprint planning.

Discovery is complete when all are true.

  • Problem and scope are clearly documented.
  • Business rule is written in plain English.
  • At least five edge cases are identified and covered.
  • Given/When/Then acceptance criteria are written.
  • Regression surface is mapped and QA scenarios exist.
  • Business owner and Tech Lead have signed off.
  • No major unresolved risk or open question remains.
  • The story is ready for sprint planning.
Final Tactical Discovery output

A delivery-ready user story that connects the original request, validated business rules, edge cases, regression coverage, and stakeholder sign-off.

People, artifacts, escalation

Minimum participants

RequesterProduct or BA ownerQADelivery lead

Minimum artifacts

  • Requirement note
  • Acceptance criteria
  • Edge-case checklist
  • QA examples

Escalate if

  • Stakeholders disagree on the problem.
  • A workflow, integration, data-quality, or rollout dependency appears.
  • The change has financial, compliance, or audit consequences.

Check the evidence before moving forward.

What decision will this discovery evidence support?

What user, process, data, system, or model evidence would change the decision?

Which risk remains unresolved, and who accepts it if the team proceeds?

What artifact proves the team is ready for build, pilot, rollout, or scale?