The Discovery Sprint

Why Discovery Is the Most Dangerous Phase

Many FDE engagements fail not in the build phase but in the discovery phase. The failure mode is almost always the same: the FDE builds exactly what the stakeholder asked for and delivers something the organization cannot use. The stakeholder described a symptom; the FDE solved it; the root cause remained and the pilot failed anyway.

Discovery is dangerous because stakeholders are often describing their current workaround, not the underlying need. When an operations manager says "we need AI to extract data from PDFs," they may actually mean "we need to stop assigning junior staff to a task that causes 90% of our downstream errors." The PDF extraction is the workaround they invented. The real problem is downstream error rate.

An FDE who builds a PDF extractor has solved the stated problem. An FDE who understands the error rate context builds something that integrates with the validation step, flags ambiguous extractions for human review, and reports accuracy back to the operations manager. Both built "PDF extraction." The second one shipped something that will still be running in a year.

The Five Discovery Questions

After running many discovery sprints, FDEs converge on a small set of questions that reliably surface the real problem. These five questions are not a script. They are prompts that reveal what the stakeholder actually needs versus what they have asked for:

Reading the Room in Stakeholder Interviews

The five questions work on paper. In a real stakeholder meeting, an FDE also needs to read several non-verbal and organizational signals that the questions alone cannot capture.

Power dynamics. Identify who in the room has veto power over the deployment. This person may not be the most senior. It may be the compliance officer, the data steward, or the team lead whose workflow the pilot will disrupt. If that person seems skeptical, address their concern directly before the meeting ends. A pilot that moves forward without clearing the veto holder will be blocked at handoff.

Enthusiasm asymmetry. When the VP is enthusiastic and the individual contributors are quiet, it usually means the pilot has been announced to the team without the team's input. Individual contributors are the ones who will use or ignore the system. If they are not bought in during discovery, adoption will be low. Find a way to get their real concerns on the table.

Scope creep signals. Watch for the phrase "and while you are here." This signals that additional stakeholders are waiting to attach their problems to your engagement. An FDE who accepts scope additions in a discovery meeting often ends up with a pilot too large to ship in the available time. Acknowledge the request, write it in your notes, and explicitly defer it to a future phase.

Hard Constraints vs. Soft Constraints

One of the most practical skills in discovery is distinguishing between constraints that are genuinely non-negotiable and constraints that exist only because no one has challenged them recently.

Hard constraints are structural: regulatory requirements, system architecture limits, contractual obligations, or security policies that require an authorization process you cannot shortcut. When a data team says "we cannot send customer data to an external API," that is usually a hard constraint backed by legal and information security policy. Building a pilot that violates it will be stopped at security review, costing you weeks.

Soft constraints are organizational preferences, legacy habits, or undocumented assumptions. "We have never done it that way" is a soft constraint. "The last vendor we used required a different interface" is a soft constraint. Soft constraints are worth discussing with the stakeholder who introduced them. Often they evaporate when an FDE asks directly: "Is this a technical requirement or a preference? If it is a preference, can we try a different approach for the pilot?"

Writing the Scoping Document

At the end of the discovery sprint, an FDE produces a scoping document. This is not a technical specification. It is a one-page shared agreement between the FDE and the key stakeholders about what the pilot will and will not include, what success looks like, and what each side is responsible for.

A scoping document that is too detailed creates false precision: it implies the FDE knows exactly how everything will be built, which they do not. A scoping document that is too vague creates scope drift: stakeholders assume things are in scope that the FDE never agreed to build. The right level of detail specifies the outcome (what the pilot will do for the user) without specifying the implementation (how it will do it).

FDE SCOPING DOCUMENT
Customer: [Name]
FDE: [Name]
Date: [Date]
Pilot window: [Start date] to [End date]

PROBLEM STATEMENT (2-3 sentences)
What the customer is experiencing today. Be specific about
the business impact, not just the technical symptom.

SUCCESS CRITERIA (quantified where possible)
- Primary: [Metric the pilot must hit to be considered successful]
- Secondary: [Nice-to-have metrics that indicate strong performance]

WHAT IS IN SCOPE
- [Specific capability 1]
- [Specific capability 2]
(Keep this list short. Three to five items maximum.)

WHAT IS OUT OF SCOPE
This is as important as what is in scope. List at least
three things explicitly excluded to prevent scope drift.

DEPENDENCIES (what each side commits to providing)
Customer provides:
- [Sample data set, access credentials, subject-matter expert time]
FDE provides:
- [Pilot environment, build effort, documentation]

CONSTRAINTS
- Hard: [Regulatory, security, architecture requirements]
- Soft: [Preferences or legacy conventions that affect design]

SIGN-OFF
Customer sponsor: ____________ Date: ________
FDE: ____________ Date: ________