Give Your AI Workforce These Prompts and Check What Comes Back

These are the prompts from the book, each with the check to run on the output, plus the two in the chapters that the print carries only in short form. Give each one the evidence it names: your documents, your data, your notes. An AI that has none will invent some, and that is the main way these prompts fail.

Three rules apply to all of them.

1. Give it your files, not a description of them. Paste or attach the record, the script, the ticket export.
2. Ask it to mark what it inferred. A fluent guess looks the same as a fact.
3. Do the check. The person who runs the product decides. The AI drafts and challenges.

An AI persona can help design a test. It cannot pass the test on behalf of a human ICP. The chapter “AI Cannot Stand In for the Customer in an Acceptance Test” explains why.

Sort the week#

From the chapter “Cheaper Building Raises the Value of Evidence That Customers Will Use the Product.”

Prompt to use: Sort every item in my calendar and task list for last week into three groups: managing production, producing acceptance evidence, and other. Give hours for each group and list the five items you are least sure about. Do not guess what a meeting was about. Ask me.

Check the output: Reclassify the uncertain items yourself.

Testing stack audit#

From the chapter “Each Testing Layer Answers One Question and Leaves Others Open.”

Prompt to use: Read our test plan, release checklist, and UAT script. For each layer (unit, component, integration, system, QA, UAT), state what our evidence establishes and what it cannot establish. Then list the acceptance questions no current test owns. Do not invent tests we do not run. Mark what you cannot tell as unknown.

Check the output: Confirm with your QA lead that each layer is described fairly.

Find the buyer-user split#

From the chapter “The Buyer and the User Are Often Different People.”

Prompt to use: Map every person who buys, approves, evaluates, configures, administers, uses, is affected by, can block, can mandate, can abandon, or can renew this product, using our sales notes, contracts, support tickets, and usage data. Show where authority and daily use belong to different people. Identify any metric we read as acceptance where the user may have had no choice. Mark every actor you inferred.

Check the output: Show the map to one salesperson and one daily user.

Build the ICP Acceptance Specification#

From the chapter “Define the ICP Before You Test Anything.”

Prompt to use: Read the available product, market, sales, support, implementation, and usage evidence. Draft an ICP Acceptance Specification. Separate what is directly evidenced from what is inferred. List inclusion and exclusion criteria, actors, trigger, current alternative, desired outcome, constraints, and unproven assumptions. Do not invent missing facts. End with the five assumptions most capable of invalidating this ICP.

Check the output: Mark every field the AI guessed as unknown.

Audit the promise#

From the chapter “Test the Promise Along With the Product.”

Prompt to use: Compare our current advertising, landing pages, sales scripts, decks, demo behavior, onboarding, documentation, and actual product workflow. Extract every material promise, quoting its source. For each, identify where the product proves it, where service or manual intervention is required, where evidence is missing, and where the promise may be stronger than the demonstrated product. Do not soften any finding.

Check the output: Give false or unsupported claims to the person who owns that channel.

Build the ICP Acceptance Path#

From the chapter “Map the Path an ICP Takes From Problem to Continued Use.”

Prompt to use: Starting with the earliest realistic problem trigger, map the full path by which this ICP finds, evaluates, selects, sets up, uses, reaches value, and continues with the product. Include marketing, sales, demo or trial, onboarding, implementation, product use, support, and renewal where they apply. For every transition, define the actor, expected behavior, evidence, likely failure, and required instrumentation. Mark every stage where our current data is silent.

Check the output: Walk the map with someone from sales and someone from support.

Design an adversarial acceptance test#

From the chapter “Design Every Test to Have a Chance of Failing.”

Prompt to use: Take this Acceptance Hypothesis and design a test with a realistic chance of disproving it. Choose a representative participant, realistic starting conditions, messy but plausible data, reasonable interruptions, and explicit limits on product-team assistance. Define the sample size, success, failure, confounders, instruments, and when to retest. Do not sabotage the user. Remove artificial protection only.

Check the output: Ask whether the test could produce a result that would change your plan.

Find rescue contamination#

From the chapter “Unplanned Help Weakens the Evidence.”

Prompt to use: Review these demo, trial, onboarding, implementation, support, and UAT notes. Identify every human intervention required for the user to progress. Build a rescue ledger by path stage, intervention type, actor, frequency, and severity, and mark each intervention planned or unplanned. Separate intentional service from hidden rescue. Quote the note that shows each intervention.

Check the output: Show the ledger to the people who did the rescuing.

Write the test card#

From the chapter “Test Under the Conditions Customers Actually Have.”

Prompt to use: Turn this Acceptance Hypothesis into an Adversarial Test Card with the fields I paste below. Pick the two adversarial conditions most likely to break this path for our ICP, and say why. Write forbidden and allowed assistance as short rules an observer can follow without judgment. Flag any part of the test that could harm a participant or expose personal or regulated data.

Check the output: Give the card to someone who did not write it and ask them to run it.

Propose the instrumentation#

From the chapter “Instrument Each Transition on the Path.”

Prompt to use: Here is our ICP Acceptance Path. For each transition, propose the event that would show it happened, the fields it should carry (including who intervened and whether use was voluntary), the signal that would show confusion, and the signal that would show abandonment. Flag every transition we cannot currently observe. Do not propose events that collect personal or regulated data we do not need.

Check the output: Ask engineering which events already exist under another name.

Challenge the evidence#

From the chapter “Teams Misread Acceptance Evidence in Fourteen Predictable Ways.”

Prompt to use: Act as a skeptical research reviewer. Given this Acceptance Evidence Record, list the strongest alternative explanations for the apparent success. Look for selection bias, survivor bias, proxy-user bias, coerced adoption, training contamination, demo bias, incentives, stale evidence, instrumentation gaps, and confounding. Rank issues by how much they could change the product decision, not by how easy they are to fix.

Check the output: Decide which explanations you can rule out with existing data.

Retest the path#

From the chapter “Keep an Acceptance Evidence Record for Every Test That Informs a Decision.”

Prompt to use: Given the change we made, identify which prior acceptance evidence is now stale. Propose the smallest retest that can show whether the change repaired the failure without creating a new failure elsewhere on the path. Cite the records you rely on by ID. Do not treat evidence from earlier versions as current.

Check the output: Confirm the records cited name the versions the AI says they do.

Run one turn of the loop#

From the chapter “Run the Acceptance Loop Continuously.”

Prompt to use: Here are our ICP Acceptance Specification, our path, and the last three Acceptance Evidence Records. Identify the highest-risk Acceptance Hypothesis, the evidence that is now stale, and the smallest adversarial test that could disprove the hypothesis this month. Write the Adversarial Test Card. List what we should stop doing if the test fails.

Check the output: Confirm the test could really fail and that you can reach the participants.

Generate the adversarial scenarios#

From the chapter “AI Cannot Stand In for the Customer in an Acceptance Test.”

Prompt to use: Here is our ICP Acceptance Specification and the Acceptance Hypothesis we are about to test. Generate twenty plausible adversarial scenarios that stay inside the ICP: unusual but reasonable users, data, setups, and interruptions. Rank them by how likely each is to break the hypothesis. Mark any that need a participant we do not have. Do not simulate what a customer would say.

Check the output: Put three scenarios in front of a real person who fits the ICP.

Draft the stop conditions#

From the chapter “Decide What Evidence Would Make You Stop Building.”

Prompt to use: Read our strategy, roadmap, ICP Acceptance Specification, and recent Acceptance Evidence Records. Draft the stop conditions for this product: the specific evidence, threshold, and date that would make us narrow the ICP, change the promise, or stop building. Mark which we could measure today and which need instrumentation we do not have. Do not write conditions we would ignore.

Check the output: Read each condition aloud to the decision owner.