Week 13, 2026
One of the least talked‑about responsibilities of a product manager is not prioritization, but capacity stewardship. Engineering time is finite, cognitive load is real, and demand always exceeds supply. On any given week, we’re expected to improve security, keep the system running, support customers and internal teams, and still make meaningful progress on the future. This tension isn’t a failure of planning it’s the natural state of product work. The question isn’t how do we do everything, but how do we design a system that survives reality.
A key principle from operations and product literature is that planning for 100% utilization is a trap. Eliyahu Goldratt’s Theory of Constraints argues that systems with no slack collapse under variability the moment something unexpected happens, throughput suffers and firefighting begins. Capacity, Goldratt notes, is not waste; it is a buffer against uncertainty. This is why many experienced product teams intentionally plan for ~70% of their velocity, leaving ~30% unallocated. That buffer absorbs incidents, urgent requests, and dependencies and when the system is calm, it becomes space for learning, improvement, and stretch goals. This idea shows up repeatedly across Lean, TOC, and modern capacity‑planning practices, even if the percentages vary.
Once you accept the need for slack, the next challenge is where the planned capacity goes. This is where the 4 Buckets come in. Bucket‑based thinking isn’t new Adam Nash popularized a version of it with his Three Bucket Framework (metrics movers, customer requests, delighters), while many PM teams implicitly use variations of the Eisenhower “important vs. urgent” model. The 4 Buckets + Buffer Model adapts that thinking to ongoing product operations:
(1) Security & Compliance, (2) Keep the Lights On, (3) Customer & Internal Requests, and (4) Future Investments. These buckets represent persistent responsibilities, not temporary initiatives, and they help elevate prioritization from individual tickets to strategic intent.
Allocation then happens at the bucket level, but the split can’t be arbitrary it needs to reflect your organization’s strategy and ladder directly to your Objectives and Key Results (OKRs). In other words, buckets are how you structure capacity, but OKRs are how you justify it: OKRs are explicitly designed to keep teams aligned and focused on outcomes, not just activity. In practice, that means you don’t just ask “which bucket does this belong to?” you also ask “which objective or key result does this advance?” This is exactly why OKRs and roadmaps are often described as complementary: OKRs clarify what success looks like and create alignment between strategy and delivery, while the roadmap (and your bucket allocation) translates those goals into the work you fund and sequence. Allocation then happens at the bucket level, not the backlog level. Instead of every request competing emotionally for attention, capacity is intentionally distributed across buckets within the planned 70%. When something new appears and it always does the conversation changes. It’s no longer “Is this important?” but “Which bucket does this belong to, and what tradeoff are we making?” This mirrors Goldratt’s idea of subordinating work to the system constraint and avoids the common anti‑pattern of silently stealing time from long‑term investments to feed short‑term urgency.
The real finesse of the 4 Buckets + Buffer Model is not the structure it’s the discipline. Buckets drift if they’re not protected. Urgency has gravity. Left unchecked, everything slowly collapses into “keeping the lights on”. Regularly revisiting bucket allocation monthly or quarterly makes tradeoffs explicit and prevents accidental strategy. Product management, at its core, isn’t only about maximizing utilization; it’s about designing a system that continues to make good decisions under pressure. Slack isn’t laziness. Buckets aren’t bureaucracy. Together, they’re what allow teams to deliver today and still have a tomorrow.
DISCLAIMER: This post reflects my personal views and experiences as a product manager. It does not represent the views, strategies, or opinions of my employer or any organization I am affiliated with.
