Being the voice of the customer
Forward deployed engineers see things nobody else in the company sees: how customers actually use the product, where it breaks in real environments, and which needs appear again and again. Feeding that back is one of the most valuable — and most neglected — parts of the role.
Why it matters
Without a feedback loop, every deployment is a custom project, and the company never gets more efficient. With one, each engagement makes the product better and the next deployment faster. Companies that use the FDE model well treat their FDEs as their best source of product insight.
Separate one-offs from patterns
Not every request should change the product. A useful test:
| Signal | Likely a one-off | Likely a pattern |
|---|---|---|
| How many customers ask? | One | Several, independently |
| Is it tied to an unusual setup? | Yes — a bespoke legacy system | No — a common system or workflow |
| Would it help new customers? | Unlikely | Yes, and it would shorten their deployments |
Solve one-offs in the customer's deployment. Raise patterns to the product team with evidence.
Write field reports that get acted on
Product teams receive lots of vague feedback. Make yours specific:
## Field report: <short title>
**Customer(s):** <names or segments> **Severity:** <blocker / painful / nice-to-have>
**What happened**
<concrete description, with an example>
**Impact**
<time lost, deals affected, workaround cost>
**Workaround used**
<what we did in the field>
**Suggested product change**
<smallest change that would remove the need for the workaround>
Quantify the cost of the gap — hours of FDE time per deployment, or revenue at risk. Product priorities follow numbers.
Build reusable assets
The second time you solve the same problem, turn it into something reusable: a connector, a deployment template, an evaluation harness, a discovery questionnaire, a security questionnaire answer bank. A good rule: solve it concretely the first time, generalise the second time, productise the third.
Influence without authority
You usually don't set product priorities. You influence them through credible evidence, relationships with product managers, and showing up with solutions rather than complaints. Invite product managers to customer sessions now and then — seeing the problem first-hand is more persuasive than any report.
Share what you learn
Short internal write-ups after each engagement — what worked, what didn't, what you'd do differently — compound into a playbook for the whole team. (This handbook started that way.)
"How would you decide whether a customer request should become a product feature?" Use the one-off vs pattern test, describe how you'd gather evidence across customers, and explain how you'd present it to the product team.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.