Define the Outcome Before You Choose the Output
Fast implementation increases the penalty for choosing the wrong problem. Shape the outcome first so speed points in the right direction. Write an outcome frame without naming a solution. Identify the user, situation, current behavior, and desired change. Make constraints and non-goals explicit. Detect solution leakage before it hardens into scope. “Build an incident assistant” names an output. It does not say who needs it, what becomes better, or what must remain safe. An outcome frame says: That sentence can be satisfied by software, a runbook, a data repair, or a smaller interface change. It keeps the team attached to the result rather than the first artifact someone imagined. Outcome statements leak solutions when they contain a product form, interface, model choice, framework, or architecture that has not been earned by evidence. “Users receive a weekly AI summary” leaks the summary and cadence. “Users understand account changes before approval” states the result. “Deploy a vector database” leaks infrastructure. “Relevant policy evidence is available during review” states a capability. Constraints can name technology when compatibility truly fixes it. Record why it is fixed. Constraints are not implementation details. They are part of the real-world goal: no production writes during diagnosis;. response within the incident time budget;. existing audit events remain authoritative;. no new runtime dependency;. accessibility behavior remains intact. A build…
Define the Outcome Before You Choose the Output: Fast implementation increases the penalty for choosing the wrong problem. Shape the outcome first so speed…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.