saurabhships Business Requirements Document (BRD)
Why this exists
A BRD's only job is to get genuine alignment on why before anyone starts designing what. Skipped or done as a formality, three things go wrong:
- Unmeasurable objectives — goals like "improve customer experience" that nobody can later prove true or false, so the initiative can never be judged a success or failure.
- Solution creep — the document drifts into specifying features, UI, or architecture, which is premature (that's the PRD's job) and tends to lock in a solution before the problem is fully understood.
- Papered-over stakeholder conflict — different sponsors quietly hold different definitions of success, which surfaces as a fight much later, at a far more expensive point in the process.
This skill is a structure for catching all three before they cost anything.
Process
1. State the business problem, not a project title
Name the specific pain, who experiences it, and the cost of not solving it — lost revenue, rising cost, competitive exposure, compliance risk. Attach a number wherever one exists. "We need a new reporting system" is a title. "Enterprise renewals are at risk because finance teams can't self-serve the audit reports they need, costing an estimated 3 support-hours per renewal and contributing to at least 2 of last quarter's escalations" is a problem statement.
2. Define objectives as measurable outcomes
Each objective needs a metric, a baseline, a target, and a timeframe. "Improve onboarding" is not testable later. "Reduce time-to-first-value from 14 days to 5 days for new enterprise accounts by end of Q2" is.
3. Map stakeholders to their individual definitions of success
List each stakeholder group separately (exec sponsor, sales, support, finance, legal, whoever is actually affected) and what they specifically need to see to call this a win. Where two stakeholders' definitions conflict, say so explicitly and note how it will be resolved — surfacing that conflict is the point of doing this step, not a problem to smooth over.
4. Scope the business boundary, not the solution boundary
Define which business processes, customer segments, or markets are in scope and which are explicitly out — without prescribing how the problem gets solved. "In scope: enterprise self-serve onboarding. Out of scope: SMB tier, existing customer migrations" is a business boundary. Anything that starts describing a specific feature or screen belongs in the PRD, not here.
5. Make the business case
Lay out the cost of doing this against the cost of not doing it — rough ROI, strategic rationale, or both. Where a number is an estimate rather than a fact, say so and give a confidence level. An unlabeled guess presented as a hard number is how business cases lose credibility the first time someone checks the math.
6. List constraints and risks at the business level
Budget ceilings, regulatory or compliance requirements, hard external deadlines (e.g., a contractual commitment), and dependencies on other initiatives. These are business-level constraints, distinct from technical risk, which belongs in the PRD.
7. Define success criteria and how they'll actually be measured
Tie directly back to the objectives in step 2. Specify the measurement method and a review cadence — e.g., "reviewed 90 days post-launch against the self-serve adoption dashboard" — so there's a concrete point where the initiative gets judged against what it promised.
8. Get named sign-off, not just circulation
List the actual approvers by name and role, and record when each one signed off — not just that the document was shared. A BRD that was "sent around" but never actually agreed to hasn't done its job.
Output format
# Business Requirements Document: [Initiative Name]
**Owner:** [name] | **Date:** [date] | **Status:** Draft / Approved
**Feeds into PRD:** [link, once one exists]
## 1. Business Problem
[Problem statement — who's affected, cost of inaction, evidence]
## 2. Objectives
| Objective | Baseline | Target | Timeframe |
|---|---|---|---|
## 3. Stakeholders & Success Definitions
| Stakeholder | What success looks like to them |
|---|---|
## 4. Scope
**In scope:** [business processes/segments/markets]
**Out of scope:** [explicitly excluded]
## 5. Business Case
[Cost of doing vs. not doing; note which figures are estimates and their confidence level]
## 6. Constraints & Risks
- [budget, regulatory, deadlines, dependencies]
## 7. Success Criteria & Measurement
[Metric, measurement method, review cadence]
## 8. Approvals
| Approver | Role | Sign-off date |
|---|---|---|
Anti-patterns to avoid
- Don't let scope drift into specifying features, screens, or architecture — if you catch yourself describing a UI, stop and move it to the PRD.
- Don't write an objective you can't later prove true or false.
- Don't smooth over stakeholders with conflicting success definitions — name the conflict and how it'll be resolved.
- Don't treat "I shared the doc" as sign-off — get an actual name and date against each approval.
- Don't present an estimate as a fact — flag confidence level on anything that isn't measured.
Example (illustrative, placeholder company)
# Business Requirements Document: Enterprise Self-Serve Reporting
**Owner:** J. Alvarez | **Date:** 2026-08-15 | **Status:** Draft
## 1. Business Problem
Enterprise finance teams cannot generate their own audit-ready usage reports and
instead file support tickets, averaging 3 hours of support time per request.
This contributed to 2 of last quarter's 6 enterprise escalations and was cited
directly in one renewal risk review.
## 2. Objectives
| Objective | Baseline | Target | Timeframe |
|---|---|---|---|
| Reduce support hours per audit request | 3 hrs | 0.5 hrs | Q4 2026 |
| Reduce enterprise escalations citing reporting | 2/quarter | 0/quarter | Q1 2027 |
## 3. Stakeholders & Success Definitions
| Stakeholder | Success looks like |
|---|---|
| VP Customer Success | Escalation count drops; renewal risk reviews stop citing this |
| Support | Ticket volume for report requests drops to near zero |
| Finance (internal) | No increase in support headcount needed to offset the above |
## 4. Scope
**In scope:** Enterprise-tier self-serve audit report generation
**Out of scope:** SMB tier reporting, historical data migration for reports predating this system
## 5. Business Case
Estimated 3 support-hours saved per request, ~40 requests/quarter = 120 hours/quarter
recovered (medium confidence — based on last 2 quarters of ticket data). Strategic
rationale: removes a cited factor in enterprise renewal risk.
## 6. Constraints & Risks
- Must comply with existing SOC 2 audit log retention requirements
- Hard deadline: needs to ship before Q4 renewal cycle begins (2026-10-01)
## 7. Success Criteria & Measurement
Reviewed 90 days post-launch against support ticket volume dashboard and the
quarterly renewal risk review.
## 8. Approvals
| Approver | Role | Sign-off date |
|---|---|---|
| M. Chen | VP Customer Success | Pending |
| R. Osei | Head of Support | Pending |
Note the objectives are specific enough to be judged true or false in 90 days, and the scope line explicitly keeps solution decisions (what the report export actually looks like) out of this document — that's for the PRD.