Stop Overloading Your Roadmap: Why WIP Limits Are the Most Important Rule in Product Planning
The 40-Item “Roadmap” That Made Me Cry
Just yesterday, I was reviewing a client’s roadmap. Forty items. All marked for Q1 delivery. Across ten developers…
Some quick mental arithmetic: Ten devs. Six two-week sprints in Q1. That’s 3.3 items per developer per sprint. And this is a development team that (for various good reasons) can only do one release per month; and whose development process historically releases one feature per developer per sprint.
And these forty initiatives didn’t include time for Keeping The Lights On , handling incidents, and somehow finding time for the discovery work that would inform Q2 .
It wasn’t a roadmap. It was a wish list dressed up in a Powerpoint - a political document where every stakeholder’s priority got a row, and nobody was willing to have the hard conversation about what wouldn’t fit.
I see this ALL THE FRIKKIN’ TIME. And I feel terrible for the poor developers who haven’t a hope of being sucessful…
The Epidemic of Roadmap Overload
Every product leader has seen slides with pretty roadmaps that promise the impossible. It’s easy in PowerPoint…
Add another row…
Squeeze in one more initiative…
Adjust the font size so everything fits on one slide…
The problem is that these documents look reasonable. They have dates. They have swim lanes for initiatives with boxes for deliverables. They have colour-coded priority indicators. They have all the trappings of a plan. But they’re missing the one thing that would make them real: any connection to capacity.
A roadmap without capacity constraints is like a budget with no numbers. It’s aspirational fiction… Planning Theater.
Why Smart Leaders Still Fall Into This Trap
If roadmap overload is so obviously problematic, why do intelligent, experienced leaders keep doing it?
Fear of saying no. Every item on that roadmap has a sponsor. Someone who lobbied for it, who has tied their bonus to it, who will be disappointed—and possibly hostile—if it’s cut. Adding something is easy. Removing something creates conflict.
The illusion that parallel work equals faster delivery. If we’re working on ten things simultaneously, surely we’ll finish faster than if we work on five sequentially? This feels intuitively correct, but it’s precisely backwards, as we’ll see when we examine Little’s Law.
Optimism bias. “We’ll figure it out.” “The team will rise to the challenge.” “We’ve never failed to deliver before.” These phrases mask a fundamental refusal to do the mathematics. If the plan requires 400 hours of work and you have 300 hours of capacity, no amount of optimism changes the outcome.
HIPPO: Roadmaps that pander to the Highest Paid Person’s Opinion. “We have to do all these things to make our shareholders happy”. (If this sounds familiar, see our guide on objective prioritisation for frameworks that help make these trade-offs explicit.)
The Hidden Tax: What Over-Commitment Actually Costs
Let’s get specific about what roadmap overload actually costs.
Research by Gloria Mark at UC Irvine has tracked knowledge workers for decades. Her findings are stark : when workers are interrupted, it takes an average of 23 minutes and 15 seconds to return to the original task. Not to complete it—just to get back to where they were.
And interruptions aren’t rare. Mark’s research shows the average knowledge worker switches tasks every three minutes. Every. Three. Minutes.
When your roadmap has 40 items for ten developers, you’re not just creating a delivery challenge. You’re creating an environment of priority whiplash where developers are constantly context-switching between initiatives, where product managers are juggling too many stakeholder conversations, where nobody can achieve the deep focus that complex work requires.
The cost? According to multiple studies, context switching can drain up to 40% of productivity. One analysis calculated this as approximately $50,000 per developer annually—money literally evaporating because teams are spread too thin.
And it’s not just about money. In an eight-hour workday, developers experiencing frequent interruptions achieve only 2.3 hours of genuine deep work. The rest is overhead, task-switching, and trying to remember where they left off.
I learned this lesson the hard way at a previous company. We had a dozen major initiatives running simultaneously across a team of about 20 developers. On paper, it looked efficient—everyone was “busy.” In practice, nothing shipped. We’d spend the first few days of each sprint context-switching, the middle trying to make progress, and the final days scrambling to hand off incomplete work. After six months, we’d shipped precisely one initiative to production. The others were all “in progress,” which really meant “going nowhere slowly.” When we finally started allocating initiatives to teams rather the individuals, we delivered more in one quarter than we had in the previous two.
Little’s Law: The Mathematics of Flow
Here’s where it gets interesting. There’s a mathematical principle that explains exactly why limiting work in progress accelerates delivery. It’s called Little’s Law, and it’s been validated across industries for over sixty years.
The formula is simple:
Cycle Time = Work in Progress ÷ Throughput
Or, rearranged: the average time it takes to complete something equals the number of things you’re working on divided by how fast you complete things.
This has a profound implication. If your throughput stays constant—and for most teams, it does over short periods—then reducing WIP directly reduces cycle time. Work fewer things in parallel, and each thing finishes faster.
It’s counterintuitive. Surely working on more things simultaneously should mean more output? But Little’s Law shows why that’s wrong. When you increase WIP without increasing throughput, you don’t get more done—you just increase how long everything takes.
Think of a factory floor. If you pile up 1,000 half-assembled units, you haven’t increased production. You’ve increased inventory—and the time it takes any single unit to make it from start to finish.
Kanban’s Core Insight: Stop Starting, Start Finishing
The manufacturing world learned this lesson decades ago. Toyota’s production system, which evolved into what we now call Kanban, is built around one central principle: limit work in progress.
Toyota didn’t limit WIP because they were cautious. They limited WIP because it made them faster. By restricting how many items could be in any stage of production at once, they created a “pull” system where work only started when there was capacity to complete it.
The contrast with a “push” system is crucial. In a push system—which describes most product roadmaps—work is pushed into the system regardless of capacity. Items pile up. Queues grow. Everything slows down.
In a pull system, new work only enters when something exits. The constraint isn’t seen as a limitation—it’s seen as the mechanism that enables flow.
The mantra is simple: stop starting, start finishing.
“Compound Interest is the Greatest Power in the Universe”
Einstein famously called compound interest the most powerful force in the universe. Whether or not he actually said this, the principle applies beautifully to product development.
When you finish something—truly finish it, ship it, get it into customers’ hands—you create a compound effect that accelerates everything that follows.
Momentum compounds. Teams that ship feel like winners. They build confidence. They learn from real feedback. The next initiative moves faster because they’re riding the wave of the previous success.
Learning compounds. Deep work on one problem creates expertise that applies to adjacent problems. But this only happens when you go deep. Surface-level work across ten initiatives creates no transferable expertise—just a thin layer of understanding across everything.
Customer value compounds. Shipping something—even something small—creates real feedback loops. Customers respond. You learn what actually matters versus what you assumed would matter. That insight shapes everything that follows.
I once worked with a team that had been “working on” a price calculaton engine for nine months. It was considered business critical but somehow was a background task and had been a month from completion for 9 months. When we finally paused everything else and focused the entire team on shipping it, we got it live in three weeks. The customer feedback in the first week changed our understanding of the feature so fundamentally that the team would have wasted months more if they’d kept working in parallel on their original assumptions. Shipping early didn’t just accelerate delivery—it prevented a colossal waste of effort.
Firm Footholds: Building on Solid Ground
Years ago, when I was working with Bob Marshall on a pattern language for software development, he introduced me to a concept that’s stuck with me ever since: firm footholds.
The metaphor comes from climbing. You don’t reach for the next handhold until your feet are secure. Each position you establish provides the stable platform for the next advance. Rush it—grab for the next hold before securing your position—and you fall.
Product development works the same way. The first implementation of a feature is almost never the end of work on that feature. There’s customer feedback. There are edge cases you didn’t anticipate. There’s iteration.
If you’ve shipped 40 features at 30% completion, you haven’t created 40 footholds. You’ve created 40 points of instability that will all need rework—simultaneously. You’ve built on sand.
But if you’ve shipped 10 features at 95% completion, you have 10 firm footholds. Each one provides the stable base for the next advance. Each one generates real customer value and real learning.
As Helmuth von Moltke observed, “No plan survives contact with the enemy.” You need to maintain capacity for iteration. A roadmap that allocates 100% of capacity to new features has allocated 0% to making those features actually work.
Why WIP Limits Only Work at Squad Level
Here’s where many organisations go wrong. They talk about limiting WIP at the portfolio level—“we’ll only have 15 strategic initiatives this year”—but then they allocate individuals to multiple initiatives simultaneously.
This misses the point entirely.
As we discussed in Optimal Squad Size , the sweet spot for planning is the squad: 3-4 developers plus 1-2 supporting roles. At this level, you get collective ownership, adaptive task assignment, and the averaging out of individual variation.
But if you’re planning at the individual level—“Pete will spend 40% on Initiative A, 30% on Initiative B, and 30% on Initiative C”—you’ve recreated all the problems of high WIP at the most granular level. Pete is context-switching constantly. Nothing gets his full attention. Everything goes slower.
WIP limits must be enforced at the squad level to have any effect. A squad working on 1-2 initiatives will outperform that same squad supposedly working on 5.
The WIP: Your Unit of Capacity
In Capacity-Based Planning , I introduced the concept of the WIP: the intersection of one squad and one sprint period. This cell is your fundamental unit of capacity.
Your roadmap doesn’t have infinite cells. If you have 12 squads and 26 two-week sprints in a year, you have 312 WIPs.
That’s your budget. Every initiative you add to the roadmap consumes some of those cells. When the cells are full, you’re at capacity.
The beautiful thing about visualising capacity this way is that it makes overload impossible to hide. You can’t quietly add a 41st initiative when every cell is already allocated. The maths doesn’t work. The grid exposes it.
WIP Limits for Discovery, Not Just Delivery
Everything I’ve said about delivery work applies equally to discovery work. Perhaps even more so.
Product discovery—the research, prototyping, and experimentation that informs what you’ll build—requires deep cognitive engagement. You can’t run five discovery tracks simultaneously with any quality.
I work with a company that is going through exactly this experience. They’d hired a super-talented CTPO who still hadn’t had chance to build the team underneath him. He’s being asked to simultaneously running discovery on five massive product areas; each of which could be a full-time job. Funnily enough, none was progressing. Every insight from one track got lost while he context-switched to another. When I finally helped him push back and focusing on just the most important track (with the other four explicitly paused until next quarter) we made more progress in six weeks than the previous four months.
This is why making discovery work visible on the roadmap matters. If discovery is invisible—if it’s just something PMs do “in the background”—it creates unlimited demand on finite cognitive capacity. But when discovery is a visible allocation on the roadmap, it becomes subject to the same WIP limits as everything else.
For more on this, see Time-Boxed Discovery .
The “More People = More Parallel Work” Fallacy
So this all seems intuitive, but the number of times I encounter organisations that have no grasp of the reality of delivery is shocking. It literally happens all…. the… time…
I’m currently working with a company that had three squads. They asked for additional funding for seven temporary developers. Great, two more squads… Unfortunately they also committed that these seven developers would deliver seven initiatives in parallel.
Six months later, NOTHING has been delivered; quality has dropped off a cliff and they’re now trying to figure out how to fund the temporary teams for a further 12 months. My strong recommendation is to put five initiatives on-hold, and get some actual software delivered.
Adding squads does give you the opportunity to add more parallel streams of work. But massively increasing the WIP is just going to slow you down.
Faster delivery means faster feedback. Faster feedback means better decisions. Better decisions mean less waste. The compound effect again.
Practical WIP Limits That Work
So what limits should you actually set?
In RoadmapOne , we’ve built in configurable defaults:
- 2 items maximum per squad per two-week sprint
- 3 items maximum per squad per month
These aren’t arbitrary. They’re based on what we’ve observed working across dozens of product teams. At 3 items per sprint, squads have enough focus to make genuine progress on each. At 4+ items, the context-switching overhead starts eating into productive time.
Of course, your context may differ. These are defaults, not mandates. But I’d encourage you to err on the side of fewer items rather than more. If you’re debating between 3 and 5, choose 3. You can always increase later if teams are genuinely idle (they won’t be).
When I first implemented strict WIP limits with a team years ago, there was resistance. “But what if we finish early?” “What if there’s a blocker on one initiative?” The concerns were understandable but misplaced. What actually happened was that teams found work to fill any gaps (technical debt reduction, testing improvements, documentation, things that inevitably pop-up and need an urgent fix)and were grateful for the breathing room. And blockers got escalated and resolved faster because there was nowhere to hide.
Most importantly… we got stuff out of the door. Yeah, sometimes things took longer, but the organisation learned to trust that we’d always be approximately right rather than precisely wrong.
Making Constraints Visible to Leadership
The real power of WIP limits comes when they’re visible to senior leadership.
When a CEO can see that every squad-sprint cell is allocated, the conversation changes. It’s no longer “can you squeeze this in?” It’s “what should we take out to make room for this?”
That’s a fundamentally different conversation. It’s honest. It forces prioritisation. It makes trade-offs explicit.
Some of my best experiences with the roadmap process have been when the CPO pulled up the capacity grid and simply said, “We’re at capacity. Every cell is allocated. If we add this new initiative, we need to decide what to remove. Here are the options.”
The exec team—who moments earlier had been enthusiastically adding scope—suddenly had to make real choices. It wasn’t confrontational. It was clarifying. For the first time, they could see the constraints they’d been ignoring. And they made better decisions as a result.
Changing the Conversation
This is perhaps the most important shift. With visible WIP limits, you move from a world where:
- “Can we add this?” (answer always: yes, on paper)
- Teams are set up to fail
- Nobody understands why everything is late
To a world where:
- “What should we cut to add this?” (forces real prioritisation)
- Teams are set up to succeed
- Delivery becomes predictable
The power of saying “we’re at capacity” is immense. It’s not obstructive—it’s honest. And honest planning leads to better outcomes for everyone.
What About Urgent Work?
“But what if something urgent comes up?”
Genuinely urgent work exists. But if everything is urgent, nothing is. The point of WIP limits isn’t to prevent responding to emergencies—it’s to ensure that “emergency” is reserved for actual emergencies, not just things that someone forgot to prioritise earlier.
When you break a WIP limit, make the cost visible. Show what got delayed. Show the impact on delivery dates. This isn’t about shaming anyone—it’s about making the trade-off explicit so the organisation learns from it.
Over time, you’ll find that fewer things are “urgent” when there’s a visible cost to urgency.
The Counterintuitive Truth
Let me summarise the central insight:
Limiting work in progress increases throughput.
This feels backwards. Surely doing more things should mean more output? But the mathematics are clear. Context-switching eats capacity. Split attention creates bugs and rework. Half-finished work is inventory, not value.
Fewer parallel initiatives means faster delivery of each. Faster delivery means faster feedback. Faster feedback means better decisions. Better decisions compound into sustained improvement.
Teams are happier—they’re finishing things instead of juggling forever. Stakeholders are clearer—they know what’s actually happening. Outcomes improve—because you’re shipping real value instead of accumulating half-baked work. And when things do get backed up to a critical point, you have the option of calling a firebreak sprint to reset.
And, on the Subject of WIP…
…Don’t forget the lessons from Eliyahu Goldratt’s Theory of Constraints: don’t pile up work in front of your constraint.
In “The Goal”, Goldratt described a manufacturing team that implemented a buffer in front of their furnace (the constraint) where items were piled up - ostensibly so they could run the constraint flat out. Clearly this just massively increases WIP and actually makes it even harder when we need to push something quickly through the constraint. He argued that overloading a bottleneck with excessive Work in Progress (WIP) does not increase efficiency, but rather increases inventory costs, raises operating expenses, delays customer deliveries, and creates chaos.
In software product teams, your constraint is almost always your development process, so having well-meaning Product, Marketing and Commerical teams running around specifying chunks of functionality that are months away from being implemented is entirely wasteful. That’s an important consideration for how we prioritise and allocate our discovery time in dual track agile … as per Godratt, we need to “subordinate” all other, faster processes to the pace of the bottleneck.
It’s particularly insideous in software engineering because, while Discovery is one of our most important processes, premature Discovery a) burns time from team members who are involved in the process, b) creates WIP that might have gone stale while we’re waiting for implementation, and c) burns also a tonne of the team’s mental energy on items that are months away from implementation - even those who are not directly involved get caught up in the exhuberance and start second guessing decisions (“should I build this quickly now or do something that prepares us for the big thing that Lakshmi and Alex were discussing”).
As a CTPO, a tip that you might helpful when people come to you with “let’s build thing X” (and thing X seems like a good thing), is to say, “that sounds great, let’s put in on the roadmap for Q4” (where Q4 is the furthest away quarter than we’re planning—see our guide on quarterly roadmap planning ). That way it doesn’t get lost and people don’t feel like they’re being ignored. But they also don’t spend a bunch of time thinking that we’re about to build it so can get on with other things.
Your Roadmap Tomorrow
If you take one thing from this article it’s this:
Count how many things each squad is expected to work on simultaneously.
If the answer is more than 2, you’re going slower than you could be. Not because your team isn’t talented. Not because they’re not working hard. But because the mathematics of flow don’t care about effort. They only care about focus.
Here’s your homework:
-
Check your Squad Sizes. Three developers is the magic number
-
Audit your current WIP. How many initiatives is each squad genuinely juggling?
-
Set explicit limits. Start with 2 items per squad per sprint. See how it feels.
-
Make constraints visible. Ensure leadership can see when capacity is full.
-
Have the trade-off conversation. Oh please dear God have the trade-off conversation. When someone asks for more, ask what should be cut. Stop settings your teams up for failure.
-
Measure cycle time. Track how long initiatives take from start to finish. As WIP goes down, cycle time should too.
RoadmapOne makes this visible by default. The squad-sprint grid shows exactly what’s allocated. The WIP limits make it clear when capacity is reached. Adding something requires taking something out. It’s not a constraint—it’s clarity.
Because when everyone can see the capacity, the fantasy roadmaps become impossible. And that’s when real planning can begin.