How should an FDE team choose which customer problems to accept?

Scope

Use this guide at the portfolio intake point before an FDE team commits discovery and build capacity. It applies to customer-specific problems that may require production data, integration, workflow change, or product adaptation. It is more than deal qualification and less than a final implementation plan.

Why it happens

FDE demand is usually greater than capacity. Revenue, executive attention, and technical novelty dominate selection because they are visible. The hidden dimensions appear later: no authorized data path, no operator who will adopt the workflow, an irreversible production risk, or a solution that cannot be supported or returned to the product.

A team can also reject valuable field work by demanding certainty too early. The answer is a staged decision with explicit unknowns and a cheap discovery test, not one perfect score.

Diagnosis

For each candidate, write the current workflow and consequence of failure before describing an AI solution. Identify the user, decision or job, baseline, pain, frequency, and accountable owner. Then test whether the problem requires field engineering or could be handled by documentation, standard configuration, a partner, support, or core roadmap.

Surface non-negotiables early: data rights, environment access, identity, deployment, evaluation, incident ownership, security review, and exit. A project that cannot observe its intended outcome is not ready for a production promise.

Solution

Use hard gates for legal/authorized access, an accountable customer owner, a measurable value test, and a credible safe environment. Score softer dimensions such as strategic fit, repeatability, product feedback value, and opportunity cost.

Choose one of four outcomes: accept a bounded discovery, reshape the problem, route it to another function, or reject with reason. An accepted discovery has a time box, explicit questions, no implied production commitment, and a decision date.

Re-score after discovery. Replace assumptions with evidence about users, data, model performance, integration, adoption, and support. The team should be able to stop without treating sunk effort as proof of value.

Artifact

The opportunity-qualification card contains:

Area	Evidence / decision
User outcome	User, workflow, baseline, consequence, frequency, and owner
Value test	Observable success, time window, and authoritative measurement
Product fit	Current capability, required extension, and rejected standard path
Repeatability	Transferable constraint/capability and customer-specific residue
Access feasibility	Data rights, environment, identity, approvals, and customer dependencies
Production risk	Blast radius, reversibility, incident owner, and prohibited effects
Adoption	Workflow change, champion, training, feedback, and usage evidence
Learning return	Product decision that the engagement can inform
Capacity	FDE effort, core-team dependency, support tail, and displaced work
Outcome	Accept discovery, reshape, route, or reject; owner and review date

Common mistakes

• Selecting by contract value while production feasibility is unknown.
• Calling repeated customer requests a product pattern without mechanism analysis.
• Starting a prototype before identifying user, baseline, and adoption owner.
• Treating customer access as an implementation detail.
• Letting a discovery phase become an unbounded delivery commitment.