AI drafts an issue tree or a pyramid in seconds, and a tidy structure isn't a correct one. Here are four classic thinking tools, a prompt for each, and a way to break what AI drafts before you keep it.
Issue trees, hypothesis-first work, answer-first writing and 2x2s all get faster with AI. The risk is a polished structure with an overlap, a gap or an agreeable verdict inside it. Pick the tool by question shape, use the prompts below, and try to break each draft before you keep it.
Consulting frameworks used to be slow to produce and easy to trust. Someone spent a few hours turning a vague problem into a tree or a pyramid, and the effort was a kind of checking in itself, because you can’t fill in a structure without noticing where it doesn’t fit. AI removes the hours. A tidy issue tree with a clean top line arrives in seconds, and nothing about the tidiness tells you whether the structure is right.
A marketing lead who asks for “a MECE breakdown of why pipeline is down” will usually get four neat branches back. Three are sensible. The fourth overlaps the first, and the cause that actually explains the drop, a change in how leads are counted, isn’t on the tree at all. It goes unnoticed in the meeting because the structure looks finished.
So this guide treats the classic thinking tools as two things at once: a faster route to a first draft, and a set of checks on it. AI is good at the first and needs supervising on the second. Four tools follow, each chosen because it fails differently: issue trees and MECE, hypothesis-first work, answer-first writing (pyramid and SCQA), and prioritising with 2x2s and 80/20.
Barbara Minto, who developed the pyramid principle at McKinsey, described the pyramid as “a tool to help you find out what you think.”[1] That’s the spirit to keep: make your thinking visible so it can be tested.
A Future Factors method. If the break test fails once, send the named branch back to step 3. If it fails twice on the same question, the question is probably the problem, so go back to step 1.
The research on consultants points the same way. In a field experiment at Boston Consulting Group, consultants using AI on a task chosen to sit just outside what the model handled well were about 19% less likely to produce a correct solution than consultants working without it.[2] The detail worth holding onto is that the outputs still looked professional. If a structure looks complete whether or not it’s right, the polish can’t be what tells you it’s safe, and step 4 exists for that reason.
People tend to reach for the framework they remember best, which is how every problem ends up as a SWOT. A better habit is to look at the question first. Four question shapes cover most of what lands on a manager’s desk, and each has a tool and a typical AI failure.
| If the question is… | Reach for | Ask AI for | The failure to watch |
|---|---|---|---|
| “Why did this happen?” | Issue tree with MECE | Branches with one named splitting logic | Overlaps or gaps that look complete |
| “What’s going on, and how would I know?” | Hypothesis-first | Competing hypotheses, each with a ruling-out check | Agreement with the one you favour |
| “How do I put this to someone senior?” | Answer first (pyramid, SCQA) | A reordered draft and a support check | A top line the body doesn’t back up |
| “Which first?” | 2×2 and 80/20 | A consistency check on your scores | Invented scores and patterns |
Our own decision table. Choosing a strategy framework (SWOT, PESTLE, scenarios) is a different decision, covered in our guide to AI for strategic planning.
Give AI the decision you’re facing before you name a framework.
Open with “build me an issue tree” and you get the framework’s generic shape. Open with your decision and what you already know, and you get a structure bent around your problem. Every prompt below starts that way.
Whichever tool you pick, run the same four checks before a draft goes anywhere. They take a couple of minutes.
| Check | Ask yourself | It fails when |
|---|---|---|
| 1. Overlap | Could one fact sit in two places? | Two branches share a cause, so data counts twice. |
| 2. Gap | What would explain this that isn’t here? | Everything listed is plausible and the real cause isn’t. |
| 3. Evidence | What data or person would confirm or kill each part? | A leaf says “customer sentiment” and nobody knows where to look. |
| 4. Source | Which parts came from my facts, and which from general knowledge? | It would be equally true of any company in your industry. |
Our own checklist, a starting point rather than a validated method.
Keep no AI-drafted structure until you’ve tried to break it.
First-draft issue trees tend to fail quietly. Every branch is reasonable on its own, and the branches don’t share a splitting logic. “Pricing, product, competitors, marketing” mixes things you control with things you don’t, so one fact can sit under two branches and one cause can sit under none.
An issue tree breaks one question into parts that can each be investigated. MECE means the parts are mutually exclusive, so nothing counts twice, and collectively exhaustive, so nothing is missing. Minto says she was the first to abbreviate the idea and apply it to groups of ideas, though the underlying logic goes back to Aristotle.[1] Here is a tree for the pipeline question from the opening, split the way a good draft would be.
A Future Factors illustration. Branches A to C split the funnel by stage, and each names its own splitting logic. Branch D, with the dashed border, asks whether the number itself changed. In our judgment, AI drafts tend to leave it off, and the person who knows what changed in the business is the one who adds it.
The decision rule I’d use is to ask AI to name the splitting logic at each level. If it can’t state one in a few words, such as “by funnel stage,” “by who pays” or “by what we control,” the branches aren’t MECE, however they look.
| I need an issue tree for this question: [one sentence, plus the decision it feeds]. What I already know: [three to five facts, including what changed and when]. Give me two levels. At each level, tell me the one splitting logic you used. For each branch, say what data would confirm or rule it out. Then list anything that could explain the situation and fits under no branch. No recommendations yet. |
Asking for what fits under no branch makes the gaps visible.
Then check the tree in three moves:
AI can redraw a tree all day. It can’t know which branches are live in your business, or that a tracking change went in last quarter. That judgment stays with you.
Hypothesis-first work flips the usual order. Rather than gathering everything and waiting for a pattern, you write your best guess early and spend your effort trying to kill it. It’s a common consulting habit that tells you which data to pull first.
With AI there’s a catch. Ask whether your hypothesis is right and you tend to get a well-argued yes. Anthropic researchers found that five state-of-the-art AI assistants showed sycophancy across varied tasks, and that human preference judgments themselves tended to favour answers matching the user’s stated views.[3] In practice, that makes the order of your prompt matter. If you reveal the hypothesis you favour, you’ve told the model what to agree with.
A hypothesis becomes a finding only when something outside the model’s text has tested it.
Use AI to generate alternatives you hadn’t considered, and leave the verdict to the evidence.
| I’m trying to explain this: [the observation, with what changed and when]. What I know: [facts]. Give me three hypotheses that would each explain it, and make them genuinely different, not variations on one idea. For each one, tell me what we’d expect to see in the data if it’s true, the quickest check, and what result would rule it out. Then name my weakest fact. I haven’t decided what I believe, so don’t guess. |
Once you have your own view, send it in a second message and ask for the strongest case against it.
Here’s a card filled in for a question an HR business partner might face, why people leave in their first months. The last column is the one people tend to leave blank, and it’s the only one that lets you lose an argument with your own hypothesis.
| Hypothesis | If true, we’d see | Quickest check | What would rule it out |
|---|---|---|---|
| The job differs from the one in the hiring pitch | Exit notes mention role mismatch, clustered in a few roles | Tag last quarter’s exit notes by reason | Reasons spread across unrelated causes |
| New hires lose their main contact after week one | Leavers feel unsupported; check-ins were skipped | Compare check-in dates for leavers and stayers | Both groups got the same check-ins |
| Competing offers got better after a pay move elsewhere | Leavers move to similar roles at higher pay | Check where recent leavers went | Leavers move to lower-paid roles |
An illustration of the format: each row has a check to run this week and a result that would end it.
AI can draft the hypotheses and the checks in a minute. It can’t tell you which check is cheap in your organisation, such as who holds the exit notes and who will answer a question, and it can’t run the check. A pre-mortem is a close cousin, assuming the decision has already failed and asking why, and our piece on AI as a thinking partner covers keeping the judgment on your side of the conversation.
First drafts of a recommendation usually tell the story in the order the work happened: what we looked at, what we found, and on page four, what we think. A senior reader wants the order reversed, with the answer first, then the reasons, then the evidence.
That’s the pyramid principle: one governing thought at the top, a few supporting points beneath it, and evidence under each point. For opening a document, Minto’s own site describes a Situation, Complication, Question framework, and most people add an A for the answer, which is where SCQA comes from.[4] Here’s the change on a typical memo.
| Version | Opening |
|---|---|
| Before (in the order the work happened) | Over the past quarter we reviewed how the team builds weekly reports and compared three reporting tools. Our findings are set out below. |
| After: Situation | The team’s weekly reports run on a tool that renews each January. |
| After: Complication | The tool can’t take two of the data sources the reports now depend on, so most reports are rebuilt by hand. |
| After: Question | Should we renew, replace or renegotiate? |
| After: Answer | Renegotiate for a shorter term, and test one replacement on the two reports that take the longest. |
An illustration of the format. The reader knows the recommendation before the second paragraph.
AI is good at this job because it’s mostly reordering and tightening. That’s also the risk, because reordering can make a thin argument sound settled. So give it your answer and your material, and ask it to mark which points the material backs up.
| Here is my draft recommendation: [paste]. Here is the material it’s based on: [paste notes, data or quotes]. Restructure the draft answer first: a one-sentence answer, three supporting points, then evidence under each. Use only my material. After that, list each supporting point and say whether my material fully supports it, partly supports it, or doesn’t support it. Don’t add claims I haven’t given you. |
Write the one-sentence answer yourself first. You’ll be the one defending it.
The “doesn’t support” lines are the useful output. Each one is either something to find evidence for or a sentence to cut.
A 2×2 makes a long list look decided in a hurry, and it can hide an opinion inside a coordinate. Ask AI to place a dozen initiatives on impact against effort and it returns confident positions with sensible reasons. Those positions come from what projects like these usually cost, not from your team’s calendar or your customers.
AI can sort and challenge a prioritisation. The scores are yours.
The practical version has three steps. Write one sentence for what “impact” means here and one for what “effort” counts. Score each item from 1 to 5 yourself. Then paste your criteria and scores into AI and ask it to look for contradictions, not to re-score.
| Lower effort | Higher effort | |
|---|---|---|
| Higher impact | Do first: automate the weekly status report | Plan properly: rebuild the onboarding process |
| Lower impact | Do if there’s a gap: tidy the shared drive | Drop for now: a custom dashboard for one team |
An illustration of the format, with placements that come from scores a person can defend. To move an item, change a score and say why, instead of asking the model again.
| Here are my criteria. Impact means: [one sentence]. Effort means: [one sentence]. Here are my items and my scores out of 5: [list]. Don’t change my scores. Point out any pair where my scores seem to contradict my own criteria, and any item where you’d want evidence before trusting the score. Then lay the items out as a 2×2. |
Contradictions give you a second reader. New scores give you the model’s guess about your business.
80/20 answers a different question. A 2×2 sorts judgments, while 80/20 needs a real number on every item. The idea traces to Vilfredo Pareto’s observation in the 1890s that a few people held most of the wealth, and Joseph Juran later generalised it into the “vital few” and the “trivial many.”[5] It’s a rule of thumb, and your data decides whether the split is 80/20, 70/30 or something else.
Use it on lists with a figure attached, such as tickets by cause, spend by vendor or hours by report. Let AI sort and total the figures, then check the arithmetic against your source sheet. A model asked to find an 80/20 pattern can report one the numbers don’t contain.
Used this way, AI does real drafting work in all four tools, so it’s worth writing down where its job ends. Here’s a split a team could adopt for a recurring review, with the checks named so they actually happen. Our guide to human-in-the-loop guidelines goes deeper.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Drafts an issue tree and names each splitting logic | Which branches are live here, and what’s missing | Break test, plus three real facts placed under one branch each |
| Proposes competing hypotheses and a check for each | Which check to run, and the conclusion drawn from it | Check result logged before a hypothesis is kept or dropped |
| Reorders a draft answer first and marks unsupported points | The answer, and what to do about each unsupported point | Author walks a colleague through the support list |
| Challenges inconsistent scores, totals figures | The criteria, the scores, the final order | Totals spot-checked against the source sheet |
A starting split. Adjust owners and cadence to your review rhythm.
Which tool you lean on depends on the role:
A team can start on its own with the prompts above, and plenty will. Hands-on training shortens the learning curve: people practise the break test on their own real questions and agree what a pass looks like, so a structure one person drafts gets checked the same way by the next. Training builds that capability, and workflow design gives it a home, such as a review template with a “what would rule this out” field. Reinforcement comes from a manager who asks for the field, and adoption is what you see once that’s routine.
To tell whether it stuck, look past how often people prompt for trees:
| Level | What you’d look at | Who checks, and when |
|---|---|---|
| Use | Are structures being drafted with AI for real questions? | Team lead, monthly, from the review documents |
| Persistence | Is the break test still being run a month on, without a reminder? | Team lead, quarterly |
| Impact | Do reviews catch fewer missing branches late, and do decisions change when a hypothesis is ruled out? | Team lead with a senior reviewer, quarterly |
Persistence and impact need a person reading real work.
If a question turns mostly on information only you hold, the fit test in when not to use AI at work shows whether to draft with AI at all.
For this week, take one question you’re already working on and write it as a sentence with the decision it feeds. Ask AI for competing hypotheses without telling it yours, then run the four break-test questions on whatever comes back.
In our judgment, the ones that produce a structure you can test: issue trees, hypotheses with checks, answer-first outlines and scored prioritisation. Frameworks that need facts only you hold, such as a competitor analysis filled in from general knowledge, tend to return generic output unless you supply those facts first.
No. Frameworks structure thinking and AI speeds up drafting the structure, but someone still has to know the business, hold the evidence and answer for the recommendation. Consultants also bring comparison across organisations, outside challenge and facilitation. Many teams use AI for the first draft and an expert for the harder questions.
Treat the disagreement as a lead and run the cheapest check that separates the two. Don’t average the views or let the more fluent one win. If no check is possible, write down which view you’re acting on and what result would change your mind.
Rarely, and that’s fine. Business questions seldom split into perfectly clean parts, so the practical goal is no double counting and no gap big enough to change the answer. Keep an explicit “other” branch, watch whether it grows as you add facts, and spend your checking effort on the branches that would change the decision.
That depends on your organisation’s policy and the tool you use, so check both before pasting anything confidential. These methods mostly don’t need raw records. A tree, a hypothesis list or a restructured memo can be built from described facts with names and figures generalised.
The Minto quotes and the MECE attribution come from Barbara Minto’s interview on McKinsey’s alumni site, and the SCQ framework from her own website. The consultant experiment is Dell’Acqua et al. in Organization Science (2026), and the sycophancy finding is Sharma et al. on arXiv (v4, May 2025). I quote only the outside-frontier figure from the BCG study, because the working paper and the journal version report different inside-frontier numbers. The prompts, break test and tables are our own designs, not validated methods, and the scenes are illustrations, not client stories.