Forward deployed engineering, Part 2: Discovery, from a business problem to something you can build

In Part 1 I described what a forward deployed engineer (FDE) does and how an engagement runs: embed, discover, build, harden and hand over. This part is about the second of those steps, discovery, because it decides whether the other three are worth doing.

In my work with partners, the projects that struggle rarely struggle because of the model. They struggle because the team started building before anyone agreed what problem they were solving, for whom, and how they would know it had worked. A good prototype of the wrong thing is still the wrong thing, and it usually takes a few weeks before anyone notices.

I start with the basics: what discovery is and the handful of terms you need. Then I follow one realistic request at Acme Consumer Brands, our fictional company, from a vague ask to a one-page brief that the sponsor signs before any code is written.

If you prefer to watch first, here is the heart of this part as a short animated explainer.

Video: how discovery turns a vague ask into a one-page brief you can build and measure, in three minutes. The narration is a synthetic voice; the script and animation are mine.

Where does this show up in an FDE job description?

Public FDE postings ask for discovery directly, in slightly different words:

Google Cloud’s Forward Deployed Engineer, GenAI posting lists “Experience leading technical discovery sessions” as a minimum qualification.
Google Cloud’s AI Outcome Customer Engineer, Forward Deployed Engineering posting asks you to “assess project feasibility, shape proposals for long-term adoption, and validate FDE engagement requests.”
OpenAI’s Forward Deployed Software Engineer posting asks you to “embed deeply with strategic customers to understand their business challenges and technical requirements in detail” and to “prepare detailed scopes of work and project plans for both proof-of-concept prototypes and full production deployments.”

Read together, these lines describe one skill: turning a conversation about a business into a scope that engineers can build and a sponsor can measure. That skill is discovery.

What is discovery?

Discovery is the work you do before building, to find out which problem is worth solving and whether you can solve it.

A more precise version, the one I use: discovery is a time-boxed phase (it has a fixed end date, usually one to three weeks) that produces five things the customer agrees to in writing. Each one is a term you will meet again in this series:

A problem statement: one paragraph saying who has the problem, what happens today, what it costs and what better would look like.
Success metrics: the numbers that will show whether the work helped. A business metric measures an outcome the business cares about, such as lost sales. A technical metric measures the system, such as how often its figures are correct. Each needs a baseline (its value today, measured before you change anything).
A feasibility assessment: whether the data, access, technology and organisation make the problem solvable in the time available.
A use case: one specific job the system will do for one group of users. Discovery picks the first one.
A scope: what is in, and just as important, what is explicitly out.

All five go into the engagement brief, a one-page document the sponsor (the senior person who owns the outcome and the budget) signs before the build starts.

A useful comparison is a visit to the doctor. The patient arrives saying “I need antibiotics.” That is the ask. The doctor asks about symptoms and history (discovery), names the condition (the problem statement), picks a treatment (the use case) and books a follow-up to check it worked (success metrics against a baseline). A good doctor sometimes says “you do not need antibiotics”, and a good FDE sometimes says “you do not need an agent”.

discovery narrows a vague ask into a one-page brief: the ask becomes a problem statement, the problem gets success metrics, a feasibility check, one first use case, and finally a brief the sponsor signs before any build starts

What does Acme actually want?

Acme Consumer Brands is the fictional consumer goods company from the Production-ready agents series. It is running a campaign called Acme Pure Refill Launch in Western Europe. Marketing data lives in BigQuery on Google Cloud and supply data lives in Databricks, so each team sees half of the story. Marketing sees EUR 283,590 of spend and good click-through. Supply sees on-time-in-full (OTIF) delivery (the share of orders that arrived on time and complete) of 87.4% and EUR 36,026 in retailer penalties in Western Europe (EUR 51,331 across Western and Southern Europe). All of these figures are made up.

The request that reaches the FDE is one sentence: “We want an AI agent that joins up marketing and supply.” In the agents series, that ask becomes a router and two specialist agents. This post is the conversation that happened before any of that code existed.

How do you turn an ask into a problem statement?

An ask almost always names a solution (an AI agent). A problem statement names a person, a cost and a target. You get from one to the other by asking about the work, not about the tool.

an ask names a solution; a problem statement names who has the problem, what happens today, what it costs and what better looks like, which is what you can design and measure against

These are the questions I find most useful in the first meetings:

“Tell me about the last time you needed this.” A specific recent event gives you real steps, real systems and real delays. A general description gives you the official process.
“Show me.” Sit with a user while they do the task. At Acme, Maria in brand management sends a request to an analyst, who exports a campaign report from BigQuery, asks the supply team for an OTIF extract from Databricks and joins the two in a spreadsheet.
“What would you do differently with the answer?” If nobody can name a decision that changes, the problem is not worth an engagement.
“How often, and how long?” Counting turns a complaint into a cost.

This is the analyst’s spreadsheet from step 2, for the first four weeks of the campaign:

the spreadsheet the analyst builds by hand today: campaign spend exported from BigQuery next to OTIF from Databricks, one row per week for Acme Pure Refill Launch in Western Europe, with the seven-week total

Prerequisite 2: The business terms and the data behind the agents explains every column and how the two tables join.

Written up, Acme’s problem statement reads like this:

Brand managers and supply planners in Western Europe cannot see campaign spend and supply performance together. Today they ask an analyst and wait about two days for a joined-up answer, so promotions keep running while stock runs out. Better looks like a same-day answer, in their own words, with figures both teams trust.

The two-day wait is illustrative here. In a real engagement it would be a number you measured, which brings us to metrics.

Who do you need to talk to?

A stakeholder is anyone who can help, use, approve or block the work. In discovery you need five groups, and each one gets a different question.

the five groups to meet in discovery and the one question to ask each: the sponsor about the decision, users about today's work, data owners about who may see what, security about what must never leave, and the platform team about where it can run

The executive sponsor owns the outcome. Ask which decision gets better.
The users do the work today. At Acme these are Maria in brand management and Sam, a supply planner. Watch them work.
The data owners decide who may read which table. At Acme the supply data team owns the Databricks tables, including retailer penalties, which only supply may calculate.
Security and risk decide what must never leave and what has to be logged.
Platform and IT decide where the system can run, which identity provider it uses and how it reaches the data. Part 3 is about this group.

The group I see missed most often is the data owners, who rarely attend the kick-off but hold the access you need in week two.

How will you know it worked?

A success metric is a number that moves if the work helps. You need metrics at more than one level, because each level answers a different person’s question.

Google Cloud’s guide KPIs for gen AI groups metrics into model quality, system quality, adoption and business value. It also warns that teams often confuse operational efficiency gains with end goals. Google’s Rules of Machine Learning put it even earlier, as Rule #2: “First, design and implement metrics.”

I draw the metrics as a tree, so that every technical number links to a business one:

a metric tree for Acme: technical metrics such as correct figures and latency feed adoption and behaviour metrics such as weekly users and decision time, which feed the business outcome of fewer lost sales; cost per question goes into the business case

Business outcome (a lagging indicator, one that moves slowly and late): fewer lost sales from stockouts during campaigns. The business measures this, not the FDE.
Adoption and behaviour (leading indicators, which move early and predict the outcome): weekly active users, questions answered without an analyst, and time from question to decision.
Technical metrics, which the build controls: correct figures on a set of golden questions, routing to the right specialist, p95 latency (the response time that 95% of answers beat) and cost per question. Part 10 of the agents series shows how to measure the first two automatically.

Every metric needs a baseline, measured before you build. At Acme, the analyst team’s request queue already records when each request arrived and when it was answered, so the two-day figure can come from real timestamps. Without a baseline you can show that the agent is fast, but you cannot show that anything improved.

Is it feasible?

Feasibility means checking that the problem can be solved with the data, access, technology and people that actually exist, in the time you have. I run four checks.

four feasibility checks before you commit: does the data exist and is it good enough, can the agent get access, can a model do the language part with code doing the rest, and will the organisation adopt and own it

Data. Ask to see twenty real rows from each source. Check for gaps, late loads and metrics with two competing definitions. At Acme both tables exist, and supply has published the OTIF formula.
Access. Find out who approves access and how long a new grant takes. At Acme, the supply agent must read Databricks as the signed-in user, which needs an OAuth app that Acme’s identity team has to approve. That is the one amber check, and it goes in the risks section of the brief. Part 7 of the agents series shows why.
Technical. Ask whether a model is needed at all, and for which part. Rule #1 of Google’s Rules of Machine Learning is “Don’t be afraid to launch a product without machine learning.” The People + AI Guidebook makes a similar point: find where user needs and AI strengths overlap. In this series the rule is that models read and write language, and code makes the decisions. At Acme, a model is needed to understand the question and write the answer, but which team may see penalty figures is a rule in code.
Organisation. Check that someone will own the system after you leave, that users have time to test it, and that the sponsor will make a decision on a date.

How do you choose the first use case?

Most discovery sessions produce more ideas than one engagement can deliver. Place each candidate on two axes: business value and feasibility. The first use case should be high on both.

choosing the first use case: five Acme candidates placed by business value and feasibility; the campaign cost of stockouts is high on both, so it goes first, while automatic replanning and a new forecasting model are valuable but not feasible yet

For Acme, the candidates were:

A. The campaign cost of stockouts. It answers the sponsor’s question, it is read-only, it needs two sources that both have clear owners, and it can be tested with golden questions. This one goes first.
B. Automatic supply replanning. It is valuable, but it changes data and needs a human approval step. It comes back later, with the approval step from Part 9 of the agents series.
C. Chat over the brand guidelines. It is easy, but nobody is waiting for it, and nobody could name a metric it would move.
D. A new demand forecasting model. It is valuable, but it is a data science project measured in months, with no owner identified.
E. Summarising the weekly sales email. It is easy and saves a few minutes a week.

My rules of thumb for a first use case are these: read-only before read-write, one clear owner for each data source, a metric you can baseline this month, and a result the sponsor will see.

What data and access questions should you ask?

These questions come up in every engagement I have worked on. I ask them for every data source in the first use case, during the first week:

For each data source in the first use case:
  1. Where does it live? (system, project, region)
  2. Who owns it, and who approves access?
  3. Is there one agreed definition for each figure we will quote?
  4. How fresh is it, and who notices when a load is late?
  5. Does it contain personal or confidential data?
  6. Will the agent read it as itself, or as the signed-in user?
  7. How long does a new access grant usually take here?
  8. Can we see twenty real rows this week?

Questions 1, 5 and 6 are design questions as much as discovery questions, and Part 3 picks them up.

When should you say no?

Saying no is part of the job. A forward deployed engineer is valuable because they can tell a sponsor, early and kindly, that a particular plan will not work. These are the situations where I say no, or not yet:

There is no owner after handover. A system nobody owns will stop working within months.
The data does not exist, or nobody may read it. That is a data project, and it should be scoped as one.
Nobody can name a decision that changes. The agent would be a demonstration, not a tool.
The success metric cannot be measured. You will not be able to prove anything at the end.
A model is being asked to make a rule-based decision. Permissions, approvals and calculations belong in code. The model can still explain the result.

The way to say it matters. I use “no, and here is what I would do instead”: a smaller scope, a non-AI fix, or a data task that has to happen first. At Acme, the sponsor first asked for an agent that would “replan supply automatically when stockouts appear”. The answer was not in phase one: start read-only, prove the figures are right, then add replanning with a human approval step.

What goes in the one-page engagement brief?

The engagement brief records everything discovery agreed on one page. It is short on purpose: if it does not fit on a page, the scope is too big. This is Acme’s, with illustrative targets:

the one-page engagement brief for Acme, with illustrative targets: the problem in the users' words, one first use case, what is out of scope, success at three levels, a baseline, and a dated go or no-go decision

A few fields deserve a comment:

Out of scope is the most useful line in the document. When someone asks for forecasting in week five, you point to it.
Success has a business, an adoption and a technical line, matching the metric tree. The targets here are illustrative; in a real brief they come from the baseline and the sponsor.
Decision has a date. At the end of week two the sponsor decides to go ahead or to stop, based on the prototype and the first technical measurements.
Owner after handover names a team, so it survives a reorganisation.

Try it: score your own use cases

This script ranks candidate use cases. It uses only Python 3, with no extra packages. Save it as score_use_cases.py:

# name, value, data, access, effort (each 1 to 5, 5 is best), owner after handover, measurable
CANDIDATES = [
    ("Campaign cost of stockouts", 5, 4, 3, 4, True, True),
    ("Automatic supply replanning", 5, 3, 1, 1, True, True),
    ("Chat over brand guidelines", 2, 5, 5, 5, True, False),
    ("New demand forecast model", 4, 2, 3, 1, False, True),
    ("Summarise weekly sales email", 1, 5, 5, 5, True, True),
]


def feasibility(data, access, effort):
    """The weakest check sets the pace, so use the minimum, not the average."""
    return min(data, access, effort)


def blockers(owner, measurable):
    reasons = []
    if not owner:
        reasons.append("no owner after handover")
    if not measurable:
        reasons.append("no measurable success metric")
    return reasons


rows = []
for name, value, data, access, effort, owner, measurable in CANDIDATES:
    stop = blockers(owner, measurable)
    score = 0 if stop else value * feasibility(data, access, effort)
    rows.append((score, name, stop))

for score, name, stop in sorted(rows, key=lambda r: r[0], reverse=True):
    note = "blocked: " + ", ".join(stop) if stop else ""
    print(f"{score:>3}  {name:<30} {note}")

Run python3 score_use_cases.py. When I ran it, the output was:

 15  Campaign cost of stockouts
  5  Automatic supply replanning
  5  Summarise weekly sales email
  0  Chat over brand guidelines     blocked: no measurable success metric
  0  New demand forecast model      blocked: no owner after handover

The scores are my judgement for the fictional Acme. Then try these changes:

Score three ideas from your own organisation. If every idea scores 5 for data, you have not looked at the data yet.
Change min to an average in feasibility. Automatic replanning jumps up the list even though one check is at 1. This is why I use the weakest check: one blocked approval stops the whole project.
Then write a one-page brief for the winner, using the fields in the diagram above.

What can go wrong

Discovery with no end date. Without a time box, discovery turns into a series of workshops. Set the decision date on day one.
Interviewing only the sponsor. The sponsor describes the process as it should work. Users show you how it actually works.
Metrics with no baseline. You can show the agent is fast, but not that anything improved.
Picking the most impressive use case. It usually has the most approvals, data work and risk. Pick the one you can finish and measure.
A brief nobody signed. If the sponsor has not agreed to the scope in writing, the scope will grow.
Ignoring the amber check. Access approvals take the longest. Start them in week one, even before the decision to go ahead.

What I would do now

Rewrite your last three requests as problem statements: who, today, cost, better.
Find one baseline you could measure this week from data that already exists.
Put a real name against each of the five stakeholder groups. Any blank is a risk.
Run the eight data and access questions against one data source.
Fill in the one-page brief and have the sponsor read it before any code is written.

What did we learn?

Discovery is a time-boxed phase that produces a problem statement, success metrics, a feasibility check, a first use case and a scope, all agreed in writing.
An ask names a solution, while a problem statement names who has the problem, what happens today, what it costs and what better looks like.
Success metrics work best as a tree, where technical metrics feed adoption metrics that feed a business outcome, and each one needs a baseline measured before you build.
Four feasibility checks, on data, access, technology and the organisation, come before any commitment, and the weakest check sets the pace.
The first use case should be high on both value and feasibility, and saying “no, and here is what I would do instead” is part of the job.
The one-page engagement brief, signed by the sponsor, records everything discovery agreed before any code is written.

What comes next?

The brief is signed and the first use case is chosen. Now the system has to fit into an estate the FDE does not own: Acme’s identity provider, its network, its data locations and its security review. Part 3, Designing inside someone else’s estate, covers the upfront technical design and the questions to ask in week one.

Sources

Opinions are my own. Every fact in this post comes from the public documentation linked above. Acme Consumer Brands and its data are fictional.