필사 모드: Translating "It Is Slow" into an Engineering Problem — FDE Customer Communication

• Customer Words Are Pain Reports, Not Bug Reports
• The Translation Questions — Five Axes
• Bad Answers, Good Answers
• Expectation Management — Change the Unit of Promise
• Communication in the Middle of an Incident
• Practice by Doing

Customer Words Are Pain Reports, Not Bug Reports

What one engineer would tell another as "p95 doubled," a customer says as "it is slow." The moment you treat that difference as the customer's fault, the FDE job goes sideways. Customers are under no obligation to describe symptoms precisely; by reporting their pain, they have done their part. Turning it into a measurable problem is entirely your job.

The mission titles in this blog's FDE Career RPG have exactly this shape: "it is slow," "we cannot connect," "sometimes login fails." Real field reports mostly arrive that way. This post covers the craft of moving those sentences into engineering. Every dialogue below is a constructed example built for illustration.

The Translation Questions — Five Axes

Cut "it is slow" along five axes and it becomes a measurable problem. Asking them in strict order feels like an interrogation, so weave them into conversation while mentally checking whether all five boxes are filled.

• Since when — once a start time exists, you can cross it against deploys, config changes, and traffic shifts at that time. "Has it always been this way, or did it start one day" is the first fork.
• Who, and where — everyone or some users, inside the office or outside, only users with a certain role? Scope narrows the suspect layer.
• Doing what — when logging in, when searching, when saving? This is the raw material of the reproduction path.
• How much — how many seconds, how many times out of ten? The box that turns adjectives into numbers.
• Compared to what — slower than yesterday, or slower than expected? Without a baseline you cannot even judge whether it got fixed.

With all five filled, "it is slow" becomes: since last Tuesday, only users connecting from outside headquarters, on report export, from the usual 3 seconds to 30, normal until the week before. That sentence is already half a diagnosis plan — it feeds straight into the reproduction step of the incident diagnosis playbook.

Bad Answers, Good Answers

In the same situation, some sentences drain trust and others build it. Three scenes, contrasted. All constructed examples.

The pattern shows. What bad answers share is defense: drawing the liability line first, escaping the room on groundless optimism, rejecting the customer's hypothesis at the door. What good answers share are three elements: facts confirmed so far, what is being done now, and the time of the next report. The third scene matters most. Even when the customer's hypothesis is wrong, treat it as something to verify rather than dismiss — that is what keeps customers telling you their observations next time.

Expectation Management — Change the Unit of Promise

Most expectation-management failures come from promising in the wrong unit. Saying "we will have this resolved by the afternoon" while the cause is still unknown is not a promise; it is a gamble. What you can promise is not a fix time but the time of the next report. "In one hour I will summarize what we know and what we do not" can always be kept, and every time it is kept, trust compounds.

Speaking in ranges follows the same principle. Give uncertain timelines as an optimistic-to-conservative range rather than a single time, and update the range as it narrows. And the worse the news, the earlier it should be said. Announcing a delay right before the deadline costs more trust than the delay itself. The FDE who delivers bad news two days early is remembered not as the person who slipped the schedule but as the person who managed it.

Communication in the Middle of an Incident

During an incident, peacetime rules invert. In peacetime you report finished analysis; mid-incident, an unfinished report on schedule beats a polished one late. The rules fit in four lines.

• Fix the cadence first. "I will report every 30 minutes until recovery" belongs in the very first message. Twenty minutes of silence doubles the outage inside the customer's imagination.
• Lead with impact. Save the cause analysis, however interesting. Who cannot do what right now, and is there a workaround — that comes first.
• Translate the jargon. Not "the pod is in a restart loop" but "the server keeps turning off and on, so connections drop."
• Do not make people the subject. Not "someone changed the setting wrong" but "after a configuration change." Blameless language is the safety device that keeps information flowing during an incident.

And escalation is not a confession of failure. Set yourself a rule in advance — no progress in 30 minutes means escalate — and the decision becomes procedure rather than emotion. To the customer, "we have brought in a specialist" reads as a signal of response, not incompetence.

Practice by Doing

Communication does not improve by memorizing sentences; it improves by speaking under pressure.

• FDE Career RPG — among its 8 domains, a low customer-communication level makes missions fail even with a correct diagnosis. The choices about when to report are this post's content in playable form.
• FDE Curriculum Roadmap — check the self-check criteria of the customer-communication domain.

FDE Complete Guide series

• Previous: The FDE Incident Diagnosis Playbook — Six Steps from Access to Report
• Next: Why PoCs Never Reach Production — Success Criteria, Security Review, Handover