Planning Is Mostly Translation

Most planning failures aren't strategy failures. They're translation failures. You have ten Slack threads, three exec asks, a half-baked customer interview, two engineer concerns, and a deadline. Somewhere in that pile is a quarter. AI's job is to compress that mess into something a human team can actually argue about.

Treat the model as a translator, not an oracle. Feed it raw inputs and ask for structure back. You stay the decider.

Below are the raw inputs for next quarter's planning:
- 6 stakeholder asks (pasted)
- 3 customer interview notes (pasted)
- Current OKR draft (pasted)
- Last quarter's miss list (pasted)

Cluster these into 4-6 candidate themes.
For each: the underlying problem, who's asking,
evidence strength (strong/weak/anecdotal), and
the cheapest test that would confirm or kill it.
Do not pick winners. Just sort the pile.

Notice what you didn't ask for: a roadmap, a recommendation, or a verdict. You asked for clustering. That's the part humans are bad at and models are good at. Picking is your job.

Write OKRs the Model Can Attack

Bad OKRs read like wishes. "Improve onboarding." "Drive engagement." A model will happily generate a hundred of those. Don't let it.

Force the structure first, then let AI stress-test it:

Here's a draft OKR:
Objective: [paste]
KR1: [paste]
KR2: [paste]
KR3: [paste]

Critique it as a skeptical VP. Specifically:
1. Which KRs measure activity instead of outcome?
2. Which could be gamed without moving the objective?
3. Which depend on teams not on this list?
4. What would have to be true for all three to hit?
5. Rewrite the weakest one two ways: more ambitious,
   and more honest.

The "what would have to be true" question is the one that earns its keep. It surfaces the assumptions you were quietly hoping nobody would name. If the answer is "marketing ships a campaign we haven't briefed yet," you don't have an OKR — you have a hope.

Run this critique on every objective before it leaves your laptop. You'll cut a third of them. The remaining two-thirds will be sharper than anything that survives a group edit.

Stress-Test Scope Before Kickoff

Scope decisions made in planning rooms tend to be optimistic. The team is fresh, the slides look clean, and nobody wants to be the person who says "this is too much." AI doesn't have that social cost. Use it.

For every initiative on the roadmap, run this pass:

Initiative: [one-paragraph description]
Proposed timeline: [e.g., 8 weeks]
Team: [roles and headcount]
Definition of done: [paste]

List every assumption baked into this scope.
For each, rate the risk it's wrong (low/med/high)
and what happens to the timeline if it is.
Then list the top 5 dependencies on other teams
or systems that aren't named in the plan.
Finally: what's the smallest version of this
that still delivers the core value?

That last question is the one that quietly reshapes your quarter. Most "8-week" projects have a 3-week version hiding inside them. Ship the 3-week version, learn, then decide if the other 5 weeks are still worth it. Aggressive scope cutting is the highest-leverage planning move you have, and AI is unusually good at finding the seam.

The course at /courses/ai-for-managers-playbook works through this exact stress-test loop with examples.

Surface Dependencies Nobody Mentioned

Roadmaps die in the gaps between teams. The platform migration that quietly blocks your launch. The legal review that takes four weeks, not four days. The shared service team that has no idea you're depending on them.

AI can map these for you if you give it enough to chew on:

Here are the 6 initiatives planned for Q3 across
our org (pasted). For each, list:
- Other teams whose work it relies on
- Shared systems, infra, or data it touches
- External vendors or contracts involved
- Compliance, legal, or security gates it'll hit

Then produce a dependency matrix: which initiatives
share a dependency, and what conflicts that creates.

What you get back is messy and partly wrong. Don't care. Even a half-right dependency map is more than most teams have on day one of a quarter. Walk it with the actual humans named in the output. That conversation — "hey, are we on your radar?" — is the entire point. The map is just the excuse to have it.

Roadmaps That Survive Contact With Reality

A roadmap is a communication artifact, not a contract. Its job is to make trade-offs visible, not to predict the future. AI helps you build the version that survives one bad sprint.

Build it in three layers, with the model handling each pass:

1. Now (this month): committed, scoped, dependencies cleared. Confidence high.
2. Next (this quarter): directional, scoped to within 30%, dependencies named.
3. Later (this half): themes only. No dates. No deliverables.

Then ask the model the question that exposes theater:

Here's our Now/Next/Later roadmap (pasted).
Pretend you're an engineer on this team who's
seen three quarters of plans miss. Which items
read as theater — there to please a stakeholder
but not seriously resourced? Which items are
under-committed because someone is hedging?
Be specific. Quote the language that tips you off.

That prompt is uncomfortable on purpose. The point of planning is not to produce a deck. The point is to make commitments you'll actually keep, and to be honest about the ones you won't. AI gives you a cheap rehearsal of the conversation your team is already having about you behind your back.

What to Do Monday

Open last quarter's plan. Paste it into a model alongside what actually shipped. Ask: where did scope drift, where did dependencies bite us, where did we let theater survive? Use that diagnosis to design this quarter's planning differently — sharper OKRs, smaller first slices, named dependencies, and a roadmap that admits which parts are guesses. Planning gets better the moment you stop pretending it's prediction and start treating it as the team's clearest argument with itself.