When do you build a custom fix for one customer, and when do you push for a change in the product?

Build a custom fix when the need is specific to this customer, urgent for their success and cheap to maintain. Push for a product change when you see the same need at several customers, when your workaround would be fragile or costly to maintain, or when the gap is a bug or a missing basic capability. Usually you do both: unblock the customer now with a contained workaround, and bring the product team evidence for the general fix.

The tension in the role

Palantir describes forward deployed engineers as delivering many capabilities for one customer, and product engineers as building one capability for many. The value of the FDE model is the traffic between the two: field work shows what the product should become. Too much custom work, and every customer becomes a separate, unmaintainable product. Too little, and customers stall waiting for the roadmap.

Questions I ask

1. Is it specific to them? A connector to their in-house ticket system, their unique approval rules: custom work, often permanent.
2. Have I seen it before? The second or third time a need appears, it is a product signal.
3. What does the workaround cost to keep alive? Code that breaks on every product release is a hidden debt that someone else will inherit.
4. What happens if we wait? If the pilot fails without it, unblock now.
5. Is it a bug or a missing basic? Then it belongs to the product, whatever the workaround.

How to build custom work well

• Build on the product's extension points (APIs, tool definitions, MCP servers, configuration) rather than forking or patching its internals.
• Keep it small, documented, tested and owned by someone at the customer or in your team.
• Write down which product change would make it unnecessary.

How to push for a product change

• Bring evidence: which customers, how often, what it blocks, revenue at stake, the workaround and its cost.
• Propose the general version, not this customer's exact version.
• Offer your field implementation as a prototype or a test case.
• Follow up, and tell the customer honestly what is on the roadmap and what is not.

An example answer

"Three customers needed the agent to respect document permissions from SharePoint. I built a filter in the retrieval layer for the first, saw the same request at the second, and wrote a one-page proposal with both implementations and the deals depending on it. The product team built permission-aware retrieval, and I moved both customers onto it."

What interviewers look for: customer obsession balanced with product thinking, and the habit of turning field pain into evidence the product team can act on.