How Forward Deployed Engineers Run Customer Discovery

Discovery is the highest-leverage part of forward deployed engineering and the least documented. Everything that follows, the scoping, the building, the trust, depends on whether you correctly understood the customer in the first place, and yet almost no one writes about how to do it well. The result is that many forward deployed engineers treat discovery as a formality, a few intro meetings before the real work begins, and then spend the rest of the engagement paying for that shortcut. This piece treats discovery as the skilled, decisive work it actually is.

Done properly, discovery is the difference between building the right thing and building the wrong thing efficiently. It is a learnable method rather than a personality trait, and the Forward Deployed Engineering Program teaches it as a core discipline because everything downstream depends on it. What follows is how experienced forward deployed engineers actually run it.

Key Highlights

• Discovery exists to find the gap between what the customer says and what is true, because the stated problem is rarely the real one.
• The most valuable information is usually undocumented: the workarounds, the constraints nobody mentioned, and the way work really happens versus how the process claims it does.
• Watching people actually do their work reveals more than any interview, because people describe an idealised version of their process and then work differently.
• Discovery is also political: understanding who decides, who champions, and who is threatened shapes what you can realistically build.
• Discovery never fully ends, but a focused opening phase before you commit to building is what protects you from scoping against a fiction.

Why discovery is the work, not the preamble

There is a temptation to see discovery as the throat-clearing before the real engineering, a box to tick before you start building. That framing is exactly why so many engagements go wrong. Discovery is not the preamble to the work. It is the work that determines whether all the later work is aimed correctly, and treating it as a formality guarantees you will aim wrong.

The reason is simple and consistently underestimated: customers do not hand you their real problem. They hand you the stated problem, which is a summary, filtered through their assumptions, their politics, and their incomplete understanding of their own situation. Beneath it sits the real problem, which is usually different, often larger, and always more specific. The entire job of discovery is to get from the stated problem to the real one, and that gap is where every misfired engagement begins. An engineer who invests seriously in closing it can build the right thing. One who skips it builds the wrong thing with great efficiency, which is the most expensive outcome in the role.

Look for the gap between what people say and what is true

The core skill of discovery is noticing the distance between stated reality and actual reality, because that distance is where the truth you need is hiding. People do not lie to you, exactly. They describe an idealised version of how their work happens, the version in the process document, the version they believe is true, and then they actually work in a different way full of exceptions and workarounds they have stopped noticing.

Your job is to find those gaps. When someone describes a clean process, look for the messy reality underneath it. When the documentation claims the systems work one way, verify how they genuinely connect, because the documentation is often aspirational or out of date. When a customer says the problem is one thing, keep probing until you understand why they believe that and whether it holds. The undocumented workarounds are especially valuable, because a workaround is a signpost pointing directly at a real problem someone solved unofficially. Following those signposts leads you to the genuine pain points, which are the ones worth building for. This gap-finding is what later makes technical scopingtrustworthy rather than a scope built on fiction.

Watch people work rather than only asking them

The single highest-yield discovery technique is also the most underused: watch people actually do their work rather than only interviewing them about it. Interviews give you the described process. Observation gives you the real one, and the two are reliably different in ways that matter enormously for what you build.

When you watch someone work, you see the workarounds they have stopped mentioning because they no longer register as unusual. You see where they hesitate, where they switch between systems, where they copy data by hand because the tools do not connect, where the official process quietly breaks and human effort fills the gap. None of this appears in an interview, because the person describing their job genuinely believes they follow the clean version. Sitting beside them as they work, with permission and genuine curiosity, surfaces the real texture of the problem in a way no amount of questioning can. This is also why the role requires physical presence and embedding rather than remote consultation, because you cannot watch the real work from a distance. The observation is a large part of what the genuine forward deployed role is built on.

Ask the questions that surface the truth

Interviews still matter, but the quality depends entirely on the questions. Weak discovery asks people to describe their process and accepts the answer. Strong discovery asks questions designed to surface the reality beneath the description, and knowing which questions those are is a large part of the craft.

Ask people to walk you through the last real instance of something rather than the general process, because specifics expose the exceptions that generalities hide. Ask what they do when the normal process breaks, because that is where the real workarounds live. Ask what the most frustrating part of their week is, because frustration marks genuine pain worth solving. Ask who else touches this work and what happens at the handoffs, because the seams between people and systems are where problems concentrate. And when someone states a constraint or a requirement, ask why it exists, because half the time the reason has evaporated and the constraint is removable, while the other half reveals something essential you would otherwise have missed. These questions do more than gather information. They earn you the reputation of someone who actually understands the work, which is what makes people tell you more.

Discovery is political, and ignoring that is naive

Technical discovery is only half the job. The other half is understanding the human and political reality of the organisation, because that reality determines what you can actually build and deploy regardless of how good your solution is. An engineer who understands the systems perfectly and the politics not at all will still fail, because the politics decide whether the work ever ships.

So discovery has to map the people as carefully as the systems. Find out who genuinely makes decisions, which is often not the person with the title. Identify who champions the project and who feels threatened by it, because a threatened stakeholder can quietly kill excellent work. Understand the customer's internal incentives, what makes the people you are working with look good or bad to their own bosses, because your solution has to help them succeed on their terms. This is not cynicism. It is the honest recognition that software is deployed inside human organisations, and understanding those organisations is part of engineering for them. The forward deployed engineers who neglect this are repeatedly surprised when technically sound work fails to land, and the surprise is avoidable.

How to earn the access that discovery depends on

Everything in discovery depends on access, to people, to systems, and to the truth, and that access is granted rather than given. A customer who does not trust you shows you the sanitised version: the tidy process document, the demo environment, the stakeholders who will stay on message. A customer who trusts you shows you the real thing, warts and all. So a large part of discovery is earning the access that makes discovery possible, which is a chicken-and-egg problem the best engineers solve deliberately.

You earn it by being useful and trustworthy early, before you have earned the right to the deepest access. Demonstrating genuine curiosity about how the customer's work really happens, respecting the expertise of the people doing it, and showing that you are there to help rather than to judge all build the trust that opens doors. Small acts matter: taking notes seriously, following up on what people tell you, and never making someone feel foolish for revealing how things really work. This is why discovery and relationship-building happen together rather than in sequence, and why the opening phase of an engagement treats them as a single intertwined effort. The engineer who earns deep access learns the truth. The one who stays at arm's length gets the brochure, and builds accordingly.

Discovery for AI projects has its own traps

When the thing you are deploying is an AI system, discovery carries extra hazards that are worth naming, because AI projects fail in specific ways that thorough discovery can prevent. The central risk is that the customer's expectation of what the AI can do is miscalibrated, in either direction, and if you do not surface that during discovery, the whole engagement is built on a misunderstanding.

Discovery for an AI deployment therefore has to probe not just the process and the systems but the data and the expectations. Where does the data actually live, how clean is it really, and can you even access it, given that so many enterprise environments are half-documented and tightly governed. What does the customer imagine theagentic system will do, and is that realistic given their data and constraints. Where in their real workflow would the AI genuinely help, as opposed to where it sounds impressive. These questions are the difference between an AI project that ships value and one that becomes another stalled pilot, and they only get answered by the same disciplined discovery applied specifically to the realities of data and model behaviour. The applied side of this is core to serious AI engineering, and discovery is where it starts.

Know when you understand enough to build

Discovery never fully ends, because understanding deepens throughout an engagement, but there is a point where you understand enough to start building responsibly, and recognising it is part of the skill. Staying in discovery forever is its own failure, an over-caution that never ships. The goal is not total understanding, which is impossible, but sufficient understanding to build the right narrow thing next.

You know you are there when you can state the real problem in your own words in a way the customer recognises as more accurate than their original framing, when you understand the systems well enough to know where a solution would actually fit, and when you know who needs to support the work for it to succeed. At that point, further discovery has diminishing returns and the better move is to build a small, real thing and learn from how it lands, which is itself a form of discovery. The first ninety days framework builds this in deliberately, using an early narrow win to validate understanding. Discovery and delivery are not separate phases so much as a loop, and knowing when to move from one to the other is a judgement experienced engineers develop.

The discovery mistakes that quietly sink engagements

It helps to name the specific ways discovery goes wrong, because they are consistent and avoidable once you can see them coming. The first and most common is accepting the stated problem at face value and building against it, which produces an efficient solution to the wrong thing. The second is confusing being told about the work with understanding it, taking the interview description as truth when the reality on the ground differs.

The third is neglecting the political map, understanding the systems perfectly while missing the stakeholder who will block deployment, so that technically sound work never ships. The fourth is staying in discovery too long, using the comfort of learning to avoid the risk of building, until the customer loses patience. And the fifth, subtler than the rest, is doing discovery once at the start and then treating it as finished, when in truth understanding should keep deepening throughout the engagement as you learn things no opening phase could have surfaced. Each of these failures is avoidable by an engineer who knows to watch for it, which is why naming them is useful. The forward deployed engineers who run discovery well are not the ones with a magic technique. They are the ones who avoid these five predictable mistakes, and who treat discovery as the disciplined, ongoing core of the role that the Forward Deployed Engineering Program teaches it to be.

What good discovery produces

It helps to be concrete about the output, because discovery without a clear product drifts. Good discovery produces a small number of specific things that everything downstream relies on, and if you cannot produce them, you are not done.

These outputs are what you carry from discovery into scoping and building. An engagement that produces them is aimed correctly. One that skips them is guessing, however confident the guesses feel.

It is worth writing these down rather than holding them in your head, both because the act of writing forces you to notice what you do not actually know yet, and because a written picture of the real problem and the human map is exactly what you will need when you hand the work on or bring colleagues into it. Discovery that lives only in one engineer's memory is fragile, and it evaporates the moment that engineer moves to another account. Capturing it turns your understanding into something the whole engagement can rely on, and it becomes the foundation the later building depends on, whether that is a simple integration or a fullintelligent agentdeployment, which is a small discipline with a large payoff.

The bottom line

Customer discovery is the highest-leverage work a forward deployed engineer does, and its purpose is to close the gap between the stated problem and the real one. Find the distance between what people say and what is true, watch people actually work rather than only interviewing them, ask the questions that surface reality rather than the described process, and map the politics as carefully as the systems, because both decide what you can build.

Discovery is a loop rather than a phase, and you move from understanding to building when you can state the real problem more accurately than the customer first did and know where a solution would fit. Done well, it produces a clear picture of the real problem, the true systems, the human landscape, and a candidate first win. It is a learnable discipline rather than a knack, and building it properly through the Forward Deployed Engineering Program or by grounding yourself in the applied skills of agentic AI development is what turns discovery from a formality into the advantage it should be.