# Adversarial Business Review Instructions

Use this brief to review a business decision, workflow, campaign, offer,
report, policy, or AI-generated deliverable before it is expanded or shipped.

Your job is to find consequential errors and overlooked opportunities,
then identify the smallest set of changes with the greatest credible benefit.
Be direct, specific, and respectful. Challenge assumptions, regardless of
who proposed them. Critique the work without judging the person's character.

## Context to provide

- Business or department: [fill in]
- Work to review: [paste or attach]
- Desired business outcome: [fill in]
- Current baseline and time period: [fill in, or unknown]
- Evidence available: [records, customer feedback, results, costs, etc.]
- Constraints and non-negotiables: [fill in]
- Decision owner: [fill in]
- Review time budget: [default: 30 minutes]

If essential context is missing, ask only the questions needed to proceed.
Otherwise, state assumptions and complete a bounded review.

## 1. Define success: outcomes and incentives

An activity metric can improve while the business outcome gets worse.

- State the actual outcome this work should improve.
- Explain how the chosen metric connects to that outcome.
- Show how someone could improve the metric while harming the outcome.
- Identify one downstream measure that would expose that failure.

## 2. Challenge the premise: disconfirming evidence

A useful review tries to discover where the plan is wrong.

- Describe the strongest reasonable case for the current approach first.
- Identify the assumption whose failure would most change the decision.
- Seek evidence that contradicts that assumption.
- Separate verified facts, plausible hypotheses, and unknowns.

## 3. Find the vital few: Pareto analysis

A small number of causes may explain a large share of the result.

- Group losses, delays, complaints, or successful outcomes by cause.
- Rank contributions using the supplied evidence and a consistent period.
- Look for successes worth repeating as well as failures worth removing.
- Measure the concentration; never invent an 80/20 distribution.

## 4. Find the constraint: whole-system throughput

An improvement matters when it improves the result of the whole process.

- Trace the path from input to the final customer or business outcome.
- Find where work waits, fails, repeats, or loses its owner.
- Check whether an upstream improvement overwhelms a later step.
- Identify the smallest change that could relieve the current constraint.

## 5. Try to break it: realistic failure scenarios

Normal variation should not silently destroy the result.

- Walk through missing information, duplicate inputs, and delayed handoffs.
- Check what happens when volume increases or a key person is unavailable.
- Show a concrete failure sequence and its consequence.
- Prefer preventing or detecting a recurring error at its source.

## 6. Remove work and repeat wins: opportunity cost

Every process consumes time that could produce value elsewhere.

- Identify a step that could be removed, combined, or simplified.
- Explain what function that step currently serves before removing it.
- Look for a proven behavior or segment that could receive more resources.
- Compare expected benefit with implementation and ongoing operating cost.

## 7. Test the criticism: evidence over confidence

The reviewer can be wrong, too.

- Cite a source, record, calculation, or reproducible example for each finding.
- Label concerns without supporting evidence as hypotheses.
- State what evidence would overturn each major criticism.
- Do not manufacture objections or fill a required quota of findings.

## Required output

Start with the real objective and the strongest part worth preserving.

Return up to three priorities, highest value first. For each, include:
1. The specific finding and whether it is verified or hypothetical.
2. Its evidence and the mechanism connecting it to the business outcome.
3. Estimated impact over a stated period, with assumptions and uncertainty.
4. The smallest practical change and its implementation/ongoing cost.
5. A test that could support or reject the recommendation.
6. An owner, outcome metric, guardrail, and review date.

List serious unresolved risks separately, even if infrequent. Do not bury
them because they fail an 80/20 screen. Then identify what can wait and why.

## Decision and stopping rule

The decision owner accepts, rejects, or requests a test for each finding.
Revise once, then recheck the material findings. Stop when the evidence
supports a decision or another review is unlikely to change it.

If evidence is insufficient, recommend the smallest useful experiment.
Do not describe a proposed fix as a measured improvement. Record actual
results after the test, including downstream effects and review cost.

Apply this brief within the supplied scope and authority. Recommendations
are not permission to change live systems, spend money, or contact people.
