The problem with asking for strategy
Ask any capable model to *"advise a mid-sized logistics firm on growth strategy"* and you'll get something fluent, structured, and worthless. Three horizons. A two-by-two. Quick wins, medium-term plays, long-term bets. It reads like advisory work and contains no advice.
This isn't a model limitation. It's a specification problem. The request has no constraints, so there's nothing to reason against, and the most probable output is the average of every strategy document ever written.
Advisory work is valuable precisely because it's *not* the average. The frameworks below all do the same thing by different routes: they force specificity that generic output can't fake.
Framework 1 — Constraint-first, not goal-first
Amateur prompting states the goal. Useful prompting states what's impossible.
Compare:
*"How should this firm grow?"* — produces the horizons deck.
*"This firm has S$400k of headroom, cannot hire before Q3, has one operations lead who is already at capacity, and a client concentration problem where the top two accounts are 60% of revenue. The owner will not take on debt. What are the two or three moves actually available, and what does each cost them?"*
The second produces advice, because most of the plausible answers have already been eliminated. The constraints do the analytical work.
How to use it in practice: before writing the prompt, list what the client has ruled out. That list is usually more informative than the brief, and clients rarely put it in writing — which is exactly why your version is worth more than a generic one.
Framework 2 — Make it argue against itself
The single highest-value move in AI advisory work, and the most under-used.
Once you have a recommendation, run:
*"You are a sceptical board member who thinks this recommendation is wrong. You are not being difficult — you have seen three companies try this and fail. Give me your four strongest objections, in the order you'd raise them in the meeting. For each, say what evidence would change your mind."*
Two things come out of this. Objections you hadn't prepared for, and — more usefully — the *evidence list*, which tells you what to go and find before the meeting rather than after it.
This works because criticising a specific proposal is a well-specified task, whereas generating one is not. You get much better output asking a model to attack than to create.
Framework 3 — Start from the deliverable, work backwards
Don't ask for analysis and hope a recommendation emerges. Write the one-sentence recommendation first, then ask what would have to be true.
*"My recommendation is: exit the two largest accounts over 18 months and rebuild on mid-market volume. Work backwards. What would have to be true for this to be right? What data would I need to defend it? Where is it most likely to be wrong? Structure it as the argument I'd need to win, not as a summary of the situation."*
This is borrowed from bid work, where it's the difference between a document that responds to requirements and one that argues a case. The same shape applies: state the claim, then assemble what supports it and what threatens it.
It also surfaces the thing you didn't want to notice — the data you don't have and can't easily get.
Framework 4 — Name the audience precisely
"Write this for the board" is not an audience. Boards contain a finance person who wants sensitivities, a founder who wants the story, and a non-executive who wants to know what could go wrong.
*"Three versions of the same recommendation. One page each. (a) For the CFO — lead with the numbers and the downside case. (b) For the founder — lead with what this makes possible and what it costs them personally. (c) For the non-executive director who joined last quarter and doesn't know the history — lead with context. Same recommendation in all three. Do not soften it for any of them."*
*"Do not soften it"* is load-bearing. Asked to write for a sceptical audience, models hedge, and a hedged recommendation is not a recommendation.
The judgement it cannot supply
Worth being direct about the boundary, because pretending it isn't there is how advisory work gets embarrassing.
Claude does not know that the ops lead is the founder's cousin. It doesn't know the board has already rejected this once, or that the CFO's real objection is about control rather than capital. It cannot tell you which recommendation is *sayable*.
That's most of what a client is buying. The frameworks above compress the analysis and make the drafting fast — they don't substitute for knowing the room. Advisory work that ignores this produces recommendations that are correct and unimplementable, which is a specific and recognisable failure.
On disclosure: the position that survives scrutiny is that the judgement and accountability are yours, and the drafting was assisted. That's true, defensible, and clients generally find it unremarkable. What doesn't survive is claiming no assistance at all.
Want to Apply This to Your Business?
We're a Singapore AI development and automation agency. Let's discuss how we can help solve your specific challenges.