Your Business Needs an Adversary

Parents were arriving late to pick up their children. So the daycare centers introduced a fine.

Perfectly reasonable. Put a price on bad behavior. Watch the bad behavior pack its little backpack and leave.

Except lateness increased.

In a field experiment at ten daycare centers in Haifa, Israel, researchers introduced late-pickup fines at six centers. Late pickups rose at those centers. Removing the fine later did not reverse the increase during the remaining observation period.

The researchers offered an explanation: the fine changed how parents understood the arrangement. An obligation to arrive on time could become a service they could purchase. The study appeared in 2000 under the beautifully blunt title “A Fine Is a Price.”

The daycare thought it had introduced a deterrent. Parents may have discovered a late checkout option.

That finding doesn't mean fines always backfire. It means a sensible idea deserves a harder examination than “Well, that makes sense to me.”

Your business can execute a bad assumption perfectly.

The policy gets followed. The automation fires. The dashboard turns green. Everybody did their job, and somehow you're paying more to get less.

Before you tell the team to work harder, inspect the play you handed them. Eleven people running enthusiastically in the wrong direction can cover a lot of ground.

Software teams have a useful discipline for this: adversarial code review. Give someone the assignment to challenge the work and find consequential flaws before they get expensive.

Then bring that discipline into the rest of the business. Your sales process has assumptions. Your hiring system has assumptions. That strategy you were extremely charming about in Tuesday's meeting has assumptions.

Every one of them can be examined. Including yours.

Put the plan under pressure

Imagine a developer demonstrates a new checkout flow. A customer buys a product. Payment succeeds. Everybody smiles.

Then a reviewer tries something inconvenient.

The customer clicks twice. The payment succeeds, but the confirmation times out. The customer retries. Now there's a duplicate charge.

The original demo worked because nobody had tested that sequence. Google's code-review guidance explicitly asks reviewers to think about edge cases, unnecessary complexity, and whether the intended behavior is good for users.

An adversarial review makes the challenge deliberate. The reviewer gets a clear job: find the assumption that breaks, show how it breaks, and bring evidence.

That developer deserves a useful explanation and a chance to fix the problem. Being ambushed in a meeting does very little for anyone's ability to think, except perhaps the ability to think about quitting.

The standard can still be uncompromising. A duplicate charge has to be fixed. Being kind to the person does not require pretending the work is ready.

Now apply the same review to a business decision.

For the daycare policy: “Could this make being late feel more acceptable?”

For your marketing campaign: “Could cheaper leads leave us with fewer profitable customers?”

For your support team: “Could closing tickets faster cause more customers to contact us again?”

For a compensation plan: “What would a smart person do to maximize this bonus while contributing as little as possible?”

You can learn a great deal from that last question. Especially if the answer is already happening.

Make the premise defend itself before you fund the rollout. Your favorite idea does not get tenure.

The 80/20 rule needs a search party

Joseph Juran helped apply the Pareto principle to quality improvement: a relatively small number of causes can account for a large share of an outcome. He called them the “vital few.” His institute's examples use different proportions, because the distribution doesn't have to land neatly at 80/20. Juran's guide to Pareto analysis explains the method.

The principle gives you a place to look. You still have to find the causes.

Suppose sales are disappointing. The team proposes new ads, new landing pages, a new CRM, and a motivational speaker with unusually white teeth.

An adversarial reviewer asks to see what happened to the leads you already bought.

Consider this hypothetical funnel:

Under these assumptions, increasing the contact rate from 40% to 50% produces 25% more customers from the same lead volume.

That deserves your attention. It also needs a test. Those additional leads could be harder to close, and reaching them could cost more than the business they bring in. Run the numbers before declaring victory.

But you've found a precise opportunity to investigate: missed contact.

The fix might be a clear owner, a follow-up deadline, or an AI assistant that flags neglected leads. You can now connect the work to a business result and see whether it pays.

Buying more leads before checking that handoff is like ordering extra groceries because your refrigerator door won't shut. I admire the commitment to abundance. Somebody should examine the hinge.

Pareto tells you to look for concentration. Adversarial review challenges your guess about where it is.

Look for concentrated success, too. A small customer segment might buy repeatedly, require less support, and send you referrals. Find out why. If the economics hold as you expand, give that segment more attention and resources.

Removing a recurring error protects value. Repeating an overlooked success can create more of it. Both belong in the review.

Follow the work all the way to the money

A useful review needs something specific to examine.

“Review our operations” is an invitation to receive a handsome document containing the word “streamline” fourteen times.

“Trace these twenty delayed jobs from booking to payment” gives the reviewer actual work to do.

Start with the records, the steps, and the outcome. Then use questions like these:

These are starting questions. Your evidence gets to decide which ones matter.

Pay particular attention to handoffs. Marketing celebrates a lead. Sales celebrates a deal. Operations discovers what everybody promised.

Imagine a relay team where each runner records a personal best and nobody brings the baton home. Four terrific performance reviews. One fairly awkward medal ceremony.

An improvement in one department can push cost and confusion into another. Follow the work far enough to see the final result. If the company's outcome gets worse, the department's green dashboard is no defense.

Make your AI earn its agreement

AI can write you a persuasive plan. It can also write a persuasive explanation of why that plan is terrible.

Confidence is readily available. Evidence takes more work.

Research by Anthropic found that the assistants it tested sometimes favored answers aligned with a user's beliefs over truthful answers. That tendency is called sycophancy. Treat agreement as something to examine before you count it as validation. Read the research.

Give the work three distinct stages:

1. Build. Give a person or AI the objective, evidence, and constraints. Have it propose the work.
2. Challenge. Give a separate reviewer the same objective and source material, plus the proposal. Require consequential weaknesses, overlooked opportunities, and evidence.
3. Decide and test. Have the owner accept, reject, or test each finding. Revise the work and check whether the important issue was resolved.

You can begin with a second conversation. That separates the context, but it doesn't guarantee independent judgment. Two conversations with the same model can share blind spots. Different models can, too.

For a sales review, supply the script, call examples, conversion definitions, and relevant outcomes. For operations, supply the steps, timestamps, exceptions, and rework. Include the failures. A highlight reel is a lovely thing to show your mother; it is incomplete evidence for a business decision.

Anthropic describes a related evaluator-optimizer workflow, where one model generates work and another evaluates it against clear criteria. The criteria matter. The business owner has to define what improvement would actually count.

Demand a source, a calculation, or a reproducible example. “Be brutally honest” is a tone request. It doesn't make the answer more accurate.

Then ask the reviewer: “What would prove your criticism wrong?”

The critic answers to the evidence, too. Nobody gets a free pass because they sound tough.

Be ruthless about what deserves attention

Reward reviewers for finding the most problems, and watch the supply of problems blossom. Congratulations. You've opened a complaint farm.

A typo and a duplicate-payment bug can each occupy one row in a spreadsheet. Their consequences are very different. Spend attention accordingly.

Ask for up to three priorities. Require the evidence, likely consequence, smallest useful change, and a test. Compare expected benefit over a stated period with the effort and ongoing cost. Keep severe risks visible even when they're rare.

Pay attention when a reviewer finds that the existing approach is sound. A useful review can end with “Keep doing this.” Forcing everyone to discover a flaw gives your review process the same incentive problem it was supposed to uncover.

And give your people room to tell you the truth.

An employee who reveals a recurring error has handed you something valuable. If your first response is to make them feel stupid, consider what you're training them to do next time.

I would rather hear “I messed this up” early enough to fix it. That takes a leader who can absorb uncomfortable information without making the person delivering it regret their honesty.

You can care deeply about the team and insist that the numbers hold up. You can acknowledge how much work went into a plan and still stop funding it. Effort deserves respect. Continued investment requires a reason.

Start this week. Pick one recurring process. Give it a thirty-minute review. Choose one change, name its owner, and decide what result would justify keeping it. Recheck after enough work has passed through the process to learn something useful.

One revision and a focused recheck are a reasonable starting point. If disagreement remains, run a small experiment. Keep moving. A review that eats more value than it finds is eligible for review itself.

That includes the process I'm recommending here.

The daycare policy sounded sensible. Measuring the result exposed the flaw. Your next idea deserves the same examination, especially if you're the most senior person in the room and everybody has already nodded.

Buy your team lunch. Ask which assumption they think is costing the business money. Listen long enough to hear the uncomfortable part.

Then go get the evidence.

Copy the review brief

Adam Hayes's post on the UX laws in his CLAUDE.md uses a useful format: explain the principles, then provide reusable instructions. The brief below applies that format to business reviews.

Paste it into a fresh AI conversation with one real process and the evidence behind it. You can also save it as adversarial-review.md and explicitly ask your assistant to use it. Saving a Markdown file alone does not make a review run automatically.

Start with the process that repeatedly makes your team say, “We thought we fixed that.”

# 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.