One long prompt gives you a confident answer and no idea which step was skipped. Here is a four-stage method with a gate at each stage, a prompt for each, and a clear line around what stays yours.
Skip the one-giant-prompt habit. Write the question first, ask for a structure with evidence attached, test one source at a time, then ask for the strongest case against your own answer. Each stage has a prompt below and a gate that sends you back if the work isn’t ready.
Most strategic problems don’t fail in the analysis. They fail in the handoffs: the question that was never quite written down, the structure nobody tested, the evidence chosen because it was easy to find, the recommendation that nobody tried to knock over. When people bring AI to a problem like that, they usually paste in everything they have and ask for a recommendation, and a confident answer comes back. It reads like consulting work. Nothing in it tells you which of those four handoffs was skipped.
Consultants don’t solve problems in one move. They work in stages, and each stage ends with someone senior asking whether it’s good enough to build on. That habit is what a non-consultant can borrow, and AI makes it cheaper to follow because it can draft the framing, the structure, the evidence summary and the objections in minutes. What it can’t do is tell you your question is the wrong one.
The method below is a Future Factors working method, built from how we’d run this ourselves. It isn’t research, and it isn’t how any particular firm works. It has four stages, Frame, Structure, Test and Recommend, with a gate at the end of each. At a gate, a person decides whether to move on or go back.
A Future Factors working method, not research. Each stage ends at a gate that a person opens. A gate answered No sends you back, and the dashed boxes are the decision points.
This guide walks the whole run, so it stays light on individual thinking tools. Issue trees, hypotheses and the break test are covered in our guide to AI consulting frameworks. If your real question is which strategy framework to pick, our guide to using AI for strategic planning covers SWOT, PESTLE and scenarios.
One problem runs through every stage below. A head of customer support is told on a Monday that support costs have to come down, with a recommendation due before the next budget meeting. We’ll follow that problem from the first sentence to the last.
The first version of a strategic question is rarely the real one. “How do we cut support costs?” sounds clear and hides three decisions: which costs, by when, and what the team won’t give up to get there. If AI answers that question, it answers a generic one, and you get the cost-cutting advice that fits any support team.
So Stage 1 is a short brief, and you write the first draft of it yourself. Then ask AI to attack it, because a model is good at spotting the vague word, the missing deadline and the hidden assumption.
| I need to frame a strategic question before I do any analysis. My rough version: [one or two sentences]. The decision it feeds: [what will be decided, by whom, by when]. What I already know: [three to five facts]. Do not answer the question. Instead: (1) rewrite it as one sentence a decision owner could sign; (2) list every vague word and the assumption hiding behind it; (3) say what is out of scope unless I say otherwise; (4) ask me the three questions I’d most need answered before analysis could start. |
Answer its three questions yourself. If you can’t, that is a finding about the problem.
Here’s the head of support’s brief after one round. Notice that two rows came from questions AI asked and the head of support had to go and find out.
| Field | Entry |
|---|---|
| Question | Should we change how we handle our most common contact types, or reduce coverage hours, to bring support costs in line with the budget without lowering customer satisfaction? |
| Decision and owner | The head of support recommends. The finance partner and the chief operating officer decide at the budget meeting. |
| Deadline | The recommendation is due before the next budget meeting. A rough version is due earlier, to the finance partner. |
| Good enough means | A choice between options, with stated risks. Not a complete redesign. |
| Out of scope | Pricing and product changes that would reduce contact volume at the source. |
| Hidden assumption found | That cost is mostly headcount. Nobody had checked how much comes from tooling and outsourced overflow. |
A filled-in example of the format, not a client file.
Nothing moves to the next stage until a person has said yes at the gate.
Gate 1 is whether the decision owner would sign that one sentence. If the finance partner reads it and says “that isn’t what I’m deciding,” you’ve saved yourself weeks. It’s the cheapest conversation in the whole method, and it’s the one most often skipped because the team is eager to start.
With a framed question, the temptation is to ask AI for a full analysis. Resist it for one more stage. A structure comes first: the parts of the problem, split so that each part can be investigated and none is counted twice. This is the issue tree stage, and our consulting frameworks guide covers how to draft one and break it. Here, we care about what the structure has to hand to the next stage.
It has to hand over a list of things to find out. A branch that says “customer demand patterns” is a topic. A branch that says “the share of contacts that are repeat contacts about the same issue, from the ticket system” is a test. So ask for the structure and the evidence together.
| Here is my framed question and brief: [paste the brief]. Build a two-level structure for answering it. At each level, state the one logic you used to split it. For every branch, give: the claim it makes, the specific evidence that would confirm or kill it, where that evidence probably lives in an organization like mine, and how cheap it is to get (hours, days or weeks). Finish with anything that could explain the situation but fits under no branch. |
Cheap and fast evidence goes first. That ordering is yours to change.
For the head of support, the structure split cost into volume, handling time and unit cost. The “fits under no branch” line did the most work. It raised the question of whether the cost increase came from a change in how overflow work was contracted, which sat outside all three branches and turned out to be worth checking first.
Gate 2 is a check on the structure itself: does every branch have evidence that could prove it wrong? If a branch can only ever be supported, drop it or rewrite it. A person who knows the business should also read the branch list for what’s missing. AI knows how support teams generally work. It doesn’t know that your overflow contract changed last spring.
Stage 3 is where AI is both most useful and easiest to misuse. Useful, because reading ten documents and pulling out what bears on a branch is slow human work. Easy to misuse, because it will cheerfully produce an evidence summary from general knowledge when your documents don’t say what the branch needs.
The person owns one judgment here: which evidence matters. Start by writing an evidence log, one row per branch, before you analyze anything.
| Branch | Evidence needed | Source and owner | Status | What it did to the answer |
|---|---|---|---|---|
| Repeat contacts are high | Share of contacts that repeat within a few days | Ticket system export, support operations lead | Pulled | Supported. Repeat contacts cluster in two contact types. |
| Handling time has grown | Average handling time by contact type, past year | Workforce tool, workforce planner | Pulled | Weak. Mostly flat except for one contact type. |
| Overflow outsourcing costs more | Contract terms and invoices | Finance partner | Waiting | Open. This could outweigh both branches above. |
| Customers would accept fewer hours | Contacts by hour; survey comments on hours | Support operations lead | Not started | Open. |
A filled-in example of the format. The last column is what keeps the log honest.
Then hand AI the evidence, one source at a time, with strict instructions. The reason for one at a time is practical. A study of long-context models found that they tend to use information at the start and end of a long input better than information buried in the middle.[1] Ten pasted documents and a request to summarize them all is the setup most likely to lose the one fact you needed.
| Below is one source document: [paste it]. It is being used to test this branch of my structure: [paste the branch and the evidence that would confirm or kill it]. Using only this document: (1) quote the passages that bear on the branch, with their location; (2) say whether they support, weaken or say nothing about the branch; (3) list what the document does not tell me that I would need. If the document doesn’t address the branch, say so. Do not fill the gap from general knowledge. |
Run it once per source, then log the result in your evidence log yourself.
Every claim in a recommendation carries a source you can open, or a label that says it’s judgment.
If you also use AI to search for outside evidence, such as market data or what peers do, treat what comes back as leads to check. Even commercial tools built to reduce fabrication produced wrong or unsupported answers in a real share of queries in a Stanford test of legal research products, with rates between 17% and 33%.[2] That was legal research, not strategy, so don’t read the numbers across. The lesson holds anyway: open the source before the claim goes in the log.
Gate 3 has two parts. Has the evidence moved the leading answer, either toward it or away? And is the uncertainty that’s left small enough to decide on? If a branch you trusted got killed, go back to Stage 2 and restructure. If you’re stuck on the same open item twice, the question may be wrong, so return to Stage 1.
By Stage 4 you’ve probably formed a view, and that view is now the most dangerous thing in the room. AI tends to go along with the user’s view, so the order of the work matters. Draft the recommendation first, and then ask for the case against it in a separate step.
For the head of support, the evidence pointed at two contact types driving repeat contacts, and an overflow contract that could matter more than headcount. The draft recommendation was to fix the two contact types first, renegotiate the overflow terms, and leave coverage hours alone until both had been tried. Then came the part most people skip.
| Here is my recommendation: [paste it in three to five sentences]. Here is my evidence log: [paste it]. Do four things, separately. (1) Give the strongest honest case against this recommendation from the point of view of the person who would most want to reject it. (2) Assume it is a year later and the recommendation failed. List the five most likely reasons, ranked. (3) Finish this sentence three ways: ‘This only works if…’. (4) Point to any claim in my recommendation that my evidence log does not support. Don’t soften any of it. |
Run it in a fresh chat if you can, so the model isn’t defending a recommendation it wrote with you.
The second item is a pre-mortem, a technique Gary Klein described in Harvard Business Review as a way to help a team voice reservations during planning.[3] We have a full guide to running a pre-mortem with AI. The fourth item is the one that ties the whole method together, because it checks the recommendation against the evidence log you built in Stage 3.
Ask for the strongest case against your answer before the budget meeting does.
Gate 4 is yours to open, and it has three tests.
If a condition fails, the fix is usually more evidence, so go back to Stage 3. If you can’t state what the recommendation needs to be true, the question may still be too broad.
The head of support’s answer to the finance partner ended up as a choice with conditions, not a verdict. “Do these two things first, check the overflow contract this week, and revisit coverage hours only if repeat contacts haven’t moved by the following budget cycle.” That’s a recommendation someone can disagree with, which is the point.
Across the four stages AI does a lot of drafting, so it’s worth writing down who owns what. This is the split we’d put in a team’s working notes.
| Stage | What AI does | What the human owns | How it gets checked |
|---|---|---|---|
| 1. Frame | Rewrites the question, lists vague words and hidden assumptions | The question itself, and what the decision is for | The decision owner signs the one-sentence version at Gate 1 |
| 2. Structure | Drafts branches with a splitting logic and evidence for each | Which branches are live in this business, and what’s missing | A colleague who knows the work reads the branches for gaps |
| 3. Test | Extracts passages from one source at a time, flags what a source can’t support | Which evidence matters, and what the evidence log concludes | Quotes opened against the source; log reviewed before Gate 3 |
| 4. Recommend | Drafts options, argues against them, runs a pre-mortem | The recommendation, and putting your name on it | Each claim traced to a source or labelled as judgment |
A starting split. Adjust owners to your team.
The roles change who carries which stage. A strategy analyst or chief of staff will often run Stages 2 and 3 and needs a manager to open the gates. An operations lead knows where the evidence lives but may lean on AI for structure. A finance partner is the natural check on whether numbers in the evidence log reconcile. An HR business partner can use the same run on attrition or capacity questions, with extra care about what employee data goes into which tool. Check your organization’s policy on that before pasting anything.
A team can start this on its own, and many will. Expert-led training shortens the learning curve and gives everyone the same standard for what a gate means, so one person’s Stage 2 gets checked the same way as the next. Training builds that capability. Workflow design gives it somewhere to live, such as a one-page template with the four gates on it. Reinforcement is a manager who asks to see the gates. Adoption is what you notice once asking has become routine.
| Level | What you’d look at | Who checks, and when |
|---|---|---|
| Use | Are real problems being run through the four stages, with a gate record? | Team lead, monthly |
| Persistence | Are gates still being opened by a person a month later, without a reminder? | Team lead, quarterly |
| Impact | Do fewer recommendations get reversed after the meeting, and do decisions change when evidence kills a branch? | Team lead with a senior reviewer, quarterly |
Persistence and impact need a person reading real work, not a usage count.
This method has costs, and some problems shouldn’t go through it. Skip or pause it in these cases:
Our fit test for when not to use AI at work is a good check before you start.
It’s also slower than one long prompt, on purpose. A small decision doesn’t need four gates; a short Frame and a short Recommend may be plenty. The method earns its time on decisions that are expensive to reverse, or that someone senior will question.
For this week, take one problem you’ve been circling and write the framing brief in the table above, using the first prompt. Show the one-sentence question to whoever will decide, and don’t start Stage 2 until they agree it’s the right question. If you want a second pair of eyes on how your team runs it, that’s the kind of work our bootcamps and corporate workshops are built for.
It can do a lot of the drafting a consultant team does, such as structuring a problem, summarizing documents against a question and arguing against a draft. It can’t own the question, know which evidence matters in your business or answer for the recommendation. Treat it as fast, fallible support for those four calls, which stay with you.
That depends on the decision. A small one can take a couple of hours with short versions of each stage. A decision that’s expensive to reverse deserves days, mostly spent getting evidence in Stage 3, not prompting. The method is slower than one long prompt on purpose.
Say so in the recommendation. Label the claims that rest on judgment, state what you’d check if you had more time, and decide whether the open item is small enough to act despite. If it isn’t, that’s a signal to go back to Stage 1 and narrow the question.
A fresh chat per stage is the safer habit, with only the brief, the structure or the evidence log carried across. Long conversations drift, and a model that helped write a recommendation tends to defend it. Use a new chat for the stress test in particular.
That depends on your organization’s policy and the tool. Check both before pasting anything confidential. Much of this method works with generalized facts and figures, and Stage 3 can often be run on extracts that don’t carry names or personal data.
The Four-Gate Method, the prompts and the tables are Future Factors working designs, not validated methods or research findings, and the head of support in the worked example is an illustration, not a client story. The long-context finding is from Liu et al. (TACL), and the legal research tool rates are from Magesh et al. (Stanford, 2024); they are used only for the limits of AI evidence work, not as strategy benchmarks. Klein’s Harvard Business Review article is cited for the premortem idea only: I couldn’t read its full text, so I left out its figures. The article that prompted this topic is behind a paywall, so none of its content is used here. Sources were checked on October 6, 2026.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.