Turning Business Problems Into Technical Problems

Customers describe their world in business language ("we keep losing deals to slow proposals"); engineers build in technical language ("the proposal pipeline has four manual handoffs and no audit trail"). The FDE's most valuable skill is translating between the two until one statement covers both. That translation is this tutorial.

Table of Contents

• What Is a Business Problem?
• What Is a Technical Problem?
• The Translation Process
• Quantify Before You Translate
• Working Example: From Business to Technical
• Symptoms, Causes, and Root Cause

What Is a Business Problem?

A business problem is stated in outcomes: money, time, risk, customers. It talks about impact without saying how the impact happens. Typical business problems are things like "we're losing deals because proposals take a week to prepare" or "customers are churning after bad support."

The business statement is your starting point — it's what the customer cares about and what they'll use to judge success. But on its own it doesn't tell you what to build.

What Is a Technical Problem?

A technical problem is stated in systems and data: inputs, steps, outputs, failures. It describes the mechanism behind the impact. The same proposal problem becomes "proposal data lives in four separate systems, and assembling it requires a senior analyst to copy-paste for about eight hours with no validation."

The two are the same pain in two languages. The rule that ties them together: every real technical problem must trace back to a business problem, and every real business problem has technical causes that code can act on. If either half is missing, you don't yet understand the problem.

The Translation Process

Translation is a repeatable five-step walk, not a flash of insight:

1. Collect the business language. Quote the stakeholder's own words. "Proposals take a week" — don't clean it up too early.
2. Find the measurable outcome. What's the number hiding behind the words: cost, frequency, delay, error rate?
3. Follow the work. Trace the exact steps that produce that outcome. Who does what, in what tool, for how long?
4. Isolate the technical causes. Which step is manual, broken, duplicated, or waiting? What in the system produces the slowness?
5. Redraft in technical terms. State the problem as inputs and outputs, so an engineer can see the build.

A recurring shortcut is translating keywords:

Quantify Before You Translate

Translation needs a number. A quantity lets the customer and you agree the problem is real and is worth fixing, and it gives you something to measure against when the fix lands.

Look at the difference:

• Vague: "Proposals take too long."
• Sharp: "A lead engineer spends roughly eight hours per proposal assembling metrics from four systems to hit a three-week turnaround, and one in five proposals ship late."

The second version is still a business problem, but it has a number, a frequency, and a cost attached — which is exactly what you need to keep the eventual technical fix honest. Without a number, you can't know whether a change helped or hurt.

Working Example: From Business to Technical

Let's run the whole process on a real-sounding case: "Our support team is drowning and customers are getting angry."

Step by step:

Notice what happened: the complaint ("drowning, angry") became a buildable statement. The technical version reads like a brief — it names the cause (no unified view, nothing automated), the cost (60% of time, doubled load from reopens), and both of those give you your success metrics (cut assembly time, reduce reopens).

Note: the technical problem statement is the bridge into the requirements tutorial — it's where functional requirements come from. But it also answers the business question, because you kept the business numbers attached.

Symptoms, Causes, and Root Cause

A symptom is what the user feels and reports. The root cause is the mechanism underneath. FDEs skip down to the root cause, because treating a symptom makes it come back wearing different clothes.

Example peeling:

• Symptom: "Login is slow."
• First layer: authentication takes four seconds per attempt.
• Deeper: the auth service is a single server that saturates at peak.
• Root cause: no caching and no horizontal scaling on the auth path.

The business problem ("users abandon login at peak") becomes the technical problem ("auth has no cache and no scaling; p95 login latency is 4s during peak hours"). Each layer down gives you a more buildable target.

Best Practice: when you're chasing the root cause, walk backwards from the confessed problem. The true cause is usually upstream of where people complain — the data was stale before it ever reached the screen, the file was wrong before it hit the report.