Shadow-mode pilots in one to two weeks

A shadow pilot is deliberately duplicate. The old process still finishes the job. The new process produces a draft in parallel. You compare them. You do not rip out the old path to prove you are serious.

In short. One to two weeks, old path still live, a person between the draft and the customer, notes every day.

Set the window before you start

Write the start date and the decision date. One week is enough when the workflow happens daily. Two weeks is enough when it happens a few times a week. Beyond that, you are no longer piloting. You are operating without having decided to.

Put three lines next to the dates:

• What “success” will look like in words a coworker understands.
• What will make you stop even if people are curious.
• The name of the owner who reads outputs.

Those lines are also on the pilot checklist. If the decision date is “when we feel ready,” you do not have a window.

Run beside the old process

Each instance produces two artifacts: the usual finished work, and a draft from the new path. Store them where you can open both. A shared folder with the date in the name is enough. A new platform is not required for a shadow.

The person doing the job should not have to context-switch into a science project. If capturing the comparison takes longer than the task, shrink what you capture. One note per instance is plenty: usable as-is, usable after an edit, or reject.

Do not let the draft send itself, file itself into the system of record, or talk to a customer during the shadow. That is a rollout. Rollout comes after the decision, and the adoption pillar is where that sequence lives.

Keep the human checkpoint obvious

The checkpoint is a person and a moment. “Alex reads the draft before it is sent.” Not “the team reviews when they can.”

Tell Alex what they are checking: facts that must match the source, tone you would actually use, and anything that should never be guessed. Tell them they are allowed to reject the draft without writing an essay. A reject with a reason of one line is useful. A reject with an apology is noise.

If the checkpoint starts rubber-stamping because the week got busy, the pilot is no longer a pilot. Pause it. A rubber stamp teaches the wrong lesson: that the draft is the work.

Compare, then decide

At the decision date, read the notes before you read anyone’s enthusiasm. Count, in the plainest way, how many drafts were usable as-is, usable after an edit, or rejected. You are not building a case study. You are deciding whether the next month includes this path.

Keep, revise, or stop. Revising means one change and a shorter second window, not a new tool. Stopping means you write down why, so the same demo does not get re-bought in a quarter.

What you are allowed to claim afterward is what you saw: the drafts, the edits, the misses. What you are not allowed to claim is a savings number you did not measure. The companion piece is what to measure without fake ROI.

When the shadow has a result and you want a second set of eyes on whether the job should become a system, use the evaluation prep sheet and book a Free AI evaluation. Bring the comparison notes. Leave the pitch deck.