Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
You are mid-engagement and the customer’s lead says, “We need this workflow to work for our three regions, each with different approval rules, and it has to be enforced by the platform.” You can probably hack something together in the deployment, but you also know this is the kind of thing the next customer will ask for too.
This lesson is about spotting the moment when a customer ask stops being a one-off delivery task and starts being core product work, and then being clear about what still stays on you as the Forward Deployed Engineer (FDE). An Forward Deployed Engineer (FDE) is an engineer who ships in a customer environment while translating customer needs back into product and engineering work.
Before you decide what to build, you decide what the request really is. Is it “make it work for this account by Friday,” or is it “we lack a reusable capability and this customer is the first strong signal”?
Explore the contrast between a one-off client change and a reusable capability.
A request becomes product strategy when it is no longer about this customer’s configuration and starts pointing at a missing product capability. You feel it when the customer is not asking for an output, they are asking for a rule the platform must own.
Consider this situation. The customer wants region-specific approvals enforced inside the platform, not in a spreadsheet, not as a manual step, and not as a custom script that only your team understands. That is a hint they are asking for something that needs product design, long-term support, and a clear contract for how it behaves.
A quick way to separate the two is to ask what happens after you leave. If the solution requires you to maintain a custom branch, a private patch, or a special-case behavior no one can explain without your notes, it is drifting into product territory because it needs an owned interface and a stable support story.
If it must be supported, it must be designed
The moment a customer expects a capability to survive upgrades and new users, treat it like product, not a one-time delivery trick.
Even when something should become core product work, you still own forward motion in the engagement. Your job is to unblock the customer without quietly rewriting the product in the field.
That accountability has two parts.
First, you keep delivery moving. You turn the ask into a clear requirement, you identify what is feasible in the current deployment, and you propose an interim path that is honest about limitations.
Second, you protect product integrity. Product integrity means the product stays coherent as one product, not a pile of account-specific behaviors that break each other over time. In practice, that means you avoid forks, you avoid hidden flags that only one customer uses, and you avoid making commitments that force engineering into a corner later.
In our approvals example, you might implement a temporary process that meets the audit need while you gather evidence for a core capability. You are not refusing the request, you are sequencing it.
The messy part is that each failure mode can look like “being responsive” in the moment. The cost shows up later, usually when you are already on a different customer.
See a few mini-cases of how these failures create downstream cost.