← Browse all articles
Leadership IQ · Research & insights
How To Get AI To Challenge Your Thinking
A practical report on testing assumptions and examining executive decisions with AI
Published
Add us as a preferred source on Google
Imagine that you’ve decided to move most of your customer onboarding process to AI. Your team spends a lot of time answering the same questions, and customers sometimes wait a day for information that ought to take a few minutes. You explain the situation to an AI assistant, and it produces a persuasive case for making the change. It even gives you an implementation plan.
But your explanation might neglect to mention that the customers who ask the most questions also buy your most complicated services. And you probably haven’t established whether the time your team spends with those customers is wasted effort or part of the reason they stay.
You can use AI to examine those possibilities before you commit. The way you ask for help matters, though. If you give the AI a conclusion and ask it to build the case, you’ve assigned it a very different job from examining whether the conclusion holds up.
This report provides prompts for challenging a decision, explains when each exercise is useful, and shows how to turn the response into something you can investigate. The examples are hypothetical. The prompts are practical exercises, and their usefulness depends on the information you supply and what you do with the answers.
Start with a decision you actually need to make
Before opening the AI, write down your tentative choice and the main reason you favor it. Keep that note. You’ll want to know later whether you changed your mind because you learned something or because the AI supplied a more confident explanation.
Then try this prompt, using information you’re permitted to share with the tool:
A prompt to challenge your preferred decision
I’m considering this decision: [decision]. My preferred option is [option], mainly because [reason]. The alternatives are [alternatives]. Here are the facts I can support: [facts and sources]. Here is what remains uncertain: [unknowns]. Examine the reasoning. Identify the assumption that most affects the choice, explain the strongest reasonable case for another option, and identify what evidence would change your assessment. Label facts, assumptions, and hypothetical risks separately. If important information is missing, ask for it. Don’t invent company facts or treat my preference as evidence.
Suppose the answer identifies customer abandonment during onboarding as a concern. You can now ask where that concern comes from. Has the AI found evidence in the information you supplied? Or has it identified a possibility that you need to measure? Both can be useful, but they call for different next steps.
Why AI agreement deserves a closer look
In Anthropic’s 2023 research on sycophancy, five AI assistants showed a tendency to produce responses that aligned with users’ views across the tasks researchers tested. The study gives executives a reason to examine agreeable answers carefully. It doesn’t establish that every current model behaves the same way or that a particular prompt eliminates the problem.
You can also get an unhelpful answer by demanding disagreement. An AI told to attack every idea can manufacture objections to a sensible plan. What you need is a reason to reconsider that you can examine, along with a clear account of what supports it.
For the onboarding decision, “customers might dislike it” is too vague to do much with. A more useful possibility is that customers with complicated requirements might abandon the process when an automated answer fails to resolve their question. That points you toward a particular customer group and a particular moment in the process.
Choose the exercise that fits the uncertainty
You don’t need to run every exercise on every decision. Start with the question that could most affect what you do.
| Exercise | Use it when you need to examine |
|---|---|
| The Assumption Hunter | What must be true for your plan to work. |
| The Steel Man | Why an informed person might reasonably favor another option. |
| The Blind Spot Hunter | What you may have left out of your description. |
| The Red Team Attack | How the plan could break under difficult conditions. |
| The Premortem | How a future failure might develop and what you could notice earlier. |
| Persona challenges | Which questions someone with different responsibilities might ask. |
The Assumption Hunter
Your plan can sound perfectly sensible while depending on something nobody has checked. In the onboarding example, the cost-saving case might assume that most customer questions have straightforward answers. It might also assume that the employees whose work is reduced can actually use that time elsewhere.
Those are separate assumptions. A pilot could show that the AI answers routine questions well while also showing that employees spend just as much time correcting unusual cases.
Prompt for the Assumption Hunter
Here is the decision and the information available: [decision brief]. List the assumptions this plan relies on. Rate the risk of relying on each assumption as low, medium, or high, and explain your reasoning. Treat those ratings as provisional judgments, not measured probabilities. Identify which assumptions are supported by the supplied information and which remain unverified. For each important unverified assumption, suggest a specific way to check it. Don’t invent evidence or imply that the list is exhaustive.
The risk ratings help organize the discussion. You still need to examine the reasoning behind them. A claim that the AI will handle “almost all” customer questions deserves particular attention if you haven’t supplied any records of those questions.
Choose the assumption whose failure would most change the decision. If the savings depend on reducing employee time, measure the whole job, including the work that gets moved to another person or another week.
The Steel Man
Steelmanning means developing the strongest reasonable version of an opposing argument. It’s useful when you already have a preferred answer and the alternatives are starting to sound foolish to you.
In the onboarding example, the strongest argument for keeping employees involved probably won’t be that technology is bad. It might be that the early conversations reveal customer requirements that the company otherwise discovers too late. If that’s happening, removing those conversations could move the work into expensive corrections after the sale.
Prompt for the Steel Man
Here’s what I believe: [preferred decision and reasons]. Here is the information available: [facts, constraints, and unknowns]. What is the strongest argument against my position? Steel-man the opposition by explaining the best case an informed person could make for a different choice. Identify the assumptions behind that argument and the evidence that would strengthen or weaken it. Don’t invent facts to make the opposition sound stronger. After presenting the argument, explain which parts of my original position still hold up.
Give the opposing case a fair reading before asking the AI to rebut it. If you immediately ask for a response that defeats every objection, you can end up rehearsing your original preference with more elaborate language.
You might still choose AI onboarding. But you could choose it for routine accounts while retaining a person for customers whose requirements need discussion. That’s a materially different decision from replacing the entire process.
The Blind Spot Hunter
Sometimes the problem is the boundary you’ve drawn around the decision. You’ve asked how to shorten onboarding, and the more important issue is that customers receive an unclear explanation before they buy.
The Blind Spot Hunter is useful when you suspect you’re describing only part of what’s happening. It gives the AI permission to look outside the variables you’ve already named.
Prompt for the Blind Spot Hunter
Here is the situation as I currently understand it: [situation]. Here is what we have already considered: [factors]. Identify factors I may have omitted that could change the decision. Begin with the most consequential omissions, then consider less obvious possibilities. For each one, explain why it could matter and what information would establish whether it applies. Combine overlapping suggestions. If a possibility depends on facts we don’t have, say so. Don’t assume an omitted factor is an actual problem.
Maybe the AI suggests that salespeople promise a level of customization the onboarding team can’t deliver. That’s worth checking if the customer records support it. If there’s no sign of that problem, you can set it aside.
The length of the list won’t tell you how useful the exercise was. One missing fact that changes the choice is more useful than a page of remote possibilities. Give yourself a stopping point so the exercise doesn’t become another reason to postpone deciding.
The Red Team Attack
A red team deliberately looks for ways a plan could fail. For a business decision, you can use this exercise to examine difficult operating conditions before customers encounter them.
An AI onboarding process might work well with a complete customer record and a straightforward question. You’ll want to know what happens when the record is incomplete, the customer contradicts something they entered earlier, or the answer requires a commitment only an employee can authorize.
Prompt for the Red Team Attack
Here is our proposed plan: [plan]. Its intended result is [result], and its constraints are [constraints]. Act as a red team reviewing it before implementation. Identify up to five plausible ways the plan could fail under realistic conditions. For each, describe the sequence that leads to failure, the assumption or dependency involved, and a safe test we could run before expanding the plan. Label hypothetical conditions clearly. Stay within business process analysis; don’t provide instructions for unauthorized access or disruption. Explain where the available information is too thin to rank the risks.
Work through the sequence. “The handoff could fail” leaves too much room for interpretation. A customer asks for a person, the system records the request, and nobody is assigned to respond before the customer leaves. You can test that sequence and establish who owns the handoff.
A proposed test should also have a result you can interpret. If a complex case is routed to an employee, check whether that employee receives enough context to avoid making the customer start over.
The Premortem
A premortem asks you to imagine that a plan has failed and work backward through possible explanations. It can help you examine consequences that arrive slowly enough to be missed in an enthusiastic launch review.
For example, your first onboarding dashboard might show that employees are handling fewer questions. That could reflect successful automation. It could also happen because frustrated customers have stopped trying to get help. You need enough information to distinguish those possibilities.
Prompt for the Premortem
Imagine that it is [time horizon] after we introduced this plan: [plan and intended result]. The project has failed to achieve its purpose. Write a hypothetical account of how that could have happened. Keep the explanation consistent with the facts supplied and label any additional assumptions. Identify early warning signs we could realistically observe, including signs that a favorable headline metric might conceal a problem. For each warning sign, suggest what we should investigate and who would be positioned to notice it. This is a scenario exercise, not a prediction.
The useful part comes when you decide what to watch. If fewer questions count as success, also check whether customers complete onboarding and reach the point where they can use what they bought. Otherwise, the metric can improve while the customer’s experience deteriorates.
Before a pilot begins, agree on which warning signs would prompt a review. That’s easier than negotiating their importance after someone has announced that the project is working.
Persona challenges
People with different responsibilities can see different weaknesses in the same plan. A finance leader may ask whether apparent savings will reduce an actual expense. An experienced operator may ask who handles exceptions at the busiest time of the week.
Your AI can help generate those questions. It cannot tell you what your actual CFO or customers believe unless you supply reliable information from them.
Prompt for a persona challenge
Review this plan from the perspective of a [Pessimistic CFO, Skeptical Board, Cynical Customer, or Experienced Operator]: [plan and available facts]. What would concern someone with those responsibilities? Which questions would they need answered before supporting the plan? Explain how their responsibilities lead to each concern. Identify where we need input from the actual people involved. Treat this as a simulated perspective, not a report of anyone’s real views.
Choose the perspective relevant to the unresolved issue. If the financial case is thin, use the Pessimistic CFO. If the process looks elegant on paper but nobody has discussed exception handling, the Experienced Operator may be more useful.
Then take the important questions to the people who can answer them. A simulated customer’s objection is a hypothesis you can investigate through customer conversations or observed behavior.
Work through a decision before expanding the plan
Return to the hypothetical onboarding proposal. The CEO begins with a preference to automate most of the process. After examining the assumptions and the strongest opposing case, the team identifies several things it needs to learn.
The table below illustrates how the exercises could lead to specific checks. These are proposed checks, not reported results from a company or an AI experiment.
| Assumption to examine | Evidence to gather | How the finding could affect the decision |
|---|---|---|
| Most questions can be resolved without human judgment. | Review a defined sample of recent onboarding cases and classify the questions and exceptions. | Limit automation to case types with suitable answers and escalation paths. |
| Reduced routine work will produce useful capacity. | Track employee time spent on routine answers, corrections, and escalations during a pilot. | Revise the savings estimate if work is being transferred or repeated. |
| Customers can get help when automation stalls. | Test the handoff and review unresolved requests through completion. | Repair the handoff before widening access. |
| Fewer support requests mean onboarding is improving. | Examine completion, abandonment, and time to first useful outcome alongside request volume. | Investigate apparently favorable numbers that coincide with worse customer outcomes. |
The CEO could now authorize a limited pilot, preserve human help for complex cases, and ask the team to bring back the evidence needed for a broader decision. The exercises haven’t established that this is the right answer. They’ve helped specify what would make the answer defensible.
Decide what deserves further checking
You can ask a second AI to review the first response, especially if the recommendation depends on a complicated chain of reasoning. Give it the original brief before showing it the other answer so it has an opportunity to examine the problem separately.
Prompt for reviewing another AI response
First review this original decision brief and form your own assessment: [brief]. Then examine this other AI response: [response]. Identify substantive disagreements, shared assumptions, and claims that need verification. Explain what evidence could resolve each important disagreement. Agreement between the responses does not establish that a claim is correct. Don’t merge unsupported claims into a more confident recommendation.
Two models can repeat the same error or rely on the same weak source. Use their disagreement to locate questions worth investigating, and check consequential factual claims against the underlying evidence.
Keep the amount of investigation proportionate to the decision. A reversible pilot may justify learning while you proceed. A decision that is costly to undo needs stronger support before you commit. Set a decision date and identify what information you can reasonably obtain by then.
In Leadership IQ’s assessment of 1,207 executives, the average score for making timely decisions was 33 out of 100, the lowest of the five areas assessed. That finding concerns executive behavior; it doesn’t test these AI prompts. It does underscore why generating more questions needs to lead to a decision.
Keep a record of what changed your mind
After the exercise, complete the following record in your own words. If your answer is still “the AI made a compelling case,” go back to the particular evidence or assumption that persuaded you.
Decision record to copy
Decision and deadline:
My initial preference and reason:
The alternative I examined most seriously:
The assumption that most affects the choice:
Evidence checked and where it came from:
What remains uncertain:
My decision and the reason for it:
What would make me reconsider:
Person responsible for the next check and review date:
You may finish with the same decision you started with. That can be perfectly reasonable. You should be able to explain why the strongest objection didn’t change your choice and which remaining uncertainty you’re willing to accept.
About this report and its sources
This practical report adapts decision exercises taught in Leadership IQ’s AI leadership curriculum. The scenarios are hypothetical illustrations. The report presents a way to examine decisions; it does not report a controlled test of the prompts or promise a particular improvement in decision quality.
The research cited here provides context for the problems the exercises address:
Anthropic, Towards Understanding Sycophancy in Language Models, 2023. Research on agreement with user views in the assistants and tasks tested.
Leadership IQ, Most Executives Struggle To Make Decisions, 2026. Findings from a behavioral assessment of 1,207 executives.