Capacity Is the Roadmap

"Our bottleneck was capacity. We had one saw, and one person could run it at a time. Yes, we could extend the hours, and often we did. We could push harder for a while. But the real limit was still the machinery and the people around it. You cannot create skilled carpenters on the spot. You also cannot pretend you have three saws when you only have one."

"Roadmap planning is not very different. People like to talk about priorities as if the main problem is choosing what matters. In practice, the deterministic factor is capacity. Team capacity. System capacity. The share you lose to maintenance, interruptions, coordination, and keeping the machine fit to run. Ignoring these physical limits turns an ambitious roadmap into a collective illusion."

"One of the easiest ways to ruin a roadmap is to let raw demand enter as if it were already shaped work. The customer asked for this. Sales says this is urgent. We should probably do this. These are signals. A roadmap-worthy item needs more structure than that. It needs a problem statement, evidence that th"

Capacity constraints, not priority selection, determine roadmap feasibility. Like a carpentry operation limited by one saw requiring maintenance and operator changes, software teams face real constraints from team capacity, system maintenance, and coordination overhead. Raw demand signals—customer requests, sales urgency, general ideas—cannot drive roadmaps effectively. Work must be properly structured with problem statements and evidence before competing for actual capacity. Ignoring physical limits transforms ambitious roadmaps into illusions. Understanding that some capacity must always be reserved for maintenance, interruptions, and keeping systems operational is essential for realistic planning.

Read at yusufaytas.com