Published · 8 min read
When I was young, I worked in carpentry during the summers. Summer was busy. New buildings had to go up. Stables needed repairs. Barns needed extensions. Sheds had to be built out in the fields. Demand was high. 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.
The saw itself was never fully available, either. It needed oiling, adjusting, and occasional repairs. Blades wore down. Breakdowns happened when hidden nails turned up in the timber. Everyone swore their timber had no nails in it. Changing operators also slowed things down. In the end, part of the saw’s capacity always had to be spent just to keep it usable.
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.
Old rustic carpentry workshop
In carpentry, even if you are mostly processing standard timber sizes, the work still has to become specific before anyone can plan around it. Someone has to decide what runs next, which job it is for, and what waits while the saw is busy. Roadmaps have the same problem. Work should not enter as raw demand. It has to become clear enough to compete for real capacity.
One of the easiest ways to ruin a roadmap is to let raw demand enter as if it were already shaped work.
These are signals. A roadmap-worthy item needs more structure than that. It needs a problem statement, evidence that the problem is real, an expected outcome, a dependency view, and at least some sense of what it will displace. Until then, it is just a demand. It may be a valid demand, even an important one, but it is not ready to compete for capacity.
Big ideas should become negotiable before anyone debates where they rank. That is what shaping is for. Not a perfect prediction. Not fake certainty. Just enough definition to stop a large idea from arriving fully inflated. Good shaping exposes assumptions, narrows the idea, breaks it into smaller increments, and separates must-have from luxury. The goal is to stop six-month projects from entering the roadmap without boundaries.
Before something competes for roadmap space, it should survive four questions. Is it valuable? Is it usable? Is it feasible? Is it viable for the business? If those questions are still open, the item is not ready for prioritization. It is still in a discovery period.
Sales requests are where roadmap honesty usually breaks first. The fix is not to ignore them, but to force them into the same economic shape as everything else: what deal, what revenue, what deadline, what broader market pattern, and what exactly gets displaced if we take it on?
If something enters, something moves. Most roadmap dishonesty starts when teams discuss additions without naming displacement. A new customer request appears. Leadership wants a visible bet. Sales needs something for a deal. Everyone talks about importance. Almost nobody says what gets pushed out. That is the real decision. They have only added pressure and left the team to absorb the contradiction later.
Estimates matter here, but not because they make the future knowable. Their real value is that they introduce friction. They force EMs/PMs to stop pretending everything fits. They give work a boundary. They make smaller versions possible. They turn vague enthusiasm into something discussable. That is why time-boxing matters too. Once the team has a bounded appetite for the work, trade-offs become real.
Without that friction, the conversation stays political. With it, people finally have to answer the real question: how much of our limited capacity is this problem worth? A month, a quarter, or a year.
Once the work is clear, our next question is not “what do we like most?” It is “where will the time actually go?” The saw could only run one job at a time, and some of its time was lost to oiling, adjustments, blade changes, and repairs. Software teams hide that constraint better, but they do not escape it.
If capacity stays invisible, it still gets allocated, usually by the loudest stakeholder, the nearest escalation, or the latest surprise. That is why feature lists create false confidence. A list can look coherent long after hidden promises, side work, and unplanned interrupts have already broken the allocation. The real question is simpler: how much engineering, product, and design time are we willing to fund here, and what will not happen because of it?
You do not need a perfect formula, but you do need named buckets. Customer-facing work. Reliability. Engineering health. Platform or enablement work. Partner or compliance obligations. Interrupt budget. The point is not precision here. It is to make the investment mix visible enough that people can see the trade-offs they are asking for.
Visible buckets expose the zero-sum nature of the plan. If one bucket grows, another shrinks. Once the mix is visible, the argument becomes more honest. People stop pretending every category can expand at the same time.
Note that buying a vendor solution does not remove roadmap cost. It changes its shape. Integration, version drift, and dependency management still consume capacity.
Visible investment buckets
Technical debt belongs inside normal delivery, but larger engineering health work still needs explicit room. Otherwise the organization is not choosing against it consciously. It is neglecting it by default.
Technical debt is too broad to budget well. Some work is hygiene, the regular maintenance required to keep the machine healthy. Some is leverage, investment that makes future delivery faster. Some is time-bomb work, deferred failure that will eventually stop the roadmap altogether.
A roadmap that assumes perfect stability is not a roadmap. It is a wish. Broken mainline, urgent upgrades, incident follow-up, forced migrations, partner changes, and dependency fallout are part of the operating environment. They should not arrive every quarter as if they were acts of God. They should be assumed and budgeted up front.
They allocate one hundred percent of visible capacity to planned work, then act surprised when operations consume the missing share. Reserve capacity for interrupts before the quarter begins including oncall, postmortems, and operational side quests.
What gets a protected slice of capacity is what the organization truly values. If reliability is always described as critical but never appears visibly in the mix, the message is already clear. It reveals what will still be defended when pressure arrives.
Teams should be able to see where leadership is putting real money, and where the company is willing to bet the house. If those strategic bets are serious, they should show up as protected capacity. Or, put differently, if they are truly serious, the company should hire for that initiative and provide the necessary headcount.
When people talk about moving work around, they often speak as if capacity were liquid. It is not. Capacity does not slide from one priority to another without loss. Every shift has a restart cost: context reload, broken sequencing, half-finished work, re-briefing, new coordination, and delayed follow-through on the work that was already in motion.
That is why “just switch to this” is usually more expensive than it sounds. Work already underway becomes slower, messier, and harder to finish well. In practice, many roadmap changes do not only fund the new item. They also waste part of the capacity that had already been invested elsewhere.
In carpentry, timber had to be moved. Measurements had to be rechecked. Tools had to be adjusted. Software has its own version of the same friction. The more often capacity is reallocated midstream, the less of it remains for actual delivery.
Just like the carpenter’s saw, capacity is a physical limit, not a theoretical backdrop. Work has to arrive in a shape that can be sized, discussed, and displaced. Team time has to be allocated deliberately, not discovered afterwards through escalation and drift.
That is the difference between a plan and a wish. A real plan says what will happen, what will not, and why. Anything less is paperwork pretending to be planning.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。