Skip to main content
Define the objective before choosing a technology. State the business outcome, how it will be measured, who owns it, and the constraints the solution must satisfy.

What a well-formed objective does

Lead with the outcome, not the means

Start from the problem and the result you want rather than the technology. Say “our month-end close takes eight days and three late nights” rather than “we want a close agent.” This leaves room for a skill, Integration Flow, agent, process change, or a decision not to build.

Connect to enterprise value

State whether the objective is expected to grow revenue, lower cost, reduce risk, or affect another metric your organization already tracks.

Set a baseline and target

Name the metric, where it stands today, the target, and the deadline. For example: “Cut the close from 8 days to 5 within two quarters.” Confirm the baseline with current evidence during Discover.

Assign an owner

Tie the objective to the executive or process owner accountable for the outcome.

Bound the scope

Name the value stream, function, or process family. “Order-to-cash in the North America billing team” is testable; “transform finance” is not.

Name constraints up front

State regulatory, data-residency, budget, timeline, human-approval, and technology constraints. These determine which solutions can move forward.

Keep use cases separate

One objective may point to several possible use cases, so do not commit to a build yet. Selection comes later in Pick the right use case.

A simple test

A good objective fits in one sentence.
Vaguer:
Deploy AI agents in finance this year.
Sharper:
Cut month-end close from 8 days to 5 within two quarters, without adding headcount or net-new engineering. Owned by the Controller.
The technical track opens with this same step. If you’re building in a coding harness, your assistant can help you frame the objective and its constraints before anything else happens.