The title and description of a customer case don't tell me the problem. They tell me what the developer thinks the problem is.

1. App Malfunctions as Symptoms

If you go to the doctor and tell them you have a cough, they don't just give you cough syrup and send you home. The cough isn't the illness; the cough is the symptom of the illness. The true medical expertise is bridging that gap - identifying the illness and a treatment plan, dealing with the symptom at the cause.

If you show up to the doctor and explain you've been reading WebMD and you've already concluded what medical malady you're suffering from, you should expect them to take a critical view, and start at ground zero.

The same thing happens in technical troubleshooting. Your customer may be an expert, but they may start the story in the middle, and jump straight to “High CPU,” mistaking correlation for cause.

2. Why the customer is usually not correct, and why recognizing that matters

In a scenario like our 'High CPU' story above, there are two related problems:

• The real problem is something else - in this case, slowness - if you 'fix' the CPU and the slowness is still there, you've failed.
• A logical leap has already been made by the customer - and often assumed by the engineer - by starting in medias res. They saw a correlation between CPU and Slowness and concluded one caused the other, post hoc ergo propter hoc. After, therefore, because of.

The combination leads to frustration for everyone involved. The customer won't feel heard, because either you're ignoring what they're saying (in service of the real problem) or you didn't fix the actual problem. The engineer ends up chasing ghosts, fighting the customer’s assumptions instead of the actual problem.

Recognizing this leads you to the answer, though it's not one engineers always want to hear - talk to the customer and spend more time understanding their problem. I don't care if you use some fancy scheme or plan to do so (5 Whys or KT or whatever), but figure out what's really going on. What's the impact to the customer. Who do they answer to. What pre-existing biases or beliefs do they have about the services they're using?

If you don't take the time to understand the real problem, you're blindly throwing darts and hoping for a good customer experience.

3. Why it's important to listen to what the customer says anyway

What the customer does have that I won't ever have - because I see thousands of apps and incredibly rarely do I see the same one twice - is context of their particular app/ecosystem and its history. It is not uncommon for some indication of that history - at least hints that there is history - to sneak into the initial title and verbatim. For example, in Azure App Service, it's not uncommon for multi-tenant apps to eventually run into SNAT port exhaustion. Customers may have applied quick workarounds that solved one issue while planting seeds for another. If you've seen a hundred different apps that all took the quick way out and found themselves in trouble later, you can anticipate the pattern. If you've seen one or two apps have the problem at all, you may not make the connection.

In other words, I don't read the verbatim expecting to find the 'real answer' or 'real problem,' but by seeing where they think the problem is, I can guess at - and then ask about - app history, previous issues and mitigations, biases, etc.

4. How to get to the real issue

ASK: How does this affect your users?

This takes the error or metric or whatever they're focused on, and reorients it back to app behavior. Every unhappy app is unhappy in its own way; if you don't ask, you won't know, and you can't move intentionally to fix it.

Beyond just fixing it, part of the whole experience is the narrative explaning what happened and why. If you can't relate that narrative back to a grounding point that anchors the impact to their business, you lose leverage.

ASK: How does this affect your business?

Some people don't like to ask this, like if they don't know how much money the customer thinks they're losing it will somehow make things easier. The truth of the matter is that in order to understand and assess your customer's urgency, you must know the impact to their business. As with the previous questions, this is key grounding for the narrative as well.

ASK: What are you trying to do?

Curiousity and Empathy overlap in the scoping and assessing phase, opening the door to context, history, and rapport. When you show you're interested in addressing their real issues (grounded in impact) and show interest and curiosity on top of that understanding, you position yourself as a trusted advisor, which will smooth any roughness in the process moving forward.

Conclusion

Customer case titles rarely reveal the real problem—they reveal the customer’s perspective on it. Symptoms, assumptions, and history all shape that perspective, but they can also mislead. The engineer’s job isn’t just to chase metrics or fix what’s on the surface; it’s to bridge the gap between what the customer thinks is happening and what’s actually impacting their users and business. That means listening carefully, asking the right questions, and anchoring solutions in real impact. Every unhappy app is unhappy in its own way, and the only way to get it happy again is to understand that story first.