Use the sales call to establish what you can actually deliver

This is lesson one of The FDE Engagement. Use technical discovery to establish what you can deliver, and what still needs evidence. Make commitments specific enough that the customer, and your own team, can distinguish a supported capability from an untested assumption.

This is the first lesson of the flagship course. Foundations began after a project existed, but this course begins before the commitment, when customer goals and delivery constraints still need to be reconciled.

Why are you in the room? The account executive needs a technically credible delivery plan, and the customer needs to understand whether the proposed workflow can run in their environment.

Your job is to connect those questions with evidence: which system holds the data, what access exists, and which person will use the result.

Sales and engineering both depend on accurate commitments, so don't cast your colleague as the person who sells, and yourself as the only person allowed to tell the truth. Agree before the call who answers commercial questions, who owns technical follow-ups, and which claims have actually been demonstrated. And if a request exceeds the tested capability, say so while there's still time to change the plan.

It's subtle. A customer asks whether an integration is supported, and you know the product has a connector with the right name. The unanswered questions are its version, access mode, required fields and write permissions. "Supported" may be heard as "ready in our tenant next Monday," so explain the boundary before that interpretation becomes the schedule.

A quarter-end deadline can make clarification harder, but the date doesn't tell you whether the participants are acting in good faith. Ask what must be decided today, and which checks can happen before a delivery commitment. An internal signing target isn't evidence that the customer's data is ready.

Next, three questions that produce useful follow-ups. The first: where does that data live today?

Ask the customer to walk one real case through its systems. The transport system might hold shipment status, while the latest exception is in a portal, and the contract sits in a document store. For each hop, identify the owner, interface and freshness. Counting systems isn't a schedule, but testing access and identifying approval dependencies gives you something you can schedule.

The second question: has anyone here said no to something like this before? Ask what was proposed, which control or constraint caused the decision, and whether the constraint still applies. A prior rejection may concern a different data class or deployment pattern. Request the decision record, rather than treating a pause, a recollection or a job title as approval or refusal.

And the third: if this works, whose work changes? Find the person who'll use the output, and who can change the workflow. If nobody in this meeting knows, record an unresolved ownership question, and arrange the missing conversation. It doesn't prove that an owner doesn't exist elsewhere in the organization.

These questions should produce artifacts: a sample export, an access request, a workflow observation or a decision record. A call full of confident answers can still leave all four missing.

Now explain the feasible option and its conditions. Separate a capability limit from a resource tradeoff.

A capability limit means the mechanism can't do it at any budget. A resource tradeoff means it can, at a cost in time, money or deployment shape that someone has to accept. A feature might be available with a different deployment topology, additional integration work or a later date. Another request might violate a firm security restriction, or require information the source never records. So don't convert every refusal into a price. Some constraints rule out the requested mechanism.

Use this shape: what's supported, what remains to be verified, what the next check costs, and who chooses the scope after that check. For a customer-hosted deployment, a truthful answer might be: "We support that topology. We haven't checked your egress and identity requirements. We can review those with your platform owner this week, then confirm the deployment estimate." Egress means which outbound network destinations the customer permits. It's the first thing a platform owner checks, and the last thing a demo exercises.

If the customer supplies a previous six-week security review, treat it as planning evidence. Same reviewers? Same data, same topology? Confirm it. It doesn't prove that the next review takes six weeks, and it doesn't decide on its own whether the pilot should move to phase two.

When a mechanism is prohibited, state the reason, and offer an alternative only if it satisfies the requirement. Don't offer an external service as the easy route around a no-external-processing rule. An on-premises alternative may be feasible, and if it isn't, declining this scope can be the correct delivery decision.

Now work a discovery call from supplied notes. These synthetic notes introduce the freight exception workflow developed later in this module. They're statements from a fictional meeting, not verified capabilities.

The buyer says exceptions must be handled within fifteen minutes, so you still need the start and end events, and whether "handled" means identified, reviewed or resolved. The platform owner says there's a daily export, but API access isn't approved, so you need the export fields and arrival time, and a named API reviewer with a decision date. The operator lead says shipment lookup is slow, and refunds still need their approval, so you need one observed case, and the approval boundary. And the account executive says the assistant can be demonstrated in two weeks, so you need to know whether the demo uses synthetic records or customer data, and what it proves.

A daily export can support a historical demonstration. It can't establish that newly created records will be available within fifteen minutes, and refund approval doesn't disappear because identification becomes faster. So keep the proposed first workflow at lookup and evidence presentation, until the owners agree otherwise.

A useful response to the room is: "We can demonstrate lookup with the supplied export, subject to checking its identifiers. That would test matching on historical records. The fifteen-minute live workflow needs a separately approved data path, and a defined operator step." It offers a concrete next action, while keeping the two claims distinct.

Notice the question still missing. When a record is absent, should the assistant say it can't match, or might it present an old shipment with a similar identifier? Ask that before treating a convincing demo as a valid lookup flow. A correct refusal can be more useful than a fast wrong match.

Finally, write a commitment record the same day. Record the requested behavior, supporting evidence, unresolved assumptions, and the exact commitment made.

Give each follow-up an owner and a date, and send the relevant scope and dependency statements back to the customer for correction. Internal notes? They help your team, but it doesn't prove the customer accepted its interpretation.

For the synthetic call, the record should say that the two-week milestone is a demonstration on a defined dataset, not a promise of live integration or automatic refunds. The platform owner supplies the export schema, and the operator lead reviews the proposed end event. If API approval slips, the demonstration can still answer a matching question, but its results can't be described as a production latency test.

Your turn. Pause the video here. Using the supplied notes, write a four-line follow-up: the proposed demonstration, excluded actions, two open dependencies and the next decision. Then change the buyer's requirement to "every newly created exception must be handled within fifteen minutes, including weekends." Decide what evidence the daily export can support, and what would have to change.

Here's the lesson's worked review. Keep the demonstration scoped to historical lookup. Ask for a live data path with a measured freshness guarantee, and an operator coverage plan, before committing to the new requirement. A daily export and a weekday-only approval process don't meet it. If those dependencies can't change, narrow or decline that live scope. Don't relabel the historical demo as a successful test of it.

To recap. Establish capability boundaries with sales colleagues before the customer turns a discussion into a date, make sure discovery questions produce evidence, an owner and a next check, and missing information in a meeting is an unresolved question, not proof of missing ownership or approval. Then separate a historical demonstration from live freshness and action commitments, and record commitments and exclusions with the customer, while they can still correct your interpretation.

That's lesson one. Next in the series, find the constraints that can invalidate the pilot, before building it. The full lesson, with its exercise and drill, is on fdeinterviews.com.