Writing a Problem Statement: The Capstone Deliverable

The problem statement is the single-page artifact at the center of FDE work: it says, in words everyone agrees on, who's hurting, what it costs them, and what done looks like. This capstone tutorial shows how to write one that survives contact with executives and engineers alike.

Table of Contents

• What Is a Problem Statement?
• Why Write It Down
• The Anatomy of a Good Problem Statement
• A Filled-In Example
• Before and After
• What a Problem Statement Is Not
• Using It: Sign-Off and Next Steps

What Is a Problem Statement?

A problem statement is a short, written description of the problem you're solving: who it affects, what the measurable impact is, and what has to be true when the problem is solved. Usually five to eight sentences, or a tight template with a few blanks.

It's the output of everything in this course — the discovery, the interviews, the pain points, the business-to-technical translation, the requirements, the process map. If those earlier steps were done well, this page writes itself.

Why Write It Down

• It forces agreement. Vague language dies on the page. When everyone reads the same sentence, "we're all on the same page" stops being a hope and becomes a thing you can check.
• It stops scope creep. Halfway through the build, "we should add a reports page" gets answered with "that's not in the problem we agreed on." The statement is your anchor.
• It drives everything downstream. Requirements, design, build, testing, and the demo all reference it. It's the trunk everything else branches from.
• It aligns three audiences. Executives speak outcomes, users speak pain, engineers speak systems. A good statement carries all three in one page so nobody has to translate for the others.

The Anatomy of a Good Problem Statement

A solid statement has four parts in sequence — who, situation, cost, target:

That's the whole skeleton. If a statement is missing one of these, a reader will instinctively feel it's thin — and they'd be right.

A Filled-In Example

Here's a worked statement that hits every part:

Support agents at Apex Electrics spend roughly 60% of each ticket manually assembling customer context — order history, warranty, and prior tickets — from three separate systems that don't sync reliably. A single reply can take 15+ minutes and involves copy-paste, about 40% of tickets are reopened at least once, and median first-response time has crept up to two working days. The fix should let an agent resolve a routine ticket without manual data assembly. Success looks like: median first response under 4 business hours and reopened tickets below 10%.

Breaking it down against the structure:

Notice it opens with people, keeps several concrete numbers, names a cause, and closes with two thresholds you could actually test against. That's the shape to copy.

Before and After

A weak statement is worth studying so you can avoid its shape:

Customer service is slow and we need better tools. They want an AI support assistant, and it has to be done soon.

Everything's wrong with this, in an instructive way:

The strong statement fixes the weak one's every flaw by applying the anatomy above.

What a Problem Statement Is Not

• Not a feature list. "Build a unified dashboard, add alerts, add exports" is a build plan without a problem. No one can say whether the build solved anything.
• Not a sales pitch. Don't sell the product in the problem statement; the problem is the customer's, not yours.
• Not a meeting transcript. Nobody needs the play-by-play. Distill the conversation into the four parts.
• Not a chosen approach. Keep the "how" open. The solution is the next step, decided after the problem is agreed — deciding it early locks out better options (the same trap as solution-shaped requirements).

Using It: Sign-Off and Next Steps

The statement earns its place when you get it read back and confirmed. Hand it to a stakeholder — ideally the person who gave you the best stories in the interviews — and ask: "This is my understanding of your problem. Is it right?" They'll correct a detail or two, and now you have a document both of you own.

From there it becomes the north star. Requirements trace back to it, the design serves it, the demo walks its success criteria one by one, and if someone proposes an addition, the whole process stops for the question "does this still serve the statement?" Revision stays possible — discovery never ends, and the statement should change when real learning contradicts it. The discipline is that it only changes for evidence, not for convenience.

Best Practice: keep it to one page. If you need more space, you haven't found the real problem yet. Shorter, tighter, sharper — every cut that survives makes the statement stronger.