BRAC IT Product Discovery Framework

Back to Discovery Types

Glossary

When to use

The work is a dashboard, report, migration, extract, metric model, or decision-support output.
Business users need to trust definitions, source lineage, quality, and interpretation.

When not to use

The output depends on probabilistic model behavior, ranking, generation, or prediction.
The main challenge is workflow adoption or broad user experience.

Start with

Clarify the business question and decision the output must support.
Align metric definitions, source lineage, ownership, and data-quality assumptions.
Define UAT checks and sign-off rules before report or migration delivery.

Move from a business question to a validated, trusted output.

Phase 1 — Framing the ask

Define the real decision and agree what each metric means before anyone starts designing.

D.1Playbook step

Business Question Definition

Pin down the real decision this data needs to support.

Key output: Business Question Brief

D.2Playbook step

Metric & Definition Alignment

Resolve conflicting definitions before anyone builds anything.

Key output: Metric Dictionary

Depends on: D.1 Business Question Brief

Phase 2 — Data landscape

Confirm sources, lineage, accessibility, history, quality, gaps, and assumptions.

D.3Playbook step

Source & Lineage Mapping

Confirm where the data lives and whether it is actually usable.

Key output: Source & Lineage Map

Depends on: D.2 Metric Dictionary

D.4Playbook step

Data Quality & Assumptions Log

Document every quality issue and assumption embedded in the output.

Key output: Quality & Assumptions Log

Depends on: D.3 Source & Lineage Map

Phase 3 — Output requirements

Define user roles, visual priority, drill-down, access, cadence, and the expected experience.

D.5Playbook step

Output Requirements

Define what is shown, to whom, and at what level of access.

Key output: User Stories & Wireframe

Depends on: D.4 Quality & Assumptions Log

Phase 4 — Validation

Prove the output answers the original question and can support a real decision.

D.6Playbook step

Validation & Sign-off

Confirm the output actually answers the original business question.

Key output: UAT & Sign-off

Depends on: D.5 User Stories & Wireframe

Start with the decision, then earn trust in every number.

Use this Standard Discovery route to connect the business question to agreed metrics, accessible sources, explicit assumptions, usable output requirements, and decision-based validation.

Data

Who uses it

BAs, Data Engineers or Analysts, business owners, domain SMEs, report users, and governance stakeholders.

Data

When to use it

Use for dashboards, BI and MIS reports, scheduled or ad-hoc extracts, and data migrations where definitions and trust matter.

Data

What it produces

A business question brief, metric dictionary, lineage map, quality and assumptions log, output requirements, and UAT sign-off.

Data

How to use it

Frame the decision before exploring data, resolve metric definitions before design, and validate the final output against the original question.

Capture this project context.

Initiative nameOutput type: dashboard, MIS report, migration, or data extractBusiness ownerBA ownerData Engineer or AnalystTarget dateSME availability and areaBrief description and the decision the output should inform

Begin with the decision

Do not accept a dashboard or report as the requirement. Identify the decision, action, user, and usage frequency first.

Business correctness is shared work

The BA frames and validates meaning, the Data Engineer proves technical accessibility, and the SME validates domain reality.

Keep assumptions with the output

Quality decisions and embedded assumptions remain visible after launch so users can understand why numbers differ.

Who owns what in a data project

Data projects blur ownership. Use this reference to keep the BA focused on framing and business correctness rather than silently absorbing pipeline-building work.

Step	BA owns	Data Engineer / Analyst owns	Business SME owns
D.1 Business question	Define and validate the decision this data supports	—	Confirm the question reflects a real operational need
D.2 Metric definitions	Drive conflict resolution and document official formulas	Confirm what is technically computable	Validate the formula against domain reality
D.3 Source & lineage	Confirm business sense and flag gaps	Build and confirm technical lineage and accessibility	—
D.4 Data quality	Decide clean, exclude, or caveat and document assumptions	Run profiling and report technical quality issues	Explain known historical anomalies
D.5 Output requirements	Write stories and define hierarchy and access rules	Build the report, dashboard, or pipeline	Confirm the output matches real use
D.6 Validation	Run UAT, validate the question, and obtain sign-off	Confirm pipeline correctness and fix data-side bugs	Confirm a real decision can be made

Discovery is complete when all are true.

The business question is answered, not just technically delivered.
All metric definitions are resolved and documented.
Data sources, lineage, accessibility, and gaps are mapped.
Data quality issues and assumptions are logged and business-approved.
Output requirements include access control and visual hierarchy.
The business owner validated the output against the original question.
A review cadence is scheduled to catch metric drift.
BA role boundaries were respected with no silent scope drift into pipeline-building.

Final Data Discovery output

A trusted, decision-ready data output with agreed metrics, proven sources, explicit quality assumptions, clear access and presentation requirements, and formal validation against the original business question.

People, artifacts, escalation

Minimum participants

Product or BA ownerBusiness ownerData analystData engineerDomain expert

Minimum artifacts

Business question brief
Metric definitions
Source and lineage map
Data quality and assumptions log
Output validation checklist

Escalate if

The data output affects audit, compliance, finance, or executive reporting.
Metric owners disagree on definitions.
The team wants prediction, recommendation, classification, or generation.

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?

Continuous Discovery

Cadence

Weekly or biweekly signal review for live behavior, support issues, and adoption friction.
Monthly user or stakeholder touchpoints for deeper problem discovery.
Quarterly roadmap and outcome review using evidence, not only delivery volume.

Activities

Track behavior, funnel, support, operational, and trust signals after launch.
Keep a discovery backlog of assumptions, unresolved risks, and improvement hypotheses.
Run lightweight interviews, usability checks, experiment reviews, or data validation as new evidence appears.
Feed validated learning into roadmap, backlog, support readiness, and deprecation decisions.

Outputs

Discovery backlogLearning logExperiment or validation planOutcome dashboardRoadmap recommendation