business-requirements-documentlisted

# 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: 1. **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. 2. **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. 3. **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