7. Pre-Sales & Commercial Scoping

Pre-sales technical discovery answers whether something is feasible and what it would actually take — the same discovery discipline from Section 2, applied under sales-cycle time pressure and stakes.

What's promised in the sales cycle becomes the customer's baseline expectation for delivery. A demo showing a real capability without overstating production reliability protects the delivery team that inherits that promise.

A sales-cycle demo running on cherry-picked, ideal-case data sets an expectation the real, messy production data won't meet — worth catching before the contract is signed, not explaining away after.

Small, shippable units let you validate direction early and adjust course cheaply. A single monolithic build only reveals whether the approach was right at the very end, when changing course is expensive.

Independently shippable, independently valuable even if the next unit never gets built, and small enough to complete and validate within days, not months.

An ambiguous request like "help us use AI for customer support" decomposes into concrete first units — classify ticket intent, draft a suggested reply, escalate low-confidence cases — each shippable and checkable on its own.

A gate isn't a status update — it's a real decision point: continue as planned, adjust scope, or stop. Each gate needs a pre-agreed criterion for which of those three happens.

Success criteria negotiated after delivery is really a negotiation about who's disappointed, not a measurement. Pre-agreed KPIs remove that ambiguity before anyone has a stake in a particular answer.

A sponsor who's clear on the KPI and gate structure upfront is far less likely to relitigate scope mid-engagement — the agreement itself does the work of preventing that conversation.

Document what gets measured, by when, and what decision happens at each gate — continue, adjust scope, or stop — agreed with the sponsor before work begins.

Every SOW rests on assumptions — data will be provided in a certain format, a stakeholder will be available for review. Writing these down means a broken assumption is a documented, legitimate scope-change trigger, not silently absorbed extra work.

A SOW should explicitly state what the customer must provide and by when — access, data, stakeholder time — since a stalled dependency on their side is a different problem than a stalled deliverable on yours.

When a project stalls because a customer hasn't provided promised data access, a documented dependency turns that into a clear, non-adversarial conversation instead of an ambiguous blame question.

Without explicit acceptance criteria, "is this done" becomes a subjective, relationship-straining negotiation at delivery time. Defining it upfront turns a potential dispute into a simple checklist review.

A defined change process protects both sides — the customer gets clarity on what a new request costs and delays; the delivery team gets a legitimate path to reprice work instead of silently absorbing scope creep.

A mid-engagement request that clearly exceeds the original SOW is exactly what the change control process exists for — routing it there, rather than informally saying yes, protects the whole engagement's economics.