How Does Field Experience Become Product Capability?

Good intentions don't work. Mechanisms do. — Jeff Bezos

"Same pitfall, again?"

The night before the second customer's launch, an FDE stares at the error log for a moment. The problem is almost identical to the last customer's: two systems used different names for the same thing, and the moment the workflow connected them, permissions and approvals fell into chaos.

He knows how to fix it. He already fixed this once before.

Except last time's rules, mappings, and tests all stayed behind in another project. So he redoes it all from scratch. The customer's problem gets solved, but the company forgets the answer a second time.

I. Why the Field's Answers Never Make It Back to the Product

When a company does forward deployment, it's actually running two things at once.

The first runs at the customer's site. The FDE uses this customer's data, permissions, and workflow to get one specific problem running; the goal is to get the project live. The second is the vendor's own product platform: a data model, integration components, process capabilities, and application tools that multiple customers can reuse; the goal is to keep the next delivery from starting over at zero.

The field and the platform aren't naturally connected. The FDE finds the problem on-site and writes a solution that works; if that solution just sits as a project deliverable in the customer's folder, the platform learns nothing from it. Over time, the platform can end up looking like it has plenty of features, while the field keeps having to customize the same things over and over — and what's actually being done is still outsourcing.

The core of the problem: demand signals are generated on the delivery team, product decisions are made on the platform team, and there's no fixed mechanism carrying information between them. The delivery team's priority is hitting milestones; the product team's priority is protecting the roadmap. Neither side is wrong, and yet experience stalls inside the project anyway.

Flowing it back, then, isn't a matter of "write more documentation" — it's an interface that has to be designed on purpose: identify the assets that took shape in the field, carry them into product decisions, and then let the new product capability flow back into the next delivery.

II. First, Translate the Field Problem into a Shared Business Language

The problem that opened this chapter looks like field mapping on the surface, but underneath, it's two systems not speaking the same business language. One system calls it a "service request," the other calls it a "ticket"; the FDE wires the two together on the spot, and the customer can keep working. But the next customer will show up with yet another set of names, statuses, and approval flows.

To make this kind of experience persist across customers, it's not enough to save one instance of mapping rules — a shared language for describing the business has to be accumulated. This is the Ontology: it defines what objects exist in the business, how those objects relate to each other, and which actions can be carried out under what rules and permissions.¹

Take a ticketing scenario: tickets, customers, devices, and service staff are objects; "which device a given ticket belongs to" and "who handles it" are relationships; dispatch, escalate, and close are actions; amount thresholds, approval tiers, and visibility scope are rules. The customer keeps its own field names and raw data; what the platform accumulates is this modeling approach.

Inside this modeling approach, there's one more dimension that's easy to lose under the three words "objects, relationships, actions": permissions. Who can see this ticket, who can dispatch it, who can change its fields — these boundaries have to be accumulated too, not bolted on afterward as a layer of access control. Palantir's own materials use the example of a medical manufacturing company to make this point: the production team needs global telemetry access to equipment, warehouse staff have permissions narrowed to their own region, and supply-chain analysts have permissions scoped down to specific rows and columns; once all three roles start using AI agents to operate on the same set of business objects, each agent's permissions have to inherit from the permission structure of the human user or project it represents — it can't run on a separate set of rules.² Objects, relationships, actions, and permissions together are what make this shared language's definition complete — but writing the definition clearly is only the starting point. How does it turn from a one-off mapping rule into an asset the next customer can pick up and use directly?

"Distillation" is the more everyday word for "flowing back." Lu Xiaopeng (co-founder of Ventus AI) put it most sharply: experience scattered across everyone's individual heads doesn't count as accumulated — it only counts once it's gathered into a concrete knowledge base or Skill. Zhong Qianjie (Cresta) offered a further-along productized form: his team packages the distilled output — maybe a Markdown file, a CLI, a script — into an agentic tool; the customer says what they want to do, and the system automatically calls the best-practice logic behind the scenes to try it.³ The business Ontology is the shared language distilled out of the field; the six reusable assets below are everything else that can be distilled out of it and packaged into tools that feed back into the field.

III. What Flows Back Isn't "Experience" — It's the Six Reusable Assets

The business Ontology is the shared language, but it can't complete a delivery on its own. The field also leaves behind five more kinds of portable assets.

Connectors. A connector isn't just the story of "we wired up an interface" — it's a reusable integration component: authentication method, data retrieval, field mapping, sync rules, exception handling, and permission boundaries. What it solves is how data gets connected reliably, not how to carry the customer's data away.

Tools and approval templates. The ticketing system, approval chain, risk tiering, and operating interface the field builds to constrain what an agent can do — if these can be configured for use by different customers, they shouldn't stay stuck in a single project forever.

Process templates. Processes that recur across the same industry can be abstracted into parameterized templates. Configuration changes parameters, customization changes code; a template's value is turning more and more "change the code" into "change a parameter."

Evaluation structure and the failure-mode library. What's portable is task types, difficulty tiers, judging rules, and failure modes — not customer case data. It lets the next project start from "how do we verify this," instead of starting from "let's just try it and see."⁴

Demand signals. Which requests keep recurring across different customers, which are just one customer's exception — these records determine what's worth putting on the product roadmap. This is often the easiest one to throw away, and also the closest one to the product direction.

A former Palantir employee recalled that requests that kept recurring in the field — importing data, building visualizations, building pages — gradually accumulated into data-ingestion, visualization, and application-building tools. The product wasn't drawn up first and then accepted by customers; a lot of the time, it grows out of requests that kept showing up in the field, over and over.⁵

IV. Getting the Assets Actually Back to the Platform: Three Steps and Two Gates

Step one, the FDE builds and records the context of the problem on-site: why the customer needs this capability, why alternative approaches failed, which parts belong only to this customer.

Step two, the FDE carries this context back to the product team, and together they discuss "the correct general-purpose version." Handing over a requirements document alone isn't enough, because documents usually lose the constraints and trade-offs that shaped the requirement in the first place.

Step three, invite FDEs serving other customers to validate it together. With three workflows that are slightly different but share a common origin laid out side by side, the team can much more easily tell what's an industry commonality and what's just one customer's habit.¹

Around these three steps sit two gates. The first gate governs intake: requests get sorted into one-off, industry-common, and general-purpose before anything else — a one-off request can still be delivered, but it doesn't go straight into the product queue. The second gate governs output: the feedback review has to give every asset a clear destination — into the product roadmap, into the component library, into the template library, or an explicit "not doing this" (see Figure 22-1).

Figure 22-1: Not every customer request should be productized; only by passing through two gates does reusable field experience make it back to the platform.

Zhong Qianjie's team's practice is a concrete example of this output path: the distilled asset isn't left as vague as "goes into the component library" — it's packaged directly into an agentic tool: the customer says what they want to do, the tool automatically calls the accumulated best practice to try it, and if that doesn't work, it switches to the next approach and tries again.³

Productization also can't just take orders from whatever the customer asks for. A request has to clear at least three questions at once: does it keep recurring at similar customers? Does it serve a business goal the customer genuinely cares about? Can it be abstracted one level further than the current customer's solution? If any one of the three can't be answered, don't rush to turn it into a platform capability.

V. Making Feedback Something Both Sides Actually Want to Do

A checklist and a process can't change incentives — without that, they just stay on paper. The people doing delivery need to be able to see the payoff of feeding things back: when a component, template, or evaluation structure they built gets reused by a later project, it should count toward their delivery results.

The product team also needs to reserve room for field signals. Without a clear capacity and decision-making authority, field requests will never outrank the existing roadmap; if the review only takes in requests and never disposes of them, the feedback review turns into a mailbox.

Nor should feeding back be one-directional. Every time the platform accumulates a configurable component, a process template, or an evaluation structure, it should go back to the FDE first, so that at the next customer he needs fewer people, writes less one-off code, and spends his time on harder problems. When McGrew calls the FDE another kind of key customer of the product, this is exactly the relationship he means.¹

Whether feedback is actually running isn't measured by meeting minutes — it's measured by the FDE's choices: faced with a new request, does he reach for the platform's components to assemble a solution, or does he route around the platform and write another one-off fix.

VI. Three Ways to Make Feedback Fail

Turning the review into a blame session. The delivery team vents about the product, the product team defends the roadmap, and nothing comes out of it — no actionable asset, no clear decision. A review should only discuss actionable assets, and every one of them needs a clear destination.

Turning the review into an intake box that never outputs anything. Requests get logged as to-dos, but no one has the authority to reorder priorities; a few months later, the field naturally stops submitting. A feedback review has to carry real authority to influence product priorities.

Turning the first customer's answer straight into the product. That isn't feedback — it's just moving customization code into the platform. There's no need to rush before a second similar customer exists; only if the same kind of request keeps showing up with no action taken should you go back and check the mechanism.

Chapter 21 asked: why can't the Nth customer keep repeating the first customer's labor. This chapter's answer: the answers the field arrives at again and again have to be translated into shared language, components, templates, and evaluation, and then carried back to the platform through a mechanism that actually has the authority to decide.

---

Footnotes

1. Y Combinator, "The FDE Playbook for AI Startups" (Bob McGrew) ↩ ↩² ↩³

2. C26 ↩

3. Tencent Research Institute, AI Lens Roundtable, Episode 6: "FDE Non-Consensus Views and a Field Guide from Silicon Valley Founders" ↩ ↩²

4. "Inside an Applied AI Company" (Pace long-form post) ↩

5. "Reflections on Palantir" (Nabeel Qureshi) ↩