The customer says the dashboard is slow, but what they lack is conversion: a discovery lesson for FDEs

A customer complains that a dashboard loads slowly. A good engineer’s reflex is to open the profiler, inspect the queries and add a cache. But if what the customer really needs is conversion, latency is only a symptom, and an FDE can burn an entire engagement shaving off milliseconds without touching any of the customer’s goals.

Kevin B., an FDE at Rippling, sums up the lesson in one sentence: the problem is rarely the problem. In his view, what the customer tells you is the symptom.

If you are hoping to move into an FDE role, this is the skill that separates you from an engineer who takes tickets. Educative’s FDE course describes discovery as a structured technical investigation, conducted as a conversation. The point of a discovery session is to understand the problem, not to show how the FDE will solve it.

Three ways customers hide the real problem

Educative notes that customers rarely describe their real constraints in the first conversation. Instead, they open with a symptom, a solution they have already chosen, or a vague outcome. All three are valid starting points, but none of them is a spec.

Back to the dashboard. “It loads slowly” is a symptom. “We need a caching layer” is a pre-chosen solution. “We want to grow revenue this quarter” is a vague outcome. All three sentences can come from the same person in the same meeting, and if you take any of them as the brief, you are building whatever is easiest to ticket rather than whatever is most right.

That is why Educative describes the FDE’s job as working backwards from that description to the workflow problem underneath. Imagine following up: who opens the dashboard, at what time, and what do they do after looking at the numbers?

The answers might reveal that the sales team only looks at the dashboard each morning to decide whom to call first, and that the real slowness lies not in the query but in lead data arriving half a day late.

Workarounds are a map to the pain

There is one clue worth more than any complaint: what users do themselves when the official process does not work. Educative calls workarounds the clearest signal of where the real operational pain lies.

An Excel file exported by hand every morning, a Slack channel for asking about numbers, a colleague assigned to “watch” the dashboard: each is a ready-made map, waiting for you to read it.

To read it, the questions have to change direction. The first rule of The Mom Test, Rob Fitzpatrick’s book as reviewed by Yevgeniy Brikman, is to talk about their life rather than your idea. The next rule: ask about specifics in the past rather than generic opinions about the future.

The difference sounds small but determines the quality of the evidence. “If the dashboard were faster, would you use it more?” yields only a polite promise. “The last time the dashboard was slow, what did you do next?” yields behaviour that actually happened, and very possibly the workaround you are looking for.

Palantir once expected its FDEs to work at customer offices three to four days a week. Nabeel Qureshi, who has written about his experience there, argues that being onsite is what gave FDEs a detailed understanding of business processes in difficult industries, which they then used to design software that solved the right problem.

Workarounds rarely surface on a Zoom call; they surface when you sit next to the person opening Excel.

The customer owns the problem, you own the solution

There remains a tension FDEs deal with daily: who gets to decide what. The Mom Test sets out a deal: you do not get to tell customers what their problem is, and in return they do not get to tell you what to build.

PostHog’s FDE handbook, meanwhile, says that sometimes the right move is to correct the customer’s mental model rather than build exactly what they asked for.

These two principles do not conflict; they divide the territory. The pain belongs to the customer: you do not argue that the dashboard is not slow. The solution belongs to you: when the customer insists on “adding a cache”, you have the right and the responsibility to put the evidence on the table and show that a cache will not make leads arrive any sooner.

PostHog adds one more point: solve the real problem, not the one easiest to ticket. The cache is the easy-to-ticket problem. Redesigning the lead data flow so the sales team has its numbers by 8am is the real problem, much harder to write up as a ticket, but it is what makes the customer remember you.

Practise before you have the title

You do not need the FDE title to start. The next ticket from a PM or an internal customer is a miniature discovery session: before coding, ask when this last happened, how they coped, and who uses the final output.

Restate the problem in your own words in one paragraph and send it to the requester to confirm; if they correct it, you have just found the gap between the symptom and the problem.

When reading job descriptions, look for words such as discovery, scoping, customer workflow and onsite. When you see them, have a story ready about a time you went looking for the problem rather than being handed it.

On a CV, the most convincing way to tell the story is not “optimised latency by 40%” but “the original request was X; after investigating, I built Y, because Z”.

That sentence shows the interviewer you can tell a symptom from the disease.

The next ticket you receive may still say “dashboard is slow”. Your job is to find out who is opening Excel to make up for it.