Connect a software capability to a working customer workflow

This is lesson one of Foundations of Forward Deployed Engineering. Forward deployed engineering connects software capabilities to a specific customer's data, workflow and operating constraints. The work combines hands-on implementation with discovery, evaluation and coordination. A successful demo? Only one piece of evidence.

You need no freight experience. An exception here is a shipment problem that an operator must investigate and resolve. We'll use that workflow to see why customer-facing engineering can extend well beyond installing a product.

Start by following one task from request to outcome. A vendor can demonstrate a useful search or summarization capability.

And a customer may still be unable to use it in daily work, because source records don't join, users can't access the right documents, the output arrives too late, or nobody owns the failure path.

The gap has a simple cause. The capability was built and tested on data the vendor controls. The workflow runs on data, permissions and deadlines the customer controls, and every difference between the two is work somebody has to do.

Careful, though. These are possible explanations for a stalled pilot, and they aren't proof that the product is sound, or that most pilots fail for one reason. The product might lack a required capability. The proposed problem might not justify the cost. So investigate both the platform and its fit to the workflow.

The last mile is a useful name for the work connecting a capability to an actual operating outcome. It can include code and configuration. Data contracts, meaning the agreed meaning and format of each field where one system hands data to another. It can include permissions and user interaction, and rollout and support. Many organizations already have owners for those tasks. The challenge is often coordinating their boundaries, rather than finding work that literally belongs to nobody.

Now audit a supplied pilot. This synthetic freight pilot has a demo that summarizes a delay email and suggests the relevant shipment. The customer wants operators to make a supported remediation decision. Read the packet before proposing another model prompt.

Take the packet one line at a time. The demo identifies the shipment in 8 of 10 selected emails. That establishes one thing: the shown path works on some selected examples. Billing and the shipment export write identifiers in different formats. The operator must consult a contract before deciding. The export arrives nightly. Outbound model calls are blocked in the target network. And no one is named for failed imports.

Each line also leaves something open. Eight of ten selected emails says nothing about representative quality, or behavior on ambiguous IDs. Different formats don't tell you whether they're the same entity. The contract raises its current version, and who can read it. A nightly export raises whether it's fresh enough for the decision deadline. Blocked calls need an approved deployment or processing path. And someone has to diagnose, recover and communicate a failed import.

A useful first move is to trace one approved example end to end, from the incoming exception, through the shipment identity, the applicable contract, the proposed output and the operator decision, to the recorded outcome. Capture where the trace stops, and the evidence needed to continue. And do it in an approved environment with suitable data, not by copying customer records into an arbitrary demo tool.

The identifier example needs a domain decision. Stripping whitespace may be appropriate under a source contract. Dropping leading zeros may merge distinct identifiers in another system. Here's why. A system that pads every identifier to five digits can only ever mean one record by zero zero one two seven, while a system that issues one two seven and zero zero one two seven as separate accounts has two, and the export alone can't tell you which kind of system you're looking at. So ask the data owner for the mapping rule, and test collisions.

"Clean the data" is too vague to specify a safe transformation. Freshness works the same way. The nightly export may be sufficient for a daily review. It may be unsuitable for a 15-minute intervention. The right response depends on the required workflow. And a faster model can't make yesterday's source current.

Next, make ownership concrete. Different organizations divide the work differently. Use roles as starting points for a responsibility discussion, not stereotypes about who can't help.

A product capability or defect goes to product and platform engineers, source mapping and quality to the customer's data owner and integration engineers, workflow and adoption to operators and the workflow manager, access and processing to security, identity and data owners, and delivery and operation to the FDE, services, platform or customer team. A useful handoff leaves evidence behind: a reproduced issue, an approved mapping, a recovery procedure.

An FDE may implement several of these pieces and coordinate the others. But owning progress doesn't mean granting yourself permissions. Nor does it mean changing the customer's business process on your own. When a dependency sits outside your authority, record the responsible decision-maker, and the next check.

Now combine documentation with discovery. Good documentation can make a standard integration straightforward. It's valuable. It can eliminate repeated bespoke work. But where the workflow or source semantics are uncertain, documentation alone may not contain the missing answer.

So inspect permitted data samples, and observe the real task with the people who perform it. A short discovery note should separate three things. "Two IDs differ in formatting" is an observation. "They are the same customer" is an unverified interpretation. "Ask the source owner for the canonical mapping, and test collisions" is a next step. That separation keeps an early guess from becoming a production assumption.

Hands-on engineering includes implementing and testing the resulting contract. It also includes deciding not to build. Sometimes the evidence shows a proposed feature can't meet the need, or shouldn't proceed under the current constraints. One company's job posting, like Palantir's, is evidence about that role. It isn't a universal definition of every FDE job.

Finally, measure more than the shipment of code. For the synthetic pilot, keep four questions apart.

Was the agreed software delivered and tested? Does it produce sufficiently correct results on the eligible work? Can authorized operators use it in their workflow with acceptable effort? And does that use improve the agreed outcome, at an acceptable cost and risk?

Adoption matters, but usage alone doesn't establish value, and that cuts both ways. A mandatory tool may have high usage and poor outcomes. Turn it around: an accurate system with low usage may have an access, timing or usability problem. Investigate before blaming users, or declaring the whole capability useless. And a finite evaluation doesn't prove all future cases will work. Record difficult segments, human fallback, missing outcomes and operating limits.

Your turn. Pause the video here. Create a six-row issue register from the pilot packet. For each observation, write its consequence, a responsible role and the next evidence request. Then say whether it blocks a daily-review pilot, a 15-minute pilot, or both. Next, write a three-sentence status update: what the demo established, the most important unresolved dependency, and the next concrete test. Don't call the pilot production-ready. And don't quote the selected eight of ten as a representative accuracy estimate. Finally, choose a current FDE job posting and save its date and source. Mark the responsibilities involving implementation, customer discovery, operation and reusable product work, and list the questions it leaves unanswered.

To recap. The last mile connects capabilities to specific data, workflows, permissions and operating conditions. A demo supports only the cases and environment actually tested. Trace one task end to end, and separate observations from assumptions. Coordinate explicit ownership, while preserving the customer's decision rights. And evaluate delivery, quality, adoption and outcomes as related but separate questions.

That's lesson one. Next in the series, compare engineering roles by what they actually own, not by the title. The full lesson, with its exercise and drill, is on fdeinterviews.com.