ChatGPT Prompts for Strategy Consultants: Issue Trees and Hypotheses

ChatGPT helps a strategy consultant build an issue tree by drafting a MECE structure from a one-sentence problem, then listing testable hypotheses for each branch and the data that would prove them wrong. Use placeholders for client detail, ask for structure and questions only, and source every fact yourself before the workshop.

The model is good at breadth and weak at truth. It will give you six branches in seconds and, if asked, six market statistics that may not exist. The prompts below use it for what it does well: structuring, challenging and drafting questions. Each comes with a sample output and the checks you must run, so the thinking stays yours.

Follow me on Instagram@sagnikteaches

What can go to the model and what stays in your files

Settle the data rule first. Unless someone has switched off "Improve the model for everyone" under Data controls, a personal Free, Plus or Pro account lets OpenAI use its chats to improve models; a Business, Enterprise or Edu workspace is excluded from training by default, according to OpenAI's help page on data controls. Training is only one question, though. Client strategy, margins and unannounced plans belong in neither kind of account without the client's permission, because your engagement letter, not OpenAI's default, decides where they may go.

Connect on LinkedInSagnik Bhattacharya

A workable rule for engagements is to share the shape, never the substance. Say "a regional chain of 12 cafés with falling profit" and not the client's name, and use rounded or relative numbers ("revenue flat, costs up about 8%") rather than the real P&L. The structure of an issue tree rarely depends on exact figures. Keep the real numbers in your own spreadsheet, where you will do the analysis anyway.

Subscribe on YouTube@sagnikteaches

If a client contract restricts tools, follow it, and say in the engagement letter how you use AI. Mentioning AI use in client contracts and proposals has wording to adapt. For the commercial side of choosing tools that touch client files, questions to ask before buying AI that touches client data is a useful checklist.

Is the key question really a question? Frame it first

A bad tree starts from a bad question. Consultants know this, and yet the first draft of the key question is often a topic ("our profitability") rather than a question with an owner, a metric and a deadline. Use the model as a sparring partner for the framing.

I am a strategy consultant. Client situation (redacted, rounded): [two or three sentences].
Draft five versions of the key question in the form "How can [who] [achieve what, measured how] by [when]?"
Then tell me, for each, what it would exclude from scope and what decision the client could take from the answer.
Recommend none; I will choose.

Illustration: a regional chain of 12 cafés has seen operating profit fall for three years while revenue is flat. One sample version: "How can the chain restore operating margin to its level three years ago within 18 months without closing more than two sites?" The model notes that this excludes growth options and a sale of the business, and that the decision it supports is cost versus site closures. Choosing the version is your call, ideally with the client in the room.

What to fix: models write questions that bundle two outcomes ("grow revenue and cut costs"). Split them. A tree for two questions at once usually collapses into a list of everything the business could do.

Two rival issue trees, then three facts to break them

Now the tree itself. MECE means mutually exclusive and collectively exhaustive: branches do not overlap and together cover the question. Ask for two different structures so you can compare logic rather than accept the first.

Key question: [paste the chosen question].
Build two alternative issue trees, three levels deep, each MECE.
Tree A: split by profit equation (revenue minus costs, each broken into drivers).
Tree B: split by customer or site segment.
Present as indented lists. For each tree, list one place where branches might overlap and one thing that might fall outside all of them.

A sample Tree A for the café chain starts: Operating profit = Revenue − Costs. Revenue = number of transactions × average spend. Transactions = footfall × conversion, split by site type. Costs = ingredients, labour, rent, other. Labour = hours × rate, with an overtime branch. The model's own flag says "Delivery-app commission could sit under revenue (net) or costs (fees)": that is the overlap, and you have to decide where it lives.

Then break the tree on purpose. Choose three random facts about the business ("a new coffee machine lease", "a council road closure outside two sites", "a supplier price rise") and ask which branch each belongs to. If a fact fits two branches or none, repair the structure. This is a test of the tree, not of the model.

The wider point: an issue tree is a thinking tool, not a deliverable. If you can explain it in a minute without the diagram, the structure is probably good. If you need the slide to understand it, it is not yet right. For desk research that follows a tree like this, AI tools for desk research and market sizing covers the next step.

Hypotheses that could be proved wrong, leaf by leaf

Hypothesis-led work starts with an answer to disprove. A good hypothesis is specific, falsifiable and tied to data you can get. A poor one is a topic dressed as a claim ("pricing may be an issue"). The prompt asks for the kind that can be killed.

For each leaf of the chosen issue tree, write one hypothesis that could be proved wrong.
Format a table: branch | hypothesis | data that would support it | data that would refute it | where I would get that data | effort (hours).
Make each hypothesis specific enough to contain a direction and a rough size, for example "labour cost per transaction rose faster than average spend".
Do not state any factual figure as true; mark all numbers as illustrative.

This is an illustrative sample. The "refuted by" column is the most valuable one; if you cannot say what would disprove a hypothesis, you are collecting evidence for a belief. Sort by effort and potential size to get a workplan: here, footfall and attachment rate are cheap tests that run first.

Check each hypothesis for two faults. First, is it a rephrasing of the branch name? Second, does it quietly assume the answer, such as "poor management is the cause"? Rewrite both kinds, and delete any you cannot test within the project's budget.

Which tests run first: impact times ease, on your scores

Ranking is where you add the judgement. Give the model your own rough scores and let it do the layout, not the scoring.

Here are my hypotheses with my own scores out of 5 for potential impact on profit and ease of testing: [paste table].
Compute a priority score as impact multiplied by ease, sort from highest to lowest, and list the top four with a one-line reason each, using only my scores.
Do not change my scores. Flag any pair where one hypothesis depends on another being true.

Check the arithmetic yourself. Impact 4 and ease 5 give 20, impact 5 and ease 2 give 10. Language models occasionally slip on a multiplication in a longer table, so recompute at least the top four. The dependency flag is a useful extra: "the rota hypothesis depends on the sales-by-daypart data being reliable" tells you to check data quality first.

Interview guides that test hypotheses without leading

Before a workshop you usually speak to six to ten people: site managers, finance, the owner, a supplier. A tailored guide beats a generic one, and a model is quick at building it from your hypotheses.

Write a 30-minute interview guide for a [role, for example site manager] to test these hypotheses: [paste top four].
Include: opening (2 minutes, purpose and confidentiality), six open questions that do not lead the witness, a probe for each, one question asking what I have not asked, and a closing.
Avoid questions that can be answered yes or no. Do not reveal my hypotheses in the wording of the questions.

A sample question for the site manager: "Walk me through a typical Tuesday afternoon: who is on, who comes in, what happens?" with the probe "What do you do when it is quiet?". That question tests the rota hypothesis without saying so. The model tends to write leading questions ("Do you think the rota is too heavy?"), so scan each one for a built-in answer and rewrite.

Tailor the guide per role by changing one line of the prompt. A supplier interview should explore price history and terms; a finance interview should confirm definitions of margin; an owner interview should ask about constraints and sacred cows. Consistency across interviews lets you compare answers later.

How could this engagement fail? A pre-mortem prompt

Before the workshop, ask the model to attack your work. A pre-mortem imagines that the project has failed and asks why. It is cheap, and it surfaces blind spots such as an unsupported assumption or a stakeholder you forgot.

Assume the engagement has finished and the client says the work was not useful. Using my key question, tree and hypothesis list below, write the eight most likely reasons, each with an early warning sign I could spot in the next two weeks and one action to prevent it.
Be specific to this project; avoid generic project-management advice. [paste]

Typical sample outputs include "the sponsor wanted a closure list and we gave them a diagnosis", "the data from two sites is incomplete" and "the workshop attendees were not the people who control the rota". Pick the three that scare you and fix them this week. Ignore any the model invents about things outside the project.

A 90-minute workshop plan that ends in decisions

When the evidence is in, a workshop turns findings into decisions. The prompt drafts a running order so that the room spends time on choices, not on re-reading analysis.

Draft a 90-minute workshop plan for [number] senior attendees to decide between the options below.
Findings (rounded, redacted): [paste]. Options: [list].
Include timings, who speaks, the question for each segment, the output of each segment, and what we need decided by the end.
Put discussion before voting. Leave no segment longer than 20 minutes.

Check that the timings add up to 90 minutes; models sometimes produce 105. Remove any segment whose output is vague, such as "align on vision". Every block should end with something that can be written down: a ranked list, a decision, or an owner for an action.

Tree B in practice: splitting by site and finding the outlier

The profit-equation tree tells you which driver moved; the segment tree tells you where. Using the same illustrative chain of 12 cafés, split by site type: four high-street sites, five office-district sites and three station sites. Ask the model for the sub-branches under each type that would explain a profit fall (footfall, lease terms, local competition, rota) and then test the segments with a one-line check: which type contributes most of the fall?

Suppose the till and cost data you hold shows the profit fall of $240,000 across three years splits $30,000 for high-street sites, $190,000 for office-district sites and $20,000 for stations. The outlier is obvious: office-district sites account for about 79% of the fall ($190,000 of $240,000). That one number redirects the project. The hypotheses now centre on office attendance patterns and weekday rotas, not menu pricing or supplier terms. This is how a tree earns its place: it points you at the data that decides the question.

Ask the model to help with the next step only after you have the numbers: "Given that office-district sites explain most of the fall, list six hypotheses specific to those sites and the data to test each." Because you gave it a real finding, the output is narrower and more useful than the first round. Always keep the order: your numbers first, its suggestions second.

Coding interview answers against your hypotheses

After eight interviews you will have pages of notes. A simple coding step keeps the findings honest. Paste redacted, shortened notes into a new chat and ask for a table with one row per hypothesis and columns for supporting comments, contradicting comments and number of interviewees mentioning it. Tell it to quote the note text it relied on, so you can check each row.

An illustrative result: "Rota overstaffs weekday afternoons: supporting (4 of 8 interviewees: two site managers said afternoons are quiet, one said staff are sent home early, one said overtime is rare); contradicting (1 of 8: the area manager said afternoon staffing is minimum already)". Check the counts against your notes. Models miscount, and a claim of "6 of 8" that was really 4 of 8 changes the strength of your evidence. Where the quotes do not appear in your notes, delete the row.

One discipline helps: record who said what in your own notes, never in the prompt. The prompt contains roles ("site manager 1") not names, which keeps people out of the chat and out of any workshop slide that quotes them.

A quick sum to keep hypotheses honest about size

Before you spend a week on a hypothesis, size it roughly. Ask whether, if true, it could explain a meaningful part of the problem. In the café example, say the rota hypothesis affects the five office-district sites. If each runs about 14 surplus labour hours a week at $16 an hour, that is 14 × 16 × 5 = $1,120 a week, or about $58,000 a year. Against a $190,000 fall at those sites, it explains roughly 31%. That is worth testing first, but it will not explain everything, so the tree must still carry other branches.

Do this sum yourself with your own inputs rather than asking the model to invent the hours and rates. Then paste the result back and ask: "Given this size, which other branches would need to contribute to close the gap, and what would they have to be worth?" The answer gives you a coverage check: if the top three hypotheses add up to 60% of the fall, the remaining 40% needs a further hypothesis or an honest "unexplained" line in the workshop pack. Saying "we explain about two thirds" is far more credible than a tidy story that accounts for 100%.

Explaining the tree to the client in plain words

Clients who have not seen an issue tree can be put off by the diagram. Ask the model to translate it into three short paragraphs: what question we are answering, how we split it, and what we will check first. Add "no consulting jargon" and "no word longer than needed". A sample: "We are asking why profit has fallen. We have split it into money coming in and money going out, and within each into what drives it. First we will check the three cheapest ideas: rotas, supplier prices and footfall at two sites." Read the result aloud. If you would not say it to the owner over coffee, rewrite it.

When an issue tree goes wrong

• The tree is a list. If your second level has fifteen items, the split is not doing its job. Regroup into three to five branches by a single logic.
• Mixed logics at one level. "Revenue, costs and new competitors" mixes accounting with market structure. Choose one split per level.
• Solutions in the branches. "Open a loyalty scheme" is an action, not a branch. Move it to the hypothesis stage.
• A tree that matches the client's org chart. Easy to explain but it hides cross-functional causes. Test it against a problem that cuts across departments.
• Model-flavoured buzzwords. "Operational excellence" and "customer centricity" are labels, not drivers. Replace them with the measurable thing.

Each of these shows up quickly when you read the tree aloud or hand it to a colleague for two minutes. If they cannot say what each branch contains, the branch needs rewriting.

The verification routine every consultant needs

The model does not know the client's market, and it speaks with the same confidence whether right or wrong. Build a routine that makes that irrelevant. First, strip every factual claim from the outputs: market sizes, growth rates, benchmark ratios, regulations. Second, list each in a notes document with a source column. Third, fill the column from a primary source you have opened: the client's data, a statistics office, a company filing, a named industry report. If you cannot, delete the claim.

Fourth, check named frameworks: ask yourself whether the model really described the framework as practitioners use it. A mis-described "Porter's Five Forces" in a client deck costs credibility fast. Fifth, scan for numbers that look too tidy ("a 37% improvement") and ask where they came from. A realistic mistake: a junior consultant pasted a "typical café labour cost of 32% of sales" from a model into a slide. No source existed, and the client's own figure was 36%. The slide was pulled an hour before the workshop.

The positive version of the rule is a good one for the whole team: the model proposes structure and questions, and the consultant disposes with evidence. For a broader view of the limits of AI as an adviser, using ChatGPT as a business adviser without being misled is worth a read.

A workflow for the week before the workshop

Day one: draft five versions of the key question and agree one with the sponsor. Day two: build the two rival trees and test them against three awkward facts. Day three: write falsifiable hypotheses for each leaf, rank them by impact times ease, then start the cheap data requests. Day four: interviews, using a guide tailored to each role. Day five: run the pre-mortem and draft the 90-minute workshop plan.

Illustratively, a consultant who spends 12 hours on this in a week might save three to four hours of blank-page work, mostly on drafting guides and plans. The larger benefit is coverage: the model often suggests the branch or the interviewee you would have overlooked at 6pm on a Thursday. Keep a record of which model suggestions you accepted and rejected, and why; it will show you where it helps your thinking and where it only adds noise. If you want to set this up with a team, that is what my AI implementation consultation covers.

Questions consultants ask about using ChatGPT on client problems

Can ChatGPT produce a properly MECE issue tree?

It produces a good first draft, but branches often overlap or leave a gap. Treat the draft as a prompt for your own thinking, then test each level with the question: could one fact belong to two branches, and does anything fall outside all of them?

Is it safe to put client data in a free or personal plan?

No. OpenAI says personal accounts share data for training by default unless you switch that off, and client financials or strategy are not worth the risk. Use placeholders and a made-up scale for the structure work, and keep real figures in your own files.

Should I let the model suggest hypotheses?

Yes, as a way to widen your list, not to replace it. Ask for hypotheses that could be proved wrong, with the data that would test them. Then discard any you cannot test within the project time and budget.

How do I stop confident but wrong market facts getting into a deck?

Never take a figure from the model. Ask it only for structure and questions, then source every number from a primary dataset, the client or a named report you have opened. Put the source in the speaker notes next to each figure.

Further reads

• AI Readiness Checklist for Accountants, Solicitors, Consultants — Check your firm's readiness before wider AI use.
• AI Consultant or DIY: Which Suits a Small Professional Firm? — Decide between DIY and outside help for a small firm.
• How Consultants Use AI to Write Proposals in Under an Hour — Draft the proposal that comes before the workshop.
• What an AI Consultant Can't Do for You, and What You Must Own — See what stays with you whatever tools you use.
• How to Run a Pre-Mortem Before You Launch an AI Project — Run a fuller pre-mortem on an AI project.
• ChatGPT Custom Instructions for Consultants: Setup and Data Rules — A ready-to-adapt custom-instructions set-up for consultants, how Projects hold client context, and a plain never-paste list for client data.
• Using AI in Management Consulting: Synthesise Stakeholder Interviews — A practical interview-to-theme workflow with a coded example, evidence table and contradiction check.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: OpenAI Help Center page on data controls in ChatGPT (checked 4 November 2026).