Start with the decision, not the stack
A technology choice has value only in relation to a business decision. Establish the users, the outcome, the operating constraints and the irreversible choices first. A short discovery process should expose what is known, what is assumed and what must be tested before a schedule becomes a promise.
Map the real dependencies
The visible interface is rarely the whole system. Existing data, permissions, third-party services, policy requirements and internal handoffs often shape delivery more than a screen list. Mapping those dependencies early lets a team sequence work around real risk instead of discovering it during a release.
Leave with a useful next move
Discovery is not a slide deck that delays action. Its output should be a prioritised path: what to build first, what to validate, what to defer and who owns each decision. That makes the first increment reviewable and gives the next commercial conversation a concrete basis.
