Guide

How to build an FDE practice

A software company or development shop can deliver a successful FDE project and still struggle to put another team in front of the next customer. The first team may have relied on one person who knew which questions to ask, how to challenge a requested solution and when to get help.

A practice needs to develop that judgment across its engineers and give them the tools and time to act on it. When agents help implement a change, customer findings need to inform their instructions and the tests used to check their work. The firm also needs to understand what each engagement demands before assigning another customer to the same engineer.

Build for the kind of work you take on

A company selling a complex ERP product needs FDEs who understand that product deeply and can investigate how different customers use it. The work may justify specialists by product area or industry, engineers at different levels of experience, and leaders who support decisions across teams. Customer feedback should help improve the shared product as well as the individual customer's results.

A shop building smaller, bespoke applications may begin with much more uncertainty about the solution. Its engineers need to investigate the customer's work, compare approaches and test proposed interactions with users. Discovery and design deserve explicit staffing and coaching when the team is responsible for defining the application itself.

Both need discovery skills and sound engineering. Product maturity, customer variability and the consequences of a mistake should determine the depth of expertise and supervision each assignment requires.

Hire and develop product judgment

Assess how an engineer investigates a problem before testing how they would build the requested feature. Give a candidate a fictional operations manager who wants a dashboard of late orders. Ask them to find out what the manager needs to decide and why the current information is insufficient. Look for questions about recent incidents and a willingness to revise their recommendation when the evidence changes.

Teach the same skills through observation and coached practice. An engineer can watch an experienced colleague investigate a problem, lead the next conversation and review the reasoning together. Product specialists and designers can help deepen those skills. Give engineers more authority as they demonstrate judgment and the ability to implement and verify their decisions.

Technically capable product managers can develop toward implementation too. Everyone making production changes needs to meet the relevant engineering and operating requirements. Product discovery in FDE develops these responsibilities within an engagement.

Carry discovery into delivery and measurement

Suppose the dashboard investigation shows that staff spend most of their time checking whether an order is late at all. Two systems update at different times. A useful first change might help reconcile those records before the team builds another reporting screen.

Record which source is authoritative and what should happen when records disagree. Give the people and agents implementing the change current instructions and representative cases to test. If an agent classifies orders, its evaluations should include the conflicting records that caused difficulty for users.

Establish a baseline and target for how quickly and accurately staff identify orders needing action. Build measurement into the first release and reserve time to review results with users. Use evaluations to investigate faulty classifications and production measures to judge whether the work improved. Assign someone to act on those findings in the next iteration.

Decide how many engagements an FDE can carry

An FDE may be able to support several engagements when their combined demands leave enough time for customer work and ongoing improvement. Discovery, a production rollout or an incident can require concentrated attention. Familiarity with one shared product can help, but several customers may still need the same engineer at the same time.

Before adding an engagement, the practice lead should review recorded effort and upcoming commitments with the FDE. Include customer sessions, investigation and design, implementation, and support interruptions. Account for the time needed to regain context between customers. Protect time for post-release observation and iteration, and identify who can step in when demands overlap.

The lead needs authority to resolve conflicting commitments and reassign work. If response commitments slip, decisions wait for the engineer or improvement cycles keep getting postponed, review the allocation and add support or reduce the workload. An engagement waiting for customer access still needs an owner and a plan for when work resumes.

Make customer access a practice responsibility

Each engagement needs a customer lead who knows the job, has influence with colleagues and makes time to collaborate. The sponsor must involve affected users and address concerns about how their work will change. The firm also needs access to the systems and data required to make and verify improvements.

Check these conditions before committing delivery capacity. Agree who intervenes when participation or access fails, including when the account executive gets involved. Scoping an FDE project covers the responsibilities and boundaries to establish with the customer.

Improve what the next team can use

An ERP practice can bring recurring customer problems and measured results to the product team. Together, they can decide what belongs in the shared product and check whether the change helps other customers. A bespoke shop may find more reuse in delivery tools, integration methods and evaluation techniques than in application code.

Give shared delivery tools an owner who studies where engineers lose time or introduce defects. Keep that responsibility distinct from decisions about the customer-facing product, even when one person holds both roles. Reuse methods within the agreed boundaries for customer information; private records and credentials stay with their engagement.

The product management article explains how teams can invest in customer improvements and the development system together.

Check the economics and keep improving the practice

Record the full effort required to produce and sustain customer improvements, including specialist help, leadership, training and shared tooling. Teams need consistent records so the firm can see whether a later engagement benefits from what it invested in earlier work.

A product company may fund FDE work to improve adoption, retention or the shared product. Those benefits need evidence alongside delivery costs. A bespoke shop needs to price and staff for discovery, design and ongoing support. How to structure an FDE engagement examines how commercial commitments can support iterative work.

Assess where the team needs coaching or better tools. A bounded internal project can help engineers practice unfamiliar work; a customer engagement tests those methods under real delivery conditions. Review what another team could do better as a result, then check whether the next engagement bears that out.

Big Robot offers assessment and coaching to help you build an FDE practice.