How to Use AI Like a Strategy Consultant

AI Guide #01 · The issue-tree method I use to turn a vague problem into something AI can actually investigate.

---

TL;DR: Why this method is useful

1. See how AI reaches its recommendation, step by step

2. Catch weak assumptions early and steer it back on course

3. Turn methods into repeatable systems you control (a crucial step towards AI-native learning systems)

---

Just a quick thank you to all of you reading this.

Appreciate your support more than you know.

After a few questions and requests, I’m starting a more practical series to document things I wish I had known earlier. Hope you find it useful!

---

---

By the end, you should have a small issue-tree kit you can reuse whenever the question is too big for a single prompt. It takes you from a vague complaint to a decision you can defend.

Let’s be clear, we have a trust problem with AI that isn’t going away anytime soon.

Ask a model for a strategy and it will give you something that looks like one. There will be headings, options and a confident recommendation. The weak assumptions tend to be buried underneath all that polish.

I still get caught by this. I ask for 30 ideas, or tell a coding agent to "debug this", then wonder why the answer feels generic.

A useful rule of thumb: better context usually improves the answer. But the model also needs a smaller job.

The fix is simple: make the problem smaller before asking AI to solve it. Then solve it step by step, providing only the context necessary at each step.

Strategy consultants are trained to do this with an issue tree. It sounds grander than it is. You take one difficult question, split it into smaller questions, then investigate them separately.

Breaking a big problem into smaller ones helps us think. It also gives AI a much easier job.

^{Give AI the whole map. Make it work on one branch at a time.}

Quick aside: this is the same broad pattern behind tools such as Manus Wide Research, Perplexity Computer and Claude Code agent teams. They break a larger job into smaller tasks, send those tasks to separate agents or models, then bring the results back together.

Some systems route simpler tasks to smaller or cheaper models. This can increase speed and coverage while reducing cost when the branches are independent. More agents do not guarantee a better answer. The final synthesis still needs checking.

What an issue tree actually does

Say you are deciding whether to launch a new service.

"Should we launch?" is too broad. The answer depends on a few different things:

• Do customers have an urgent problem?

• Can we solve it better than the alternatives?

• Can we deliver it reliably?

• Do the economics work?

Those questions need different evidence. Customer interviews will not tell you whether the delivery team has capacity. A margin model will not tell you whether anyone cares.

The tree stops AI blending everything into one plausible paragraph.

Consultants call a good tree MECE: mutually exclusive and collectively exhaustive. I would not get too hung up on that. For normal work, ask two simpler questions.

Can I investigate each branch separately? And together, do they cover the important parts of the problem?

If yes, the tree is good enough to start.

A worked example: "My newsletter isn't growing"

One caveat before the example: the figures below are illustrative. I chose round numbers because they make the arithmetic easy to inspect. They are not the performance of this publication.

This is the sort of problem I might once have dropped straight into ChatGPT:

My newsletter isn't growing. What should I do?

The answer would probably contain 20 ideas. Post more. Try referrals. Rewrite the landing page. Collaborate with another writer.

Any one of them might work. But the model is brainstorming against a problem it has not diagnosed.

So I would stop it and make the question narrower:

I run a weekly newsletter for people using AI in small teams.
Net subscriber growth seems to have slowed.

Help me turn that complaint into one measurable decision question.
Ask for any facts you need, one at a time.

Do not suggest solutions yet.

After a little back and forth, I want to reach something like this:

What is the main reason net new subscribers slowed during the last four weeks, and which part should I work on first?

Now AI has a job. It needs to find the bottleneck.

I would ask for a small issue tree:

Break this question into a simple issue tree.

Each branch should be a distinct possible cause.
Together, the branches should explain the whole result.

For each branch, tell me what evidence I need.
Do not suggest fixes yet.

It might produce this:

Net new subscribers slowed
├── We gained fewer subscribers
│   ├── Fewer people reached the signup page
│   └── A smaller share of visitors subscribed
└── We lost more existing subscribers

Each line is now something I can check. We have moved from "give me growth ideas" to "show me which part is broken."

Here is a made-up set of numbers to show what happens next:

Previous four weeks
900 signup-page visits
45 new subscribers
3 unsubscribes

Latest four weeks
1,100 signup-page visits
22 new subscribers
3 unsubscribes

Traffic still comes mainly from the same sources.
Email open rates are steady.
The signup form works on phone and desktop.

I would paste those numbers in and say:

Use only the evidence I have provided.

For each branch, label it:
- supported
- ruled out
- still unknown

Show the calculation.
Do not recommend actions yet.

The result should be fairly plain.

More people reached the signup page, so reach is not the immediate problem. Unsubscribes did not increase, so retention is not the immediate problem.

The signup rate fell from 5% to 2%. Conversion is the branch worth opening.

That still is not the answer. "Conversion is down" only tells me where to look next.

So I would expand that branch:

Why did fewer visitors subscribe?
├── The wrong people reached the page
├── The page did not explain the value clearly
└── The signup process caused friction

The traffic sources are roughly the same, so audience mismatch looks less likely. The form works on two devices, so obvious form failure also looks less likely.

I would still be careful here. A working form can be annoying to use, and the same traffic source can send a different mix of people. Those branches are weaker, not dead.

The next cheap test is the promise on the page.

I might show it to five people for ten seconds and ask: "What do you think you will receive if you subscribe?"

If four of them cannot give me a clear answer, I have better evidence that the promise is the problem.

Only then would I ask AI for ideas:

Work only on the unclear promise.

Write three plain-English newsletter headlines.
Each must name the reader and say what they will receive.
Avoid claims I cannot prove.

Recommend one version to test and explain why.

For example, I might change:

Notes on AI, work and strategy

to:

One practical AI workflow each week for people running small teams.

I would leave the rest of the page alone for two weeks. Then I would check whether the share of visitors who subscribe improved.

That is the method in full. Frame the question, map the possible causes, use evidence to rule branches in or out, then work on one branch.

One branch means one branch

This is where AI usually tries to escape the structure.

You ask it to investigate conversion and it starts rewriting the email, suggesting a referral programme and planning LinkedIn posts. The ideas may be fine. They belong to other branches.

Freeze the tree and give the model a narrow brief:

Keep the agreed issue tree fixed.

Work only on this branch:
[paste one branch]

Use only these sources:
[list the approved material]

Separate material claims into:
- EVIDENCE: directly supported
- INFERENCE: what follows from the evidence
- UNKNOWN: what could still change the answer

End with:
- a provisional answer
- confidence and why
- the strongest evidence against it
- the next check to run

Stop after this branch.

^{The model sees the whole problem, but receives one investigative job at a time.}

A few practical habits make this work much better:

• Give each branch its own context and only as much as needed

• Keep the original tree at the top so the model knows where the branch fits

• Save a short conclusion before moving on

• Make "we do not know" an acceptable answer

Save each branch in a decision ledger: the question, assumption, evidence, confidence, counter-evidence and next check. Mine is usually a Markdown file, but a plain document or spreadsheet works too.

The file does not give AI memory by itself. It gives you a stable record to bring into the next chat.

The more boring the tool, the more reliable it often is.

The four-prompt issue-tree kit

I would save these as four separate prompts, not one long prompt. Run them one at a time. The stop lines matter. They stop the model jumping from a vague question to a confident answer before you have checked the structure.

This is the practical side of the AI-native operating model I wrote about last week: not one clever answer, but a method you can inspect and reuse.

^{Save the kit. Run one prompt at a time: question, tree, branch memo, decision and next check.}

1. Frame the question

I need to make a decision or diagnose a problem.

My rough version:
[describe the decision or problem]

Context:
[what happened, what changed, why it matters, and any time limit]

Rewrite this as one answerable question. Do not assume the cause.

Then list:
- the assumptions hidden in my wording
- the important boundary or time frame
- the missing facts that could change the question

Give me one recommended question and up to two alternatives.

Do not suggest solutions or build the issue tree yet.

2. Map the branches

Use this agreed question:
[paste the question]

Build the smallest useful issue tree for it.

Use three to five top-level branches. Each branch must be something I can investigate separately. Together, the branches should cover the important explanations or conditions.

Add a lower level only where it helps distinguish causes.

For each branch, give:
- the question it asks
- the evidence that would support or rule it out
- any overlap with another branch

Show the tree in plain text. Then point out its weakest gap.

Do not investigate the branches or recommend an action yet.

3. Investigate one branch

Keep this question and issue tree fixed:
[paste the question and tree]

Investigate only this branch:
[paste one branch]

Use only these sources:
[list files, links, data or observations]

For every material claim, label it:
- EVIDENCE: directly supported by a source
- INFERENCE: a conclusion drawn from that evidence
- UNKNOWN: missing information that could change the answer

If the branch itself is badly framed, flag the problem. Do not silently redraw the tree.

End with:
- a provisional answer
- confidence and why
- the strongest evidence against it
- the next check
- one sentence for the decision ledger

Stop after this branch.

4. Make the decision

Use the agreed question, issue tree and completed branch notes:
[paste them]

Make the narrowest decision the evidence supports. Do not fill unknowns with assumptions.

Give me:
1. the decision or diagnosis in one sentence
2. the evidence that carries most weight
3. the branches ruled out, and why
4. the important unknowns that remain
5. the cheapest reversible next action
6. the result that would make us change course

If the evidence is not strong enough, do not force a recommendation. Name the single next check that would most reduce the uncertainty.

When the tree is weak

Before letting AI investigate, check the shape. A weak tree usually has one of these problems:

• It mixes causes, symptoms and solutions on the same level.

• Two branches need the same evidence, so they overlap.

• A branch is too broad to test in one pass.

• The wording assumes the answer.

• The branches miss an obvious alternative.

• You cannot say what evidence would rule a branch out.

Fix the tree first. A clever investigation cannot rescue a badly framed tree.

Debugging is an issue tree with logs

The same method works particularly well for code.

Imagine this bug:

I click Save. I see a success message. But the item is missing after I refresh.

"Please debug this" gives a coding agent a large search space. I would split it first:

The saved item is missing
├── The browser never sent the right request
├── The server rejected or mishandled it
├── The database did not persist it
└── The read path or interface hid it

^{A vague bug becomes four groups of causes that can be tested separately.}

Now the investigation has an order.

Did one request leave the browser? What status came back? Does the database contain the record? Can the read endpoint return it? If it can, why did the interface hide it?

Each answer removes part of the tree.

A plug-and-play debugging harness

Cursor's Debug Mode is built around this loop and I personally use it all the time in engineering.

Cursor generates several hypotheses, adds targeted runtime logs and asks you to reproduce the bug. It uses the resulting state, execution path and timing evidence to choose a cause.

After the fix, it asks you to repeat the same steps. If the bug is gone, it removes the temporary instrumentation.

I would give it a brief like this:

The Save button shows success, but the item is missing after refresh.

The harness runs through roughly these steps:

Before changing code:
1. Split the causes into browser state, request handling,
   server logic, database write and display.
2. Say what evidence would distinguish each branch.
3. Add the minimum logging needed to test them.
4. Ask me to reproduce the bug once.
5. Eliminate branches using the runtime evidence.
6. Make the smallest supported fix.
7. Ask me to repeat the same steps, then remove the logs.

The reproduction steps matter. So do the expected result, the actual result and the last version known to work. Without those, the agent is still guessing.

Coding is easier to harness because the outcomes are testable. For non-coding work, we have to supply the harness ourselves: the issue tree, the evidence boundary and the stop condition. Judgement still sits with us.

Brainstorming has the same failure mode

The same failure shows up in brainstorming.

Ask AI for "30 post ideas about AI" and you will get 30 versions of familiar internet content.

The model has started with titles before it understands the reader, the outcome or the proof.

This article began as a rough thought about using AI like a consultant. It could have become a vague piece about better prompts. The tree made it more useful.

^{Work out the reader problem, useful outcome and proof before choosing the format.}

The branches were:

• Reader: someone getting polished but vague answers from AI.

• Outcome: they can build and use a simple issue tree.

• Proof: a debugging example and a worked decision.

• Form: an illustrated beginner's guide with prompts to copy.

Only then did the article have a shape.

You can use this prompt for almost any piece:

I want to create one useful piece about:
[broad topic]

It is for:
[specific reader]

Ask me one question at a time to clarify:
- the reader problem
- the useful outcome
- the proof I can show
- the best format

Do not suggest titles until those four are clear.

This does not make creativity mechanical. It stops AI using volume as a substitute for thought.

Which tool should you use?

I would not choose the tool first. I would ask where the evidence lives. If it is in a folder of documents, use the chat tool you already know. If it is in code, use an agent that can inspect the repository.

• Use ChatGPT, Claude or Gemini to frame a question, build the first tree and work through documents you provide

• Use Cursor Debug Mode when a bug is reproducible and runtime evidence will separate the causes

• Use Claude Code locally when the evidence lives in a repository, tests or logs

• Use a plain document or spreadsheet to keep the tree, branch conclusions and decision ledger together

In each case, give the tool the map, the evidence boundary and the stop condition. Otherwise, you are relying on the model to organise itself.

The part I still would not delegate

AI can draw the tree faster than I can. It can keep evidence tidy and notice a missing branch.

I still own the question, the structure and the point at which the evidence is good enough to act. Those are judgement calls, and the model does not carry the consequence of getting them wrong.

In consulting, issue trees often ended up in decks with workstreams, owners and weeks of analysis behind them. You do not need that machinery to use the useful part.

The useful part is the interruption. Before AI gives you 20 answers, make it show you the structure it is using to explain the problem.

If the tree is wrong, fix it before the model does anything clever.

---

Cheers. If you try the kit on a real problem, send me the tree!

In the meanwhile, all the best, J.