Just-in-Time Planning
Shrink long roadmaps to a lightweight monthly priority list and grant explicit permission to kill dead processes.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 88%
Because the field changes so fast, Fiona Fung replaced six-month roadmap docs with JIT (just-in-time) planning: a lightweight monthly priority list (a small spreadsheet, not docs) checked weekly to confirm the priorities still hold, over a backdrop of themes set roughly every six months. Underpinning it is a cultural rule — explicit permission to kill processes that no longer serve — so any dreaded, noisy, expensive, or manual process is regularly re-examined for whether it still has a purpose.
Origin
Fiona Fung, from her first big learning joining Claude Code when a lightweight six-month roadmap she introduced went unreferenced three months in.
Core principles
- 01A fast-changing field makes long-horizon plans go stale before you reference them
- 02Plan just in time: a lightweight monthly priority list, verified weekly
- 03Keep long-range themes loose, set roughly every six months
- 04Grant explicit permission to kill any process that no longer serves its purpose
How to run it
- 1
Set loose six-month themes
Bring the whole team together roughly every six months to agree on themes of where the work is heading, without heavy detail.
- 2
Plan one month at a time, lightweight
Align on the month's highest priorities in a simple spreadsheet — not docs — and let each person own how they address them.
Pro tip Keep the list short and focused so updating it never feels like a tax.
- 3
Re-confirm weekly
Each week do a quick check that the listed priorities are still this month's priorities, adjusting as the landscape shifts.
- 4
Audit and kill dead processes
Periodically pick one process you dread, that's noisy, expensive, or very manual, and ask whether it still serves its purpose — kill it if not.
Pro tip Look for ways to automate the surviving process so it stops feeling like a tax.
Watch out Even a process you introduced yourself can outlive its purpose; be willing to cut your own.
In the wild
Joining Claude Code, Fiona introduced a deliberately lightweight six-month roadmap doc. Three months in she realized the team hadn't referenced it because so much had changed, so she cut it down to JIT monthly planning on a small spreadsheet.
→ Planning shrank to a monthly priority list checked weekly, eliminating wasted planning effort while keeping the team aligned in a fast-moving field.
Common mistakes
Writing long roadmaps in a fast-changing field
A six-month plan goes stale and unreferenced within months when the landscape shifts quickly, wasting the planning effort.
Keeping a process because you always have
Failing to ask whether a dreaded, noisy, or manual process still serves its purpose lets dead work persist; the fix is explicit permission to kill it.
Is it for you?
Best for
Leaders of fast-moving teams (especially in AI) who want alignment without heavyweight roadmap overhead
Not ideal for
Long-lead, capital-intensive, or heavily regulated programs that genuinely require multi-quarter committed plans
From the transcript
“I I call it JIT planning now, like just-in-time planning.”
“we've shrunk it to JIT monthly planning.”
“explicit permission to kill processes that no longer serve us.”
“always be open to learning and always ask yourself whatever process you have is it still serving its purpose? Just because the field is changing…”
From the episode
What happens after coding is solved?
Fiona Fung (Manager of the Claude Code and Cowork Teams)