You spend a week planning the quarter. Build a roadmap. Prioritize features. Assign resources. Get buy in from stakeholders.
Two weeks later, a major customer requests something urgent. A competitor launches a feature you need to match. The CEO has a new vision. A technical issue forces you to pause planned work.
The roadmap is already outdated.
So you replan. Adjust priorities. Shuffle the backlog. Communicate the changes.
Then it happens again. And again.
At some point you have to ask: if everything changes constantly, what's the point of planning at all?
The Illusion of Stability
Traditional planning assumes a relatively stable environment. You gather requirements, design a solution, build it, ship it. The plan might adjust slightly, but the fundamentals hold.
That doesn't describe most modern product teams.
Markets shift fast. User needs evolve. Technical constraints emerge. Competitive threats appear overnight.
The plan you made in January might be completely irrelevant by March.
And yet, organizations still demand quarterly roadmaps, annual budgets, and committed timelines. They want predictability in an inherently unpredictable environment.
The Agile Promise (and Problem)
Agile was supposed to solve this. "Responding to change over following a plan."
And at the sprint level, it does. You can pivot every two weeks. If priorities shift, you adjust in the next sprint.
But here's the problem: sprints don't solve the broader planning challenge.
You still need to make bets about what to build over the next quarter. You still need to allocate people and resources. You still need to communicate direction to the team.
Agile made the micro flexible, but the macro still demands planning.
What Actually Works
Teams that thrive in high change environments plan differently:
1. Plan in shorter horizons
Forget annual roadmaps. Plan the next 4-6 weeks in detail, the next quarter in themes, and beyond that in vague direction.
The further out you go, the lighter the plan.
2. Plan around bets, not features
Instead of "we'll build X, Y, and Z," say "we think improving onboarding will have the biggest impact, so we'll explore that space."
You commit to the problem, not the solution. That gives you room to pivot as you learn.
3. Maintain a flexible backlog
Keep a prioritized list of what matters, but don't commit to the order beyond the next few items. As new information arrives, you can reshuffle without feeling like you're breaking commitments.
4. Communicate uncertainty
Be honest with stakeholders. "Here's what we're focused on now. Here's what we think is next. But we expect this to change as we learn more."
Predictability is less important than transparency.
5. Build in slack
If you plan for 100% utilization, any disruption breaks the plan. If you plan for 70-80% and expect interruptions, you have room to absorb change without chaos.
The Anti Plan
Some teams take this to the extreme: they don't plan beyond the current week.
They maintain a prioritized backlog. Each week, they look at the top items and ask: "Is this still the most important thing?" If yes, they work on it. If no, they adjust.
No roadmaps. No sprints. Just continuous reprioritization.
This works for small, fast moving teams in highly uncertain environments. It doesn't work for large organizations with dependencies and compliance requirements.
But the mindset is useful: assume the plan will change, and build systems that adapt gracefully.
The Real Skill
In stable environments, the skill is execution. Make a plan and follow it.
In volatile environments, the skill is adaptive planning. Make a plan, watch for signals that it's wrong, adjust quickly.
This requires:
- Constant communication with customers, stakeholders, and the market
- Willingness to kill plans you spent time building
- Comfort with ambiguity and incomplete information
- Trust that the team can handle change without falling apart
It's not about having the best plan. It's about having the best response when the plan breaks.
The Mindset Shift
Stop treating plan changes as failures. They're not. They're signs that you're learning and adapting.
The goal isn't to follow the plan. The goal is to ship the right thing. If the plan gets you there, great. If it doesn't, change it.
Flexibility is a feature, not a bug.
So yes, keep planning. But plan lightly. Plan iteratively. Plan with the expectation that you'll be wrong.
Because in a world that changes every week, the best plan is the one you can rewrite tomorrow.