Forward deployed engineering brings engineers close to the customer's work. To use that access well, they need the skills to investigate problems, the authority to act on what they learn and responsibility for checking the results.
Agentic engineering uses AI agents to help implement changes. The two can work together, but faster implementation only helps when customer understanding, decision authority and feedback keep pace.
That requires changes to the inputs into engineering: how problems are discovered, who can act on that knowledge and what evidence guides the next change.
Give engineers the skills to discover the problem
Access to users is valuable when engineers know how to learn from them. Engineers working in an FDE role need practical discovery skills: observing work, asking about recent events rather than hypothetical preferences, distinguishing a requested feature from the underlying problem, and testing assumptions before committing to a solution.
Ask a user to walk through a difficult case. Follow the information they needed, the decisions they made and the workarounds they used. Then check the interpretation with other people affected by the same workflow. The person making the request may see only one part of it.
On a construction accounting project, Big Robot's conversations with finance staff and project managers separated two connected jobs: matching incoming payments and reviewing subcontractor payments. Each needed different information and decision authority. Those findings shaped the system we built.
See how customer research changed the solution
Define the outcome and the limits of the solution
Before choosing features, agree on the result the customer needs, its current baseline and a measurable target. For a billing problem, that might mean reducing the time from completed work to an accurate invoice, while preserving the checks needed to bill correctly.
Carry that reasoning into implementation. The team and its agents need access to the user evidence, intended outcome, operating constraints and acceptance conditions.
An instruction to add a report leaves more room for misunderstanding than an explanation of the decision that report must support.
Test the uncertainty most likely to change the solution. For example, an apparently simple reporting request may turn out to involve conflicting source records. A quick prototype can test whether a proposed view helps the user; inspecting representative records can establish whether the information behind it is trustworthy.
Let technical product managers take changes into production
The overlap should work in both directions. Engineers need discovery skills, and technically capable product managers should be empowered to implement and deploy changes within an agreed scope. A PM who understands the customer problem and can make a sound change should have a path to put it into use.
Give that authority according to competence and responsibility. Everyone making production changes should meet the same relevant requirements for testing, review, security, monitoring and recovery. The team needs clear ownership when a change affects shared systems or commitments to other customers.
This allows the person learning with users to act on what they find. It also makes them responsible for checking the result after release. Broader authority depends on a delivery system that makes those responsibilities practical.
Build the evidence into the delivery system
The machine that builds the machine should also help the team decide what to improve. Product usage data, outcome reporting and evaluations belong alongside the tools for writing, testing and deploying changes.
Build capture and reporting for the agreed outcome into the first release. Record enough to see where users complete the work, abandon it or need help. Check those signals with users: high activity can reflect repeated attempts, and low activity can reflect a problem the product has not solved.
Where LLMs or agents perform work, evaluations are a critical part of that feedback. Test representative tasks against explicit success criteria and failures observed in use. Use deterministic checks for results that can be verified directly, and calibrate LLM-based judgments against human assessment. These evaluations help the team compare changes and catch regressions before release. Anthropic's evaluation guidance explains how these methods work together.
Passing an eval establishes performance on the cases and criteria tested. Production evidence must still show whether the change helps people do their work. Delivery measures provide another view: DORA's guidance pairs throughput with instability so teams can see whether frequent releases also bring more failures or rework.
Keep the whole product in view
Expensive implementation forces hard choices about what gets built. When implementation becomes cheaper, it is easier to approve a feature because it can be delivered quickly. The cost of supporting it, explaining it to users and fitting it into the rest of the system remains.
Prioritization must account for these obligations as engineering effort becomes a weaker filter. Ask whether the change improves the customer's overall work, whether an existing capability could solve the problem, and what the team will have to maintain afterward. A stream of individually reasonable requests can still produce a confusing product.
Use faster engineering to test alternatives and deliver a coherent solution. A small release can solve a narrow problem well. Leaving essential parts of that problem unresolved creates work for users, even if the release is technically complete.
Make iteration a commitment
The ability to make another change quickly does not ensure that anyone will return to the first one. If a team starts work faster than it finishes or retires existing work, unfinished features and workarounds accumulate. Cheap implementation can make that pattern easier to sustain.
Before release, name who will review the result, when enough evidence should be available and what capacity is reserved to act on it. Short feedback cycles need a decision: improve the change, expand its use, leave it as it is or remove it. A backlog item saying "fix later" provides none of those commitments.
Review usage and outcome data with users. Investigate changes in workload or other processes before attributing a result to the release. The next step may be a product change, better support for adoption or a different understanding of the problem. The observation window must fit the work; daily deployments do not make a monthly outcome visible sooner.
Carry the learning back into the delivery system as well. A recurring failure may call for better context, an eval or a release check that protects future changes. At handover, retain the measures, reporting tools and ownership needed to continue this work.
Apply discovery to your project
Big Robot combines product discovery and hands-on engineering in customer projects, with measurement and short iteration cycles built into delivery.
Forward deployed engineering projects · How to scope an FDE project · Product management for agentic engineering