Skip to main content

Step 2 — Problem Definition

⏱️ At a Glance Step 2 of 5 — and the most important one. Write one dense paragraph covering: what's broken, who it affects, and a number that proves it's a real problem. Vague input here means a vague, generic BRD later — specific input here means a sharp one.

The Problem Definition step captures the real-world pain points your project addresses. The more specific and data-driven your inputs, the more precise your AI-generated documents will be — this is the single highest-leverage step in the entire brief.

This stage captures three dimensions:

  • What is broken — the current failure or gap
  • Who is impacted — teams, customers, or systems affected
  • Which metrics are failing — quantifiable indicators of the problem

Steps​

  1. In the input field, describe what's broken, who's impacted, and which metrics are failing.
  2. Craft a clear problem statement that captures all three dimensions in a single, dense paragraph.
  3. Click Back to return to Project Overview.
  4. Click Continue to proceed to Step 3 — Solution Design.
  5. Click Save Draft to store progress and resume later.

✏️ Avoid vague statements like "the system is slow" or "tracking is hard." Instead, name the specific pain point, the affected user role, and a measurable impact. Vague inputs produce vague BRDs.

Worked Example — Contractor Sync​

This is where the Contractor Sync story actually starts. Here's the real situation that was typed into this field.

The Underlying Problem​

Before Contractor Sync existed, a facilities services company managed cleaner attendance entirely manually. Supervisors and the cleaners themselves tracked clock-in and clock-out times over phone calls, WhatsApp messages, and end-of-day spreadsheet entry. There was no system of record — just a supervisor's memory and whatever a cleaner self-reported.

What Was Broken​

  • No reliable way to confirm a cleaner was physically present at the correct client site when they "clocked in."
  • Constant manual data entry to reconcile phone-call check-ins into payroll spreadsheets.
  • Disputes between cleaners and supervisors over actual hours worked, with no record to resolve them.
  • No visibility for the business into real-time staffing coverage across client sites.

Who Was Impacted​

  • Cleaners — frustrated by disputes over hours and inconsistent pay.
  • Site supervisors — buried in manual reconciliation work every single day.
  • Payroll/Operations team — processing attendance data riddled with manual entry errors.
  • Client sites — no transparency into whether contracted coverage was actually being met.

Failing Metrics​

  • Manual reconciliation time per supervisor: ~45–60 minutes/day.
  • Attendance disputes: roughly 8–10 per week across the cleaner workforce.
  • Payroll correction rate due to attendance errors: ~12% of pay runs.

The Problem Statement (as entered into DeX)​

"Cleaner attendance across client sites is tracked manually via phone calls and spreadsheets, with no way to verify that a clock-in actually happened at the correct location or by the correct person. This creates daily manual reconciliation work for supervisors, frequent disputes over hours worked, and payroll errors in roughly 1 out of every 8 pay runs."

This single paragraph is what DeX's AI used downstream to generate the BRD's Executive Summary and Background sections (see Sample BRD).

Why This Step Matters So Much​

Compare this to the BRD excerpt generated for the Loanmind AI project (a different, larger example from a lending platform), where the problem definition described:

Manual collection, classification, and verification of unstructured documents made underwriting smaller loans economically unviable for lenders.

Notice the pattern in both cases: a specific operational failure, a named impacted group, and a quantifiable cost. That structure is exactly what the AI engine is trained to extract and expand into formal business requirements.

🧩 The formula, in short: [Specific failure] + [who it hurts] + [a number that proves it] = a problem statement DeX can turn into a sharp BRD. Drop any one of the three and the AI has to guess — and guesses produce generic output you'll spend time fixing later.

What's Next​

➡️ Solution Design — Describe what you're building, for whom, and how success will be measured.