Someone uploaded a 100-page document, and the application crashed.
In my recent FDE Talks conversation, Akshay described an AI workflow his team had built during his time at Microsoft. It took a PDF containing a series of steps and produced a summary and action items. The demo worked with the inputs the team had tried.
Then they opened it up to broader testing. A user uploaded a much longer document than the team had tested. They had assumed the system would handle it somehow: process what it could, fall back, or explain that the input was too long. Instead, it crashed.
That example stayed with me because the team had considered what might happen. They had not verified what actually happened.
It also captures a responsibility we kept returning to: an FDE helps turn a promising demonstration into a system that works for the customer, and stays involved long enough to understand whether it delivers value.
Akshay joined me to discuss his move from software engineering into forward deployed engineering. We talked about discovering customer problems, using AI in delivery, and what aspiring FDEs can do before they have enterprise production experience.
Learning to understand the problem before building
Akshay was already doing parts of the job before he knew the title.
At Microsoft, he worked on the Azure Support Copilot team. Alongside engineering, he helped other teams understand generative AI, ran training, advised on architecture, and supported their path to deployment. When a recruiter approached him about an FDE role, the responsibilities sounded familiar, even though the name did not.
Moving into a customer-facing role still required a significant adjustment.
As a software engineer, he had been used to a roadmap, sprint planning, and a structured process. In customer conversations, information arrived without that structure. Early on, he sometimes struggled to understand why he was in a particular meeting or what a customer’s description of a problem meant for the solution.
He credited his onboarding with helping him develop a consultative approach: asking useful questions and adapting them to the people in the room.
This resonated with my own customer-facing experience. A customer’s initial request may reveal only part of the problem. More context appears as you speak with other teams, understand their dependencies, and learn what they are trying to change.
An accurate record of the first meeting will not contain information nobody thought to ask for. The engineer still has to recognize what is missing and follow up.
Akshay described his engagements as moving through discovery, solution design and use-case scoping, then implementation and production. In his experience, the work continues through measuring the impact. He also emphasized that FDE responsibilities vary across companies and even across engagements within a company.
That makes the scope of ownership more useful than the title when evaluating a role. Who helps choose the use case? Who builds it? Who stays involved when users encounter problems? Who checks whether the outcome justified the work?
Where the time saved by AI goes
I asked Akshay how AI had changed his own workflow and what he did with the time it saved.
He described using AI coding tools to build solutions, meeting recordings and notes to revisit requirements, and tools that help create architecture diagrams. These activities had become faster for him.
His answer about the saved time was more interesting: he spends more of it understanding the customer’s problem.
A customer may describe a symptom before either side understands its cause. Faster implementation does not resolve that uncertainty. It gives the engineer more room to investigate it, provided they use the time that way.
One practical application is to review a meeting summary against the proposed solution. Which requirements are addressed? Which statements are assumptions? Which questions still need a customer answer? This is a way to use the captured context to improve the next conversation.
The same reasoning applies to product feedback. Akshay described FDEs as a connection between customers and product teams. Working directly on a customer problem gives him a different basis for feedback than he had when working primarily from the code.
My recommendation is to make that feedback specific: explain the workflow the customer cannot complete, the limitation encountered, the workaround attempted, and its consequence. That gives the product team a concrete problem to assess.
Testing the behavior you have assumed
The PDF example makes the production discussion concrete.
Akshay did not identify the technical cause of the crash or describe the eventual fix in our conversation. What his account does establish is that the team’s expected behavior had not been tested with that input.
For a similar document application, I would turn those expectations into explicit checks:
SituationDecision to makeEvidence to inspectA document exceeds the supported sizeReject it clearly or use a defined processing pathThe user receives the intended response and the application remains availableOnly part of a document can be processedDecide whether partial output is acceptable and how to disclose itThe output makes its coverage clearThe system extracts action itemsDefine what makes an action item correctCompare the output with a reviewed set of expected actionsProcessing failsDefine recovery and what the user should do nextThe failure is recorded and the user receives a useful next step
These are proposed checks, rather than fixes Akshay reported implementing.
They also separate two questions that can get mixed together: did the application handle the request, and was its answer useful and correct? A request can finish successfully while producing a poor summary. A good answer on a small test document does not establish how the application handles a larger one.
During the conversation, I mentioned that I encourage customer teams to plan evaluations early. That means agreeing on examples and expected results so the team has something concrete to compare against as the system changes.
Akshay also raised security controls and privacy constraints as concerns on the path to production. The scope is broader than improving a prompt: the surrounding application needs defined behavior, and the team needs evidence that it behaves that way.
Preparing for the role without pretending you have done it already
There is a difficult question for aspiring FDEs: how do you demonstrate production judgment when you have not yet owned a production system?
Akshay’s advice was to go beyond describing the agent or prompt. Be able to explain deployment, evaluations, what you tried, what you learned, and what would need to happen next.
He was not asking a new graduate to prove they had operated at enormous scale. He was asking whether they understood the path ahead and could discuss it honestly.
My suggestion in the conversation was to put a project in front of real users. Make it available, let people try it, and learn from what they do. A small deployment is useful experience, although it does not establish enterprise readiness.
For a document assistant, here is a bounded way to do that:
Define one task and a small set of documents with reviewed expected answers.
Deploy the application and ask a few people to use it without guiding every step.
Record what happens: the inputs, outputs, failures, and points where users need help.
Change one thing based on that evidence, then rerun the original cases and the newly discovered failure.
Write a short account of what improved, what remains unreliable, and what you would need before expanding access.
If the new failure disappears but previously correct answers get worse, the change has introduced a tradeoff. If users still need you to explain how to complete the task, successful deployment has not yet established usability. Those observations give you something specific to discuss in an interview.
The resulting project should help you answer Akshay’s most useful challenge: can you explain why you built the solution and how it addresses the problem?
You can use AI to help write the code. You still need to understand the implementation well enough to explain its choices, limitations, and results to someone who has no background in the project.
If you already have a demo, use your next iteration to collect that evidence. Choose a user, observe where the application falls short, and document the change you made because of it. Bring the working project and that account into your next FDE conversation.
