Paid discovery should leave you with decisions you can use: a defined workflow, users and constraints, a focused first scope, acceptance criteria, and an explanation of the unresolved risks. A list of features is not enough.
Separate a fit conversation from project definition
An initial conversation can establish whether a business problem matches a team’s capabilities. It usually cannot resolve every integration, exception, data issue, and delivery decision. Detailed discovery is the work of turning that uncertainty into an agreed plan.
At AgenticShip, detailed discovery is a paid stage after a fit conversation. Its scope and commercial terms are agreed in advance. The checklist here is our proposed way to judge a useful engagement, rather than a promise that every project includes the same package.
Ask for a map of the current workflow
The map should show what starts the work, which people and tools handle it, and how someone knows it is finished. Include at least a few real exceptions: an incomplete request, a duplicate record, or an approval that does not arrive.
A useful map distinguishes the intended process from what people actually do. If the team quietly maintains a second spreadsheet because the main system cannot handle a handoff, that workaround belongs in discovery.
Expect a first-release boundary
Discovery should explain what will be built first and what will remain outside that release. A scoped customer intake queue is more assessable than a promise to transform all operations.
Ask why the boundary was chosen. The answer should connect to an operational outcome, dependency, or risk. A long backlog can be useful, but it should not obscure the small set of things the first release must do.
Make acceptance observable
For each important workflow, describe a demonstration a business owner could watch. A request is saved once, an owner can see it, an unauthorized person cannot alter it, and an exception has a recovery route.
Avoid relying entirely on broad adjectives such as seamless or intuitive. They describe an aspiration. A concrete scenario lets the buyer and delivery team decide whether the agreed behavior exists.
Leave room for an honest unknown
External services may limit integration access. A sample export may reveal missing identifiers. A workflow owner may still need to resolve an approval rule. Discovery should name those uncertainties and describe how they affect the next decision.
An estimate that depends on an unverified assumption should make the assumption visible. Ask who will resolve it, what evidence is needed, and whether development can sensibly proceed before it is resolved.
Use a short completion review
Before closing discovery, ask the operational owner to explain the proposed first release in their own words. Ask the technical team to identify the largest remaining dependency. Then check that both descriptions match the scope.
The practical outcome is a basis for deciding whether to proceed, narrow the work, or investigate further. Discovery earns its place when it makes that decision clearer, not when it produces the largest document.