The problem, in one paragraph
When somebody quotes a number for an integrated ecommerce project before doing any discovery, that number is not really a number. It is a range, and it is usually wide enough that you would make a different decision at one end of it than at the other. At the low end the project gets approved without much thought; at the high end it might not happen at all.
What discovery is actually for
Not producing a document. Narrowing the range — improving the reliability and the probability of success, so the work can be delivered against a budget and a timeline that resemble the original estimate, or so the people who need to know are updated early enough to decide about it.
What is in the training
Who is in the room. Five roles are worth having on an integrated ecommerce project: somebody who owns the storefront and knows how customers actually buy today, somebody who owns the ERP, and the sales, marketing and back-office people whose work the integration passes through. This decides most of the quality of what comes out.
How to capture what they know. Record the screen rather than taking notes, wherever there is no PII or other sensitive data, and have each person walk their own part: how a customer finds a product, gets a price and places an order; how that order lands in the ERP, gets picked and shipped, how the invoice is raised and how payment gets applied. Recording beats notes for a specific reason — when people narrate a process they walk the happy path and skip the exceptions, and the exceptions are where the work is.
How to catalogue it. Every object, in both directions. Every field that carries real meaning. Every rule, and every exception somebody demonstrated without naming. That catalogue is what the refined estimate gets built from, because every object in it is a separate interface with its own failure modes.
How to validate it — the step that gets skipped. Take the catalogue back to the same people and walk it line by line. Two things reliably surface: the real state of the data, and what the environment can actually do — which API surfaces exist on that specific ERP version, what the rate limits are, whether a test environment exists with representative data in it.
What has to come out the other side. Not a document for its own sake. A sequence: the interfaces in the order they get built, what each one depends on, and which data has to be cleaned before which interface can be trusted.
How to use it
Use it before the decision rather than after it. The training covers the planning that happens before anything gets built, which is the point at which the choices in these videos are still cheap to change.