Before the Engagement

What this phase is for, and how it fails

By the time an FDE is assigned, someone has already agreed how long the work will run, what it will cost the customer, who on their side cares about it and what counts as success. Usually that someone is an account executive, and usually it happened in a few emails. Those answers decide most of what follows. Whether the data arrives, whether an expert gives up an afternoon a week, and whether anyone signs at the end all depend on them. This chapter covers the work before the work: reading the deal you have been handed, and reshaping it while that is still cheap.

Start with the oldest public record of the model. Palantir's 2020 S-1 filing describes its first commercial phase plainly. It acquires customers "through short-term pilot deployments of our software platforms at no or low cost to them", and "During these short-term pilots, we operate the accounts at a loss." It gives the sales cycle as "often… six to nine months but can extend to a year or more for some customers", and it warns that "there is no guarantee that we will be able to move customers from the Acquire phase into later phases" (Palantir S-1, T2: company-reported, in a regulatory filing). The numbers show what that costs. In 2019, customers in the Acquire phase generated $0.6 million in revenue "which yielded a contribution loss of $65.4 million". The filing also admits that Palantir "sometimes spend[s] substantial time, effort, and money in our sales efforts without producing any sales."

The AI labs inherited this model, and the lesson in it is not that pilots should be cheap. Palantir treated a pilot as an investment, carried on its own books and judged by "the revenue such accounts generate in the following year". Somebody inside the vendor owned the bet. What tends to get copied is only the outside of it: the free pilot without the investment discipline. A free proof of concept for a vague use case, with no end date, is a favour, and favours have no owner on either side.

That is the core failure mechanism. When the pilot costs the customer nothing, nobody on the customer's side has spent anything they must justify. No budget line is at risk, so no executive has to answer for the result, so no one is obliged to free up the data or the experts. The pilot competes for attention with work that someone is accountable for, and it loses. When it ends, the question "should we buy this?" lands on someone who never asked for it.

The wider evidence points the same way, though it is not about FDE engagements specifically. IDC, working with Lenovo, found that for every 33 AI proofs of concept a company launched, only four reached production. IDC's Ashish Nadkarni said: "These POCs are highly underfunded or not funded at all", and "Most of the time the POC happens not because of a strong business case" (CIO, March 2025, T3: secondary reporting of a vendor-partnered survey). That is a correlation, not proof that funding causes conversion, but it is the pattern this chapter is built against. The book's chapter on when engagements fail returns to it with the failure data.

The evidence here is thin, and you should know how thin. Everything published on pilot terms is either vendor self-report (Palantir's calls and filing, T2) or practitioner advice (investors and operators, T4). No independent source publishes pilot-to-contract conversion rates, for AI or anything else. The terms this chapter recommends are the ones that practitioners agree on and that fit the mechanism above. Nobody has run the controlled comparison, and you should not argue as if they had.

The composite: the pilot sales promised

Part II follows one composite engagement, introduced in How to Use This Book. This is where it starts.

Notice what the reshape did not do. It didn't make the pilot bigger, or promise a better model, or pick the use case. It moved the pilot from someone who was curious to someone who was accountable, and it gave the work a date by which the data had to exist. The rest of Part II depends on those two changes.

Proof, not proofs of concept

The best-documented attempt to fix the pilot comes from the company whose filing described the problem. In 2023 Palantir moved its commercial pilots to a new format it calls AIP bootcamps. On the Q3 2023 earnings call, Ryan Taylor said the bootcamps "deliver real workflows on actual customer data in five days or less versus our traditional pilots, which generally take one to three months." Shyam Sankar put the intent in one line: "we're focused on proof, not proofs of concept." He added that roughly 70 bootcamps would run that November, "which is more than the number of commercial pilots we did all of last year" (Q3 2023 call, T2: vendor earnings call).

By the next call Palantir reported "more than 560 bootcamps across 465 organizations to-date", and Alex Karp summed up the pitch as "Our 10 hours, your 10 months" (Q4 2023 call, T2). Later calls gave examples of conversion. On the Q1 2025 call, Taylor described a large healthcare company that "did a boot camp with us in December and five weeks later converted to a five-year" enterprise agreement worth $26 million in annual contract value (Q1 2025 transcript, T2). On the Q4 2025 call: "A healthcare company completed two boot camps with us last summer and signed a $96 million deal" before the year ended (Q4 2025 transcript, T2).

What this proves, and what it doesn't. It proves that a vendor can compress the pre-contract phase from months to days for some customers, and that some of those customers sign large contracts quickly. It does not prove a conversion rate, because none was disclosed. The Q4 2023 call talks about "doubling down on how we're converting bootcamps to enterprise deals" and gives no rate. The examples are the ones management chose to tell investors. The examples also say nothing about what happened after signature: whether the bootcamp workflows reached production, or how many FDE hours the conversion cost.

The lesson to take is not the bootcamp format. Most vendors cannot run a five-day bootcamp. It needs a mature platform, a library of prebuilt workflows and engineers who have done it hundreds of times. What transfers is the principle beneath it. The customer's real data and a real workflow appear in the first week, not the third month, and the event is judged by whether the workflow works on that data, not by whether the demo impressed. A 30-day paid pilot with data access by day 5 is the same principle at a pace an FDE team can hold.

Terms that make a pilot real

There is no study of which pilot terms convert. There is a small body of practitioner advice that agrees on most points, and every source in it is T4: advice from investors and operators, based on their own experience. Here is what it says, source by source.

Read together, they converge on six terms, and each one closes a specific gap from section 4.1.

• A price. A fee makes someone on the customer's side spend budget they have to answer for. Shimoni's point about the labour budget matters for AI. If the agent saves adjuster hours, the person who owns adjuster headcount is the natural buyer, and IT is not.
• One KPI, owned by the sponsor. Heavybit's "only pick one KPI" is about focus, but the stronger reason is ownership. The KPI should be a number the sponsor already reports. Then a good result helps them, and they will fight for the data you need to produce it.
• A short, fixed duration. Thirty days is the consensus target, and none of the sources goes above three months. A short clock forces data access and expert time early, because there is no later.
• The annual contract agreed in advance. Pear and Heavybit both want the price and shape of the full contract settled before the pilot starts. Then success leads to a signature, not a new negotiation.
• Credit on conversion. Crediting the fee towards the annual contract takes the sting out of paying for a pilot, and rewards a fast decision.
• Milestones with owners on both sides. Pear's two or three milestones, with deliverables on both sides and a named owner for the pilot at the customer, turn "we'll get you the data" into a commitment someone can miss.

This book adds two terms the sources leave implicit, because AI engagements fail on them. The first is a data-access date, written into the terms: production-like data by day 5. Without it the clock runs out on synthetic data. The second is a security-review start date on day 1. An AI deployment's review asks about retention, training and residency, and it takes longer than the pilot if it starts at the end. Heavybit's annual-frame advice is partly about this, but it is better to name the date.

The pilot's price also has to cover what the pilot costs to run, which in an AI pilot includes inference. If the price assumes the cheapest model and the eval needs the largest, the economics are wrong before you start. The wiki's note on the cost, quality and latency triangle covers how that trade-off moves.

What the terms cannot do. A paid pilot does not make a bad use case good, and paying customers still say no. Lemkin's figure, low-confidence as it is, implies that even well-run paid pilots fail to convert some of the time. The case for these terms is the mechanism, not a measured rate. They put an owner, a number and a deadline on the work, and pilots without those fail for reasons nobody can act on.

The FDE's job in pre-sales

If the terms decide the engagement, the FDE has to be in the room when they are set. Job posts suggest the labs agree, though job posts are T4 for how the work is actually done; here they are used as primary evidence of what employers ask for.

• Anthropic's Manager, Forward Deployed Engineering, is to "Collaborate with account teams and Engagement Managers during the pre-sales process to qualify engagements, scope work, and inform statements of work" (Anthropic, T4).
• Mistral's Forward Deployed Machine Learning Engineer will "be involved in pre-sales calls to understand potential clients' needs, challenges, and aspirations" (Mistral, T4).
• Sierra's Deployed Infrastructure Engineer collaborates "with Sales and Customer Success to scope infrastructure requirements during pre-sales and onboarding, translating customer needs into concrete deployment plans" (Sierra, T4).
• Harvey's Forward Deployed Finance Engineers "lead discovery, demos, pilots, trainings, onboarding, and custom builds alongside our AEs and CSMs" (Harvey, T4). Harvey quotes the role's pay as on-target earnings with a variable share, which makes it the clearest case in the sample of an FDE with a stake in the sale.

The posts show what employers ask for: qualifying the deal, scoping the work and informing the statement of work. They don't show how often FDEs are actually consulted before signature, and no public source measures it. In many companies the FDE still first sees the terms after the customer has signed. If that is your situation, the next best time to raise them is the week before kick-off.

The FDE's distinctive contribution in pre-sales is the sentence "this pilot cannot succeed as written." The account executive can't say it with authority, because they can't tell whether a use case is technically feasible in 30 days. The customer won't say it, because they don't know. The FDE is the only person who knows what the build needs and has an interest in it shipping. That is the qualifying half of "qualify engagements": deciding that a deal should not go ahead on its current terms.

How to say it: name the missing term, don't refuse the deal. "We won't do a free pilot" sounds like an engineer obstructing a sale. "This pilot has no KPI, so at the end nobody will be able to say it worked" is a statement about the deal's chances, and it comes with its own fix. Work from the brief in section 4.6. For each blank field, name the field, say what goes wrong if it stays blank, and propose a value.

• No sponsor: "Who on their side loses something if this fails? If nobody, then nobody will sign when it succeeds. Can we get the COO's office to own it?"
• No KPI: "What number will the sponsor show their boss? Let's write that one down and take its baseline in week one."
• No data date: "If we don't have production-like data by day 5, we will spend the pilot on fixtures and prove nothing. Can we make day 5 a term, with the clock pausing if it slips?"
• No price: "Free is fine if it's a choice. What's our reason, and who on our side owns the investment?"

The last line matters. A free pilot is sometimes the right call: a strategic logo, a first customer in a new vertical, or a product team that needs the learning. Palantir ran its Acquire phase at a deliberate loss. The failure is not that a pilot is free. It is free by default, with no one on either side owning what it costs. If it is free, write down why and who owns the investment, and keep every other term.

The 90-day pilot in this site's AI-driven SDLC book is the internal version of the same discipline: take the baseline before the agent starts and write the stop rule before the first result. An FDE engagement adds a second organisation with its own sponsor and budget, which is why its terms are written down before anyone starts.

The template: engagement brief and pilot terms

The brief is one page that the FDE, the lead and the account executive fill in together before signature, and that the customer's sponsor reads. If a field cannot be filled, that blank is the finding. The problem hypothesis is deliberately labelled a hypothesis. Discovery tests it, and Scoping and the First Win turns the KPI into a threshold.

ENGAGEMENT BRIEF AND PILOT TERMS                     v__ / date ________

PARTIES
  Customer sponsor (owns the KPI):          ______________________
  Decision-maker (signs the annual deal):   ______________________
  Budget owner (whose budget pays):         ______________________
  Vendor: FDE ____________  Lead ____________  AE ____________

PROBLEM HYPOTHESIS (to be tested in discovery, not built to)
  As stated by the customer:                ______________________
  Business number it is meant to move:      ______________________

THE ONE KPI
  KPI:                                      ______________________
  Baseline source (system / report):        ______________________
  Baseline measured by (who, which week):   ______________________

TERMS
  Duration (30 days target; 90 max):        ____ days, start ______
  Price:                                    ______ (or: FREE because ______;
                                            investment owner: ______)
  Credit on conversion:                     ___% if signed within ___ days
  Annual contract shape agreed in advance:  [ ] yes  scope ______ value ______

DATES THAT STOP THE CLOCK IF MISSED
  Production-like data access by:           day ___ (target: day 5)
  Security / model-risk review starts:      day ___ (target: day 1)

CUSTOMER EXPERTS
  Name / role                    hours per week      from day
  ______________________         ____                ____
  ______________________         ____                ____

MILESTONES (2-3, owner on each side)
  1. ______________________  vendor: ______  customer: ______  day ___
  2. ______________________  vendor: ______  customer: ______  day ___
  3. ______________________  vendor: ______  customer: ______  day ___

EXIT CRITERIA (either side may stop if)
  - ________________________________________________
  - ________________________________________________

ON SUCCESS
  Success means:                            ______________________
  What happens next (contract shape, date): ______________________

BLANK FIELDS AT SIGNATURE (list; each blank is a risk accepted by ______)
  ________________________________________________

Here it is filled in from the composite, at the point the COO signed. Ranges stand in for figures the composite does not fix.

ENGAGEMENT BRIEF AND PILOT TERMS                     v3 / pre-signature

PARTIES
  Customer sponsor (owns the KPI):          COO
  Decision-maker (signs the annual deal):   COO (with CFO above a threshold)
  Budget owner (whose budget pays):         Claims operations, not IT
  Vendor: FDE (mid-level)  Lead (senior, part-time)  AE

PROBLEM HYPOTHESIS (to be tested in discovery, not built to)
  As stated by the customer:                "A customer chatbot"
  Business number it is meant to move:      Claims take too long; status
                                            calls are a symptom (unconfirmed)

THE ONE KPI
  KPI:                                      Claims cycle time (the number
                                            the COO reports to the board)
  Baseline source (system / report):        Claims system event timestamps
  Baseline measured by (who, which week):   FDE + claims analyst, week 1

TERMS
  Duration (30 days target; 90 max):        30 days, start on signature
  Price:                                    20-50% discount on prorated
                                            annual value
  Credit on conversion:                     full fee, if signed within
                                            about a month
  Annual contract shape agreed in advance:  [x] yes  scope: claims triage
                                            value: range agreed with COO

DATES THAT STOP THE CLOCK IF MISSED
  Production-like data access by:           day 5 (read-only replica +
                                            document store sample)
  Security / model-risk review starts:      day 1 (intro call booked)

CUSTOMER EXPERTS
  Name / role                    hours per week      from day
  Senior adjusters (2-3)         2-4 each            days 2-5
  Claims analyst (1)             2-4                 week 1

MILESTONES (2-3, owner on each side)
  1. Baseline + data access    vendor: FDE    customer: claims analyst  week 1
  2. Working demo on redacted  vendor: FDE    customer: claims director week 2
     real documents
  3. KPI readout vs baseline   vendor: lead   customer: COO             week 4-5

EXIT CRITERIA (either side may stop if)
  - No production-like data by week 2: pause the clock, renegotiate
  - Discovery shows the KPI cannot move within the workflow in scope

ON SUCCESS
  Success means:                            Threshold on the KPI, agreed
                                            in scoping (week 1-2)
  What happens next (contract shape, date): Annual contract, claims triage,
                                            signature within about a month

BLANK FIELDS AT SIGNATURE (list; each blank is a risk accepted by lead)
  KPI threshold (set in scoping with claims director)

Two things in the filled version are deliberate. The success threshold is still blank, and it is listed as an accepted risk with an owner. You cannot set an honest threshold before discovery has seen the workflow, but you can promise when it will be set and by whom. The chatbot also survives as the stated problem, so the customer's words are on record. If discovery shows that claims documents, not customer calls, are where the time goes, the brief has already said that might happen.

Failure signals

Each of these is visible before the first day on site. Any one of them is a reason to reopen the terms. Two or more mean the pilot is, in effect, an unfunded proof of concept, whatever the contract calls it.

Ready to move on

Move on to discovery when every item below is true, or when the blank ones are written down with someone who has accepted the risk.

• A named sponsor with budget, who owns the KPI.
• One KPI, with a baseline source and a person who will measure it in week one.
• A duration of 90 days or less, with a start date.
• A date for access to production-like data.
• A start date for the security or model-risk review.
• Exit criteria in writing, for both sides.
• Customer experts named, with their hours per week committed.
• A price, or a written reason why it is free and a named owner for the investment.
• The shape of the contract on success, agreed before the pilot starts.