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.
A discovery handover you can review
Use this illustrative customer-request workflow to review the deliverables. The purpose is to make the first release assessable. Agree the actual deliverables and exclusions before commissioning discovery.
| Deliverable | Example for a request workflow | What to check together |
|---|---|---|
| Current workflow map | A request arrives, a coordinator assigns it and an operator completes it. Missing contact details return to the coordinator. | Can the people doing the work identify their actual handoffs and exceptions? |
| First-release boundary | An internal intake queue with assignment, status and search. Customer login is deferred. | Can the team complete one request with this scope, and is deferred work listed? |
| Acceptance examples | Submit a complete request, submit it again, then submit one without contact details. Define the expected result for each. | Who demonstrates these cases, and who accepts the result? |
| Dependency record | CRM access has not yet been tested. The proposed handoff depends on permission to create the required record. | Is there a named owner, required evidence and a decision if access is unavailable? |
| Decision and next scope | Proceed with the internal queue, investigate the CRM connection separately, or pause if the queue has no operational owner. | Does the recommendation explain what is known, what remains open and what the next fee covers? |
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.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.