The one-page AI opportunity brief

Most AI ideas arrive as capabilities:

“Could we add a copilot?”
“Could the model summarize this?”
“Could we automate that workflow?”

Those are possible solutions. They do not yet tell a team what should change, for whom, or how anyone will know the idea was worth building.

This playbook turns that first spark into a one-page product decision.

Use this when

• A stakeholder has proposed an AI feature but the user value is still vague.
• A team is comparing several AI opportunities and needs a common frame.
• A prototype is about to begin without a clear learning goal.
• “Adoption” is being used as the only definition of success.

The outcome

By the end, you will have one brief that connects a person, a decision, a useful change, a learning loop, and a pre-agreed proceed-or-stop rule.

The brief is intentionally short. Its job is to expose weak assumptions before they become expensive software.

What you need

• Inputs: The current workflow, examples of the decision or task, and any evidence of the problem.
• People: A decision owner, someone close to the user, and a technical partner who understands the system constraints.
• Timebox: 60–90 minutes for a first draft; one short review with the people above.
• Tooling: A page, shared document, or whiteboard. A model is not required.

The playbook

1. Name the decision, not the feature

Write the moment in which a person must decide or act.

Use this structure:

When [person] needs to decide [decision], they currently rely on [signals or workflow], which creates [delay, cost, risk, or missed value].

“Generate a summary” is a feature. “Help a support lead decide which cases need immediate attention” is a product decision.

Output: One sentence naming the person, decision, current method, and consequence.

2. Draw the path from capability to value

Make every link explicit:

1. The system sees a signal or context.
2. AI produces an answer, prediction, draft, or recommendation.
3. A person changes a decision or behavior.
4. The product observes what happened next.
5. That evidence improves the system or workflow.
6. The changed behavior creates an outcome worth having.

If the chain stops at “the model creates content,” the value is still missing.

Output: A six-link capability-to-value chain.

3. Locate the moment in the workflow

Specify what the system knows before it helps and what it can observe afterward.

Ask:

• What information is available at the moment of need?
• What information is missing or unreliable?
• How much time does the person have?
• What happens if the answer arrives late?
• Can the product observe acceptance, correction, escalation, or the downstream result?

An idea without a place in the workflow often becomes another destination people must remember to visit.

Output: A before-and-after workflow sketch.

4. Expose the consequential failures

Do not begin with “How accurate can the model be?” Begin with “What happens when it is wrong?”

List the three most important failure modes. For each, record:

• Who experiences the consequence?
• How serious is it?
• Can the action be reversed?
• How quickly would anyone notice?
• What human review or product boundary would reduce the risk?

Output: Three ranked failures and their recovery paths.

5. Choose the smallest evidence-producing artifact

Build for the uncertainty you have—not for the product you hope to launch.

• Test value with a manual or concierge workflow.
• Test model behavior with realistic examples and an evaluation harness.
• Test trust with a recommendation that shows its evidence.
• Test workflow fit with a thin integration in the real moment of use.
• Test economics with plausible volume, latency, and operating effort.

Output: One artifact, one audience, and one uncertainty it is designed to reduce.

6. Write the decision rule before the pilot

Decide what the evidence will mean while the team can still be honest.

• Proceed if: The important behavior and outcome improve without crossing the safety or operating boundaries.
• Revise if: Value appears real, but the role, workflow, or failure pattern needs to change.
• Stop if: The problem is weak, the critical failure is not controllable, or the economics cannot support the use case.

Output: Proceed, revise, and stop conditions with an owner and review date.

Worked example

Scenario: A support organization wants AI to “summarize every case.”

The feature is a summary. The decision is different: a support lead must decide which open cases need immediate intervention.

The opportunity brief may reveal that a generic summary adds reading, while a short recommendation with the customer risk, supporting evidence, and missing information changes the decision. The smallest test might be a manually reviewed recommendation for one case type—not an assistant for every case.

The team proceeds only if reviewers identify urgent cases faster without missing more high-risk cases than the current workflow. It revises if the recommendation helps but the evidence is insufficient. It stops if the input data cannot distinguish urgency reliably.

Copy the brief

• Person and decision: When [person] needs to decide [decision]…
• Present state: Today they use [signals/workflow], which creates [cost, delay, risk, or missed value].
• Proposed change: The product will use [context] to help them [changed behavior].
• Learning loop: We will observe [acceptance, correction, escalation, or downstream outcome].
• Most important uncertainty: We do not yet know whether [belief].
• Smallest useful test: We will build [artifact] for [audience and context].
• Proceed / revise / stop: We will make the next decision when [evidence] is available by [date].
• Out of scope: This test will deliberately not attempt [boundary].

Quality check

• Does the brief name a real decision, not merely an AI capability?
• Is the valuable human or business change observable?
• Is the artifact matched to the most important uncertainty?
• Are consequential failures and recovery paths visible?
• Could the team genuinely stop after the test?

Common failure modes

• Starting with a model capability and inventing a problem afterward.
• Calling generated content a product outcome.
• Naming adoption as the only evidence of value.
• Building a polished interface for a model-quality question.
• Hiding the most consequential uncertainty.
• Running a pilot without a pre-agreed decision rule.

What this does not solve

The brief does not replace user research, technical feasibility work, security, privacy, legal review, or a real evaluation plan. It tells the team whether there is a coherent product bet worth taking into those deeper processes.

Take it with you

If the team cannot name the decision, the changed behavior, and the evidence that would stop the work, it is not ready to build the AI.