A customer can get exactly the software it asked for and still have the same problem. Suppose a software company is implementing its product for a customer whose service requests take too long to resolve. The customer asks for a dashboard. But when the company's FDE spends time with the service team, they discover that people already know which requests are late. They're waiting for another department to approve them.
The dashboard might make those delays more visible. To reduce them, the FDE may need to propose a change to how approvals work, and the customer would have to authorize it. Before proceeding, the provider and customer have to decide whether that work belongs in the project.
This is why I'd scope an FDE project around a customer problem, with explicit limits on what the team can change and how much the customer will invest. Within those limits, the FDE and customer lead can revise the solution as they learn. They can pursue a better approach without reopening every commitment, while work that exceeds their authority goes back for approval.
The customer problem and the target
"Reduce service-request delays" gives the team a direction, but there's quite a bit left to agree on. When does a request count as resolved? If the team closes it sooner and the customer has to reopen it, the apparent improvement creates more work for everyone involved. Resolution time only tells a useful story when the team also checks whether the problem stayed solved.
I'd want to see the current performance before committing to a target. If nobody can measure it yet, the provider can scope the initial work around investigating the delay and collecting a baseline, then agree on a target with the customer once they understand what is causing the problem.
A target also needs to be plausible within the team's authority. If another department controls most of the delay, the service team's software may have little effect on the result. The customer might bring that department into the work or choose a narrower improvement. Either decision is better informed once the team can show where requests wait. Product discovery in FDE covers that investigation in more detail.
Customer participation and system access
The customer's project lead can be enthusiastic about the work and still have no time to help with it. A scope that assumes their availability can leave the FDE waiting for answers whenever a request takes an unexpected turn.
The sponsor can make that time available by agreeing with people's managers which other work will wait. The customer lead also needs to be able to bring colleagues into the discussion when the FDE finds a question they can't answer themselves. People whose jobs may change deserve an explanation of what is being proposed and a chance to shape it. If the team waits until rollout to involve them, it risks implementing assumptions it could have checked earlier.
An API is useful to the project only if the FDE can access the records and perform the operations the work depends on. Confirm that the necessary permissions are available, including any restrictions on customer data. If temporary elevated access is needed for setup, agree on its limits and when it will be removed. The team may also have to connect systems and resolve conflicting records, even when the customer thinks of the project as a new screen.
I'd resolve those access questions before treating a delivery date as dependable. Where access still depends on another team, agree on who will arrange it and by when. If it falls behind, the customer sponsor and provider's account owner can decide whether to work on something else or pause. The budget can run out while the FDE waits for permission to begin.
An example scope
For the service team, the initial boundary could be requests it handles from receipt through confirmed resolution. Within that boundary, the FDE and customer lead could agree to change how information is collected or how a request reaches the right person. Company policy and another department's work would remain subject to separate approval.
The provider has boundaries too. An FDE may be able to configure the product or build an integration while depending on the product engineering team for changes to shared functionality. Those dependencies belong in the proposed plan. A customer commitment that relies on a product change needs agreement from the people responsible for delivering it.
| Scope decision | Illustrative agreement |
|---|---|
| Customer outcome | Reduce time to resolve requests while preserving resolution quality. Agree on the target after measuring current performance. |
| Initial boundary | Requests handled by one service team, from receipt through confirmed resolution. |
| Systems and data | The request system and relevant customer records, including the connections and business rules needed to use them together. |
| Work the team can change | Information gathering, routing and the working interface, within agreed quality and access requirements. |
| Decisions requiring approval | Company policy, additional departments or systems, and increases to the agreed investment. Shared product changes require the provider's engineering commitment. |
| First use | A limited release to participating users, with someone responsible for monitoring it and recovering from failures. |
| Evidence of improvement | Resolution time, reopened cases and user feedback over an agreed period. |
| Investment and review | An agreed budget and team allocation, with a review before committing to work beyond those limits. |
Under this scope, the FDE can pursue a routing change with the service team. If the cause turns out to be another department's approval policy, the customer has to decide whether to expand the project. The provider can explain why that would help and what it would cost before either side commits.
Evidence before and after release
A demo lets the customer try a proposed approach and see whether it makes sense for their work. The production version also has to protect records according to each user's permissions and handle failures without losing requests. Someone has to know when it fails and be able to recover it. The scope must allow time for the delivery team to test those conditions and agree with the customer who accepts the release.
Where an AI agent handles part of the workflow, evaluations should test its permitted actions and the cases it must refer to a person. An agent could route every request correctly while the same approval delay continues elsewhere. The outcome measurements have to show whether people can finish the work sooner.
For the service team, that means recording when requests arrive and when they're resolved, including cases that reopen. Those records let the team compare performance with the baseline and ask users about the changes they see. A lighter workload could improve the average even if the new software made no difference. The team has to investigate that before taking credit for the result.
The time available to learn from a release depends on the business. A monthly workflow may take several cycles to assess, even if the engineering team can deploy daily. Include that observation period and time to act on what it reveals. How to structure an FDE engagement discusses how to fund that follow-through and assign responsibility when it extends beyond the initial implementation.
Scope changes and completion
When the FDE proposes a change, the customer should be able to see what prompted it and what the team would give up to make room for it. More evidence may justify a different solution. It may also show that further work is unlikely to pay off within the customer's budget.
I'd set the review early enough that the customer still has a choice about the remaining investment. A report delivered after the budget is spent leaves them deciding whether to spend more to finish what they expected to have already. The scope should say who can approve a revised plan and what the team will complete if the customer decides to stop.
An investigation may show that the proposed implementation won't solve the problem at an acceptable cost. The customer should receive those findings and enough explanation to understand why the provider recommends stopping before building it.
If the team has put changes into use, the handoff includes instructions for operating them and the tools to keep measuring the result. When there hasn't been enough time to assess the outcome, the customer and provider should agree on who will review it and when. They can decide whether to fund more work once they have that assessment. Someone also has to take responsibility for running the system and handling failures so both sides know who will respond after the FDE leaves.
Big Robot provides senior FDE support for customer discovery and problem definition. We work with your engineering team to turn that understanding into a delivery plan.