Scoping a Vague Customer Problem: Questions Before Code

"We want AI to read our emails." A request like this is where most customer projects start, and it is rarely a problem statement. It is a solution, a technology and a hope, packed into one sentence. The first job of a forward deployed engineer is to unpack it before writing any code. This guide shows a way to do that in one or two conversations, and lets you try it on an invented customer.

The ask is not the problem

When a customer asks for a specific technology, they are describing what they think the fix looks like. Behind it sits a pain: something is slow, expensive, risky or annoying for a particular person. Your work is to walk down from the ask to the pain, and then to a number that would move if the pain went away.

Notice that the last step is small on purpose. A pilot you can finish in two weeks, with a person still checking the result, is easy for a customer to say yes to. It also produces the first real evidence about whether the bigger idea is worth pursuing.

Five areas worth a question each

• People. Who does this work today, who is hurt when it goes wrong, and who can say yes to a trial? Missing the person who can say yes is how a good pilot stalls.
• Data. Where do the records live, who owns them, and in what shape? A project that needs a clean ticket history cannot start in a shared inbox without a plan.
• Process. What happens today, step by step, and where does the time go? The slow step is often not the one the customer named first.
• Limits. What is not allowed: data that must stay in a region, a security review, a past attempt that damaged trust. These decide the size of the first step.
• Success. What would make this a win next quarter, and what is a late or wrong result worth? If there is no number yet, helping them pick one is part of the job.

Questions that change the plan

Not every question is equal. Some answers are interesting; a few change what you should build. A useful habit is to ask yourself, before you ask, what you would do differently if the answer were yes and what you would do if it were no. If both lead to the same plan, you can ask something else.

1. Where does the time actually go? The customer's first answer is often about volume. The better answer is about the step that waits.
2. What does a mistake cost? A wrong action that costs a penalty needs a human in the loop. A wrong suggestion that costs a click does not.
3. What is not allowed? Legal and security limits arrive late and slow everything. Hear about them on day one.
4. What did you try before? Past attempts tell you which failures the team will not forgive.
5. Who decides? A pilot under someone's own budget moves in days. One that needs a committee moves in months.

Try it: a call with a customer

The widget below is an invented call with an operations lead at a freight company. There are 12 things you could ask and only time for a few. 5 of them reveal a fact that changes what you should build first. Pick your questions, then choose a proposal and see how it holds up. Try it twice with different questions: the second time, the point is to notice which areas you skipped.

An invented scenario for practice. The customer, the numbers and the right answer are made up to teach the habit.

Write the problem down

After the call, write one paragraph and send it back to the customer. If they correct it, you just saved a week. A template that works:

For [the people who feel it], [the event] takes [how long] today, which costs [what]. We will try [one small thing] with [one team] for [two weeks], measured by [one number]. We will not [the limit we agreed].

Filled in for the freight example, it reads: "For the four dispatchers, finding the owner of an exception email takes hours, which can trigger service penalties. We will try a router that suggests the owner, with a dispatcher confirming, for two weeks, measured by minutes to the first owner. We will not send any customer reply automatically."

Common mistakes

• Solving the stated problem. Building exactly what was asked, when the pain is somewhere else.
• Asking only about the data. Engineers love data questions. People and limits decide whether the project survives.
• Skipping the success number. Without it, "it works" becomes an opinion.
• Proposing the big version first. A large plan invites a long review. A small one invites a yes.
• Keeping the notes to yourself. The written problem statement is shared; it is the first thing the customer can correct.

Practice on ScaleDojo

• In the HLD Lab, switch on Interview mode: it hides the requirements and makes you ask for them, the same habit as above. How to Structure Any Design Answer lists the questions to start with.
• Read what an FDE does for the whole loop this step belongs to.
• Once you know the problem, The Messy Data Day covers the first week of building.

What we know and what we do not

The five areas and the question habits here are our own framework, built from common practice in customer-facing engineering and from how our learners approach design prompts. They are not a company's published method. The call with the freight customer is invented, and so are its numbers. Real customers answer less cleanly, and you may get one good answer in a whole call. Use the framework as a checklist for yourself, not as a script to read out. Last reviewed in October 2026.