FDEInterviews logoFDE/Interviews

The stated request is a symptom. The workflow underneath is the problem.

Customers ask for a solution they have already imagined, and building it is the most common way an engagement fails politely. Discovery is the work of getting from the stated request to the workflow that actually costs them something.

13 MIN

TL;DR: A customer's request is a solution they already picked, not the problem they have. Build it literally and you will ship something correct that nobody needed. Discovery means watching the work until the expensive step becomes obvious.

Where you are. Module two, first lesson. You know the shape of an engagement. This is stage one, and the one that quietly determines whether the other seven were worth doing.

Why the request is never the problem

Someone says: we want a chatbot over our documentation. That sentence has already made four decisions. It picked an interface, a data source, an interaction model, and by omission it decided that the problem is people not finding documents.

The person who said it is not being careless. They are being helpful. They have translated a frustration they feel every day into the nearest solution they have seen elsewhere, because that is what a reasonable person does when asked what they want. The translation is where the information gets lost.

Underneath that request there is a workflow: a real sequence of steps a real person performs, with a step in it that costs far more than it should. Sometimes the chatbot addresses it. Often the expensive step turns out to be that two systems disagree about customer identifiers and somebody reconciles them by hand every morning, and no chatbot over documentation touches that at all.

Building the stated request is the most polite way to fail. Everyone is satisfied at each milestone, the demo goes well, the thing ships, and adoption is near zero because the expensive step is still there. Nobody will tell you this happened. You find out from the usage logs, which do not do politeness.

"We want a chatbot" a solution, already chosen watch the work sit with the operator count the cost hours, errors, delay The expensive step reconciling two systems by hand SKIPPING DISCOVERY: SHIPS, NOBODY ADOPTS

Three questions that do the work

Discovery is not a personality trait. It is a small number of questions asked in a particular order, and they work because they are hard to answer with a solution.

Walk me through the last time you did this. Not "how does the process work", which produces the idealised version that lives in a document. The last specific instance produces the exceptions, the spreadsheet nobody mentions, and the step where they said "and then I usually just fix it manually".

How long does that take, and how often? Frequency times duration is a number, and a number tells you whether this is worth a deployment. It also, quietly, gives you the baseline you will be measured against later, which is much harder to establish after you have shipped something.

What happens if this stays exactly as it is? If the honest answer is "not much", you have found something that is annoying rather than expensive, and annoying does not survive a security review. The projects that get finished are the ones where somebody can articulate a real cost of inaction.

Ask them of the person who does the work, not only the person who signed the contract. Those are usually different people, and they describe different problems.

Watching beats asking

The strongest discovery move is not a question. It is asking to watch somebody do the job for twenty minutes.

People are unreliable narrators of their own workflows, not from dishonesty but because expertise makes steps invisible. The analyst who says "I pull the report and check it" performs eleven distinct actions. Three of them correct the same recurring data problem. None of the eleven will be mentioned, because to the analyst they are not steps. They are just what pulling the report means.

You will see the workaround they have stopped noticing. That workaround is usually the deployment.

Palantir's old vocabulary for the deeper version of this habit is the ontology: model the customer's world, their entities and the relationships between them, in their language, before you compute anything. The word is theirs. The habit is universal, and it is what every retrieval or agent design question is secretly testing.

Do this before moving on

Pick a process you know well from your own work, ideally one you would describe in a single sentence. Write out every action it actually takes, including the ones you would not normally mention. Then count how many of those steps exist only to compensate for something being broken upstream. That ratio is what you are looking for in someone else's workflow, and it is why watching beats asking.

Go deeper

Key takeaways

  • A stated request is a solution the customer already chose, so building it literally is the most common polite failure.
  • Ask for the last specific instance rather than the general process; the general process is the idealised version.
  • Frequency times duration turns a complaint into a number, and that number is also your baseline for later.
  • Watch someone work for twenty minutes. Expertise makes steps invisible, and the workaround they no longer notice is usually the deployment.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

  1. 1A director asks for a chatbot over their documentation. What is the first thing you should do?

  2. 2Why ask 'how long does that take, and how often' during discovery rather than later?

  3. 3Why is watching someone work more reliable than asking them to describe their workflow?

Sign in to track which lessons you have finished.