Lesson 2.1: Finding the real problem behind the request
Customers describe solutions, symptoms and numbers, not problems. Learn a four-layer ladder and five questions that find the real problem before you build.
By the end of this lesson you will be able to take a customer's request, such as "we need a chatbot" or "build us a dashboard", and work out what problem sits behind it. You will learn a four-layer ladder from request to outcome, five questions that move you up the ladder, and a one-sentence problem statement that you can test with the customer. You will see the method applied to three realistic requests and use a simulator to check whether the problem you found is worth solving. This is the first lesson of Module 2, which is about discovery and scoping. You should have read Module 1, but no technical skills are needed here. The skills are listening, asking and checking, and anyone can practise them.
Almost every customer project starts with a request, and almost every request is not the problem. It is a proposal: a solution someone has already imagined, a symptom they have noticed or a number someone has been told to improve. This is not carelessness. People describe the work in the terms they have, and those terms were formed before they met you. If you build exactly what was asked, you will often deliver something that matches the request and misses the need. The forward deployed engineer's first job is to find out which.
Why requests mislead
Requests go wrong in three common ways.
The solution in disguise. "We need a chatbot." A chatbot is a possible answer, not a problem. The request tells you what the customer imagines, but not why. If the real problem is that customers cannot understand their statements, a chatbot may not help at all, and a redesigned statement might.
The symptom. "Our approval process is too slow." Slowness is what is visible. The cause may be a missing document, a queue at one desk or a rule nobody remembers the reason for. Fixing the visible slowness without finding the cause usually moves the delay somewhere else.
The proxy number. "We need to cut call volume by 20 per cent." Call volume is a measure, and measures are chosen because they are easy to count, not because they are what the business wants. A team can cut calls by making the phone number harder to find. The number improved and the customer was worse off.
All three share a pattern: the request jumps ahead of the understanding. Your job is not to argue with it. It is to walk back down from the request to what is really going on, and then walk up again to an outcome you can aim at.
The four-layer ladder
A helpful way to organise this is a ladder with four rungs. You will often find that the customer starts at the first and has not yet visited the others.
1. The request. What the customer asked for, in their words. ("Build a chatbot for our support line.")
2. The problem. What is going wrong for a specific person, in a specific situation. ("Borrowers call us after every statement because they cannot tell what the charges are.")
3. The cause. Why that problem happens. ("The statement lists charges under internal codes that mean nothing to a borrower.")
4. The outcome. What would be different and measurable if the problem were solved. ("Fewer than one in ten borrowers calling about charges, and fewer complaints.")
The table shows the same ladder for three common requests.
Request · Possible problem · Possible cause · Outcome worth aiming at"Build a chatbot for the support line" · Borrowers call after each statement to ask about charges · Charges appear under internal codes · Fewer charge-related calls, lower complaint rate
"Make loan approvals faster" · Applicants wait days for a decision · Most of the wait is spent waiting for missing documents, not for processing · Shorter time from application to decision, fewer incomplete files
"Forecast our demand with AI" · Stores run out of popular items and over-stock slow ones · Orders are placed weekly using fixed rules, whatever the forecast says · Fewer stock-outs and less waste at the same service level
Look at the cause column. In each row, the cause suggests a different fix from the request: a clearer statement, a document checklist at the start of an application and a change in ordering rules. Sometimes the original request is still right. A chatbot might also help. But you can only judge that once you know the problem.
Five questions that move you up and down the ladder
You do not discover the problem by asking "what is your problem?" People answer with the request again. You discover it by asking specific questions about specific moments. These five work in almost any setting.
1. "Tell me about the last time this happened." Ask for a real, recent example, not a general description. A specific story contains details that a summary leaves out: who was involved, what was tried, how long it took. If nobody can remember a recent example, the problem may be smaller than the request suggests.
2. "And then what happened?" Follow the story to its end. People often stop telling at the point where their own responsibility ends, but the cost sits further on.
3. "Why?" Ask it again and again, gently. The method is old and sometimes called the five whys. It is usually credited to Toyota, where Taiichi Ohno described asking why five times, although some sources credit the company's founder Sakichi Toyoda. The number five is a rule of thumb, not a law, and critics point out that a chain of whys can follow one cause and miss others. Use it as a way to keep digging, not as a guarantee that you have found the single root.
4. "What would you do differently tomorrow if this were solved?" This question moves you from the problem to the outcome. The answer tells you what the customer is really buying. If they say "nothing would change", you have found a solution without a need.
5. "How do you know it is a problem, and how big?" Ask for numbers: how many, how often, how long, how much. If nobody has numbers, that is a finding. Estimating the size of the problem is part of your first week's work.
Two habits make the questions work. First, ask in the customer's setting, not in a meeting room: sit beside the person doing the work and ask them to show you. People describe their work in general terms, but they act in specifics. Second, write down their words exactly. When a customer says "the system is slow", write "the system is slow" and then ask what they mean. Do not translate it into your own words until you have checked.
Predict first: a retail bank's head of customer service tells you: "Call volume is too high. We need a chatbot to bring it down by 30 per cent." Before reading on, decide what your very first request to the customer would be.
The best first request is for data and examples, not a chatbot design: "Could I listen to a sample of twenty recent calls and see the reasons that agents record for each call?" That moves you from a solution toward the problem, and it costs the customer very little. If the calls turn out to be spread over hundreds of reasons, a chatbot may be right. If a few reasons dominate, a targeted fix may be far better, and cheaper. You cannot tell which without looking, and looking takes days, not months.
Worked example 1: the chatbot that was really about statements
A finance company asks for a chatbot to reduce calls to its support line, which receive about 10,000 calls a month. The forward deployed engineer asks for a month of call records and reads two hundred of them. Here is what they find, with the figures rounded and illustrative.
The agents tag each call with a reason. Of the 10,000 calls, about 3,000 are about charges on the monthly statement. About 2,000 are about the due date, 1,500 about making a payment, 1,200 about changing contact details, and the rest are spread across many smaller reasons. Listening to twenty of the charge calls shows the pattern: the borrower sees a line labelled with an internal code and does not know what it is. Agents spend four minutes per call explaining it.
The ladder now looks like this. The request is a chatbot. The problem is borrowers calling because they cannot read their statement. The cause is internal charge codes. The outcome is fewer charge-related calls. A chatbot could answer "what is code TXN-14?" but it would be answering a question that should not need to be asked. Changing the label on the statement is cheaper, and the chatbot might still help with the other reasons. The finding changes the project from "build a chatbot" to "fix the statement and then decide where a chatbot adds value", which is a better project for both sides.
Worked example 2: approvals that were not slow
A lender says: "Make loan approvals faster. They take five days." The forward deployed engineer does not start with software. They take thirty recent applications and trace each one from submission to decision, noting every time the file waited.
The picture, again illustrative, is that of the five days, about half a day is spent on processing: checks, scoring, sign-off. The remaining four and a half days are waiting. In about two-thirds of the files, the wait is for the applicant to send a missing or unreadable document. In the rest it is the file sitting in one queue because only one officer can approve a certain loan type.
Now the problem is different. Speeding up processing, for example with a faster scoring system, could at best save a few hours of a five-day wait. The real levers are catching missing documents at the start of the application and adding a second approver for the busy loan type. The customer's request to "make approvals faster" was right about the symptom and wrong about the cause.
Notice the method. The engineer did not ask people for their opinion about why approvals are slow. They traced real files. A trace of thirty cases is quick to do, and the evidence it gives is far stronger than a meeting.
The thirty traced files show where the five days really went. The chart splits them using the figures above.
Now try the fixes. Set how much of each wait a fix would remove and see the new total. A faster scoring system would touch only the first bar, which is why it would barely help.
At the defaults, the five days fall to two, a cut of 60 per cent, without any change to how fast the files are processed.
Worked example 3: the forecast that nobody could use
A retail chain asks for "an AI forecast of demand" for its stores. The engineer asks to see how ordering works today. Each store manager places an order once a week using fixed rules: order up to a set stock level for each item. The rules were written years ago. The head office has a forecasting team whose forecasts are good, but the forecasts are sent in a report that the ordering system does not read.
The cause of stock-outs is not that the forecasts are poor. It is that the ordering rules ignore them. A better forecast would change nothing until the rules change. The problem is the connection between a forecast and a decision, a lesson that matches the logistics story in Lesson 1.1. The project becomes: feed the existing forecast into the weekly order suggestion for ten test stores, and compare stock-outs with similar stores that keep the old rules.
The same lesson appears in all three examples. The request was a technology. The real problem was in how people and processes worked today, and the first useful step was to measure it.
Is the problem worth solving?
Once you have a candidate problem, one more question remains: how much is it worth? Some problems are real but small, and a pilot that fixes a small problem will not earn the customer's attention. A rough estimate takes a few minutes and tells you whether to go on.
The simulator below uses the call-centre example. Enter the monthly number of calls, the share of calls caused by the problem you found, how much of that share your fix would remove, the cost of a call and the cost of the fix. It shows the calls avoided each month, the money saved and the months to pay back the cost of the fix.
The numbers are illustrative. Use your own as soon as you have them, and notice how fragile the answer is: halving the share your fix removes doubles the payback time. That is why estimates should be rough but honest, and why the customer's own figures, replacing yours, are the first thing to ask for.
With the defaults, a fix that removes 60 per cent of the 30 per cent of calls caused by the problem avoids 1,800 calls a month. At ₹90 a call that is ₹1.62 lakh a month, and a ₹12 lakh fix pays back in about seven and a half months. Try lowering the share removed to 20 and see the payback stretch to about 22 months. This kind of quick arithmetic is often the difference between a project the customer champions and one that fades.
Writing the problem statement
When you think you have found the problem, write it down in one sentence in a fixed form, and show it to the customer. This is the test that tells you whether you have really understood. A useful form is:
[Who] cannot [do what] because [cause], which costs [how much] each [period]. Today it is [baseline]. A good outcome is [target].
For the first example: "Borrowers calling about statement charges cannot understand them because charges appear under internal codes, which costs about 3,000 calls a month and four minutes of agent time on each. Today about three in ten calls are about charges. A good outcome is one in ten or fewer."
Three things make a problem statement good. It names a person, not a department. It contains a cause that can be checked. It has a number you can measure before and after. If you cannot write the sentence, you do not yet know the problem, and you should go back and ask more questions. If the customer reads it and says "yes, that is it, and also…", you have found something real, and the "also" is often the most valuable part.
What to do when the customer disagrees
Sometimes you do the work and the customer does not accept your finding. They still want the chatbot. This happens often enough that it is worth planning for.
Show the evidence, not an opinion. Walk them through the sample of calls or the trace of files. Let them see the pattern themselves.
Keep their idea in play. You are not saying the chatbot is wrong. You are saying that the evidence suggests starting elsewhere, and that the chatbot can come next. People accept a change of order more readily than a rejection.
Offer a cheap test. If you and the customer disagree about what drives the calls, propose a two-week check, such as tagging calls in a more detailed way. A short test is easier to agree to than an argument.
Know when to proceed. If the customer, with full information, still wants what they asked for and it is harmless, build it. It is their business. Note your concern in writing and make the results measurable, so that the evidence will decide later.
Common mistakes
Building the request. Delivering exactly what was asked without finding the need is the commonest failure and the most expensive.
Asking "what is the problem?". It returns the request. Ask for the last time it happened.
Interviewing only one person. The head of a team describes the work differently from the people who do it. Talk to both.
Trusting opinions over traces. Ask to see real cases and real numbers. Opinions about causes are often wrong, including yours.
Stopping at the first cause. The first answer to "why?" is often a symptom of something deeper, and sometimes there is more than one cause.
Falling in love with your diagnosis. Hold it loosely and test it with the customer. A problem statement is a hypothesis.
Skipping the size of the problem. A real but tiny problem is not worth a pilot. Estimate it early.
Arguing instead of showing. Disagreement is settled by evidence the customer can see for themselves.
Key takeaways
A customer's request is usually a solution, a symptom or a proxy number, not the problem.
The four-layer ladder runs from request to problem to cause to outcome. Find all four before you build.
Five questions do most of the work: the last time it happened, what happened next, why, what would change tomorrow and how big it is.
Trace real cases and read real data. Evidence beats opinion, including your own.
Estimate the size of the problem early, because a real but small problem is not worth a pilot.
Write the problem as one sentence with a person, a cause and a number, and check it with the customer.
Check yourself
1. Name the four layers of the ladder.
The request, the problem, the cause and the outcome.
2. A customer says "make approvals faster". A trace of thirty files shows most of the five days is spent waiting for missing documents. What is the cause, and what does it suggest instead of faster processing?
The cause is missing or unreadable documents. It suggests catching them at the start of the application, not speeding up processing.
3. What is wrong with asking a customer "what is the problem?"
It tends to return the request again. Asking for the last time it happened gives specific, checkable detail.
4. With 20,000 calls a month, 25 per cent caused by the problem, a fix that removes 60 per cent of them and ₹100 a call, what is the saving each month?
20,000 × 0.25 × 0.60 = 3,000 calls avoided, so ₹3 lakh a month.
5. Why should you hold your own diagnosis loosely?
Because it is a hypothesis built on limited evidence. Testing it with the customer often adds causes you missed.
Try this
This exercise takes about forty minutes and needs one real person with a repeated problem: a colleague, a family business or a club.
1. Ask the person to name a task that is slow, error-prone or annoying. Write down their request in their exact words.
2. Ask: "Tell me about the last time it happened." Take notes without interrupting. Then ask "and then what happened?" until the story ends.
3. Ask "why?" at least three times about the most costly moment in the story. Write the chain.
4. Ask: "How often does this happen, and how long does it take each time?" Write the numbers, even if they are guesses.
5. Fill in the ladder: request, problem, cause, outcome.
6. Write the one-sentence problem statement and read it to the person. Note what they correct.
A good result is a one-page note with the original request, the ladder, the problem statement and a list of what the person corrected. If the problem statement differs from the original request, you have just done what a forward deployed engineer does in the first week of a project.
Sources
[Five whys](https://en.wikipedia.org/wiki/Fivewhys), Wikipedia. Used for the description of the method, its association with Taiichi Ohno and Toyota, the point that some sources credit Sakichi Toyoda, and the criticism that it can be too shallow. This is a secondary source, so treat the history as approximate.
The call-centre, loan-approval and retail examples, all figures and the simulator's defaults are the author's illustrations for teaching, not data from real companies.
Tags: Forward Deployed Engineer Discovery Problem solving Customer interviews Beginner