The problem statement, and why the first draft is always wrong.

Alright, problem statement time! The most important part of the business case. Let's jump right in.

The problem statement decides whether the rest of the document gets read. If it doesn't land in the first paragraph, the reader is skimming the rest at best. So this is where the writing has to be sharpest.

So let me walk through my process.

The first thing I do is write the problem statement out as I understand it. Here's the first draft I wrote for the FNOL business case:

Definity receives about 500 claim calls a day. At an average of 3 to 5 minutes per call, agents spend hours on the triage system for FNOL calls. The high influx of calls makes agents prone to burnout, which could result in specific problems: 1. Agents misclassify the severity of calls. 2. Agents route claims to the wrong adjuster. 3. Some fraudulent calls make it through the claims system. These errors cost the business lots of money and time every single day. Something has to change to improve the overall business efficiency.

Yes, this is a lot for a first draft, but practice is basically what helps my starting point look like this.

Let's critique it..

Structure is right. The points are mostly right. But I'd never ship this. I've learned over the years that the first draft is just that, a first draft. Let's work towards the shipped version.

What a Problem Statement Has to Do

Before I rewrite a single sentence, I think about the job the paragraph is doing on the page. A problem statement has to land three things in the reader's head:

Who has the problem. The people in pain. In an insurance company that's two groups: the customer at the worst moment of their year .. think accident or injury, and the operational team carrying the load of listening to them every day.

Who's paying for it today. The company is footing a bill right now in agent hours, in turnover, in missed fraud, in slow resolutions. The size of that bill is the size of the problem.

How big the help would be. Implicit in the bill. If we're paying this much today, solving it is at least that valuable. The reader has to walk away feeling that size, not just reading about it.

Every sentence in the paragraph should serve one of those three. If a sentence doesn't, it's filler.

That's the lens. Now back to my draft.

The first draft is the default. Checking against the three is the work.

Did I Show Who Has the Problem?

This was the first thing I caught on re-read. The customer didn't appear once.

The first draft had operational impact (misclassified severity, wrong routing, missed fraud) and business impact (cost, time, burnout). All true. But who was actually hurting?

This is an insurance company. A FNOL call is happening because someone's worst day of the year is in progress. Their car is wrecked or their basement is flooded. The product they're paying for is the company being there at exactly that moment.

A slow or wrong triage is the moment that promise breaks. That's the angle that lands with an executive who knows the brand depends on the customer experience at the moment of loss.

Customer in. First check done.

Did I Show Who's Paying for It and What the Exact Cost Is?

With the customer in the paragraph, I went back to the numbers.

The draft said "agents spend hours on the triage system." Hours. Fine word. Means nothing.

The fact I had was 500 calls a day, 3 to 5 minutes each. But this doesn't mean anything. This doesn't communicate the weight of the cost.

Think of it like this, a billion cents and 10 million dollars are the exact same thing, but aggregating it adds weight, and that is exactly what I'll do to the numbers.

A billion cents and 10 million dollars are the exact same thing, but aggregating it adds weight.

500 calls, 3 to 5 minutes each is 1500 to 2500 minutes on call. That aggregates to 25 to 40 hours! That's the equivalent of three to five full-time employees on an 8-hour shift doing nothing else.

So by swapping the raw for aggregated numbers, suddenly the numbers carry more weight.

Aggregated numbers land differently than individual ones. They make the cost to the company visible.

Did I Close With a Bang?

Funny as it sounds, I asked myself.. does my closing statement demand urgency or does it invoke any emotion?

In the end, I am writing a sales pitch!

My first draft ended on "something has to change to improve the overall business efficiency." .. definitely too vague.

The closing sentence of a problem statement should be the hardest, most concrete sentence in the section. So I check every closer by asking: if I delete this, does the paragraph get weaker or stronger? If stronger, the line was filler. The strongest closer leaves the reader sitting with the emotional size and weight of the bill, not with a vague promise that someone will fix it.

The Version That Shipped

After running the three checks on the draft, the problem statement looked like this:

Definity's claims team receives over 500 FNOL calls per day. Each call takes a call centre agent 3 to 5 minutes to triage manually, which adds up to 25 to 40 hours of agent time spent on triage every single day. During that time the agent is capturing customer details, classifying severity, and assessing fraud risk all at once.

This manual process creates four problems. Agents misclassify severity, so high-priority claims sit in queues while lower priority claims get worked first. Claims get routed to the wrong adjuster team, which adds days to resolution. Fraud indicators get missed because agents are cognitively overloaded during the call. Agent burnout is high, which drives turnover and training cost.

The customer feels this too. They are calling at the worst moment of their year. Their car is wrecked or their basement is flooded and they need their insurance to work. A slow or inconsistent triage experience damages the relationship at exactly the moment the customer is judging whether Definity was worth paying for.

Same structure as the first draft. Same facts. Almost every sentence rewritten because of the three checks.

If This Were a Real Project

I'll be honest though, I didn't always know to check for these three things. For a long time I just wrote the first draft and shipped it. The draft felt fine, and "fine" is the trap. Fine drafts get skimmed, and skimmed drafts don't get funded.

The three checks came from doing it wrong enough times to notice what was missing each time. They're patterns I kept catching in my own work after the fact, written down so I don't have to catch them after the fact anymore.

In a real project there'd still be another round after the checks. A director would tell me a number I'd treated as solid is actually unvalidated, or a framing I picked won't land with the specific person reading. The three checks can't replace that round.

But by the time the draft hits their desk, I want it to be a version where the obvious checks have already been done. The director's time is for the checks I can't run myself yet.

Sayonara.