Kill the Hidden Buffer

Dr Bart Jaworski published "The Dark Sides of Product Management Nobody Talks About" today, eight uncomfortable truths about the job. One sentence in the first of them is advice I would put on the Kill List.

The short version

Dr Bart Jaworski writes that nothing in product management is ever on time, and that the practical solution is to plan for roughly 70 percent of the team's theoretical capacity and hold the remaining schedule buffer without advertising its existence. Keep the 70 percent. Kill the silence. A hidden buffer works once per stakeholder: the first time it is found, every later date gets discounted by the listener. It also models, upward, the exact behavior his seventh truth complains about downward, people holding information until it is polished. And it does not cover the slip that hurts most, the one nobody told the PM about. The replacement is a published buffer: measure ETA accuracy (on-time percentage and average variance in days, which my Roadmap Progress Agent reports every weekday), attach the variance to every date in the open, and let the buffer be a line with a burn rate.

What Bart wrote

His essay is a list of eight realities: nothing is ever on time, the difficulties keep piling up, politics shapes the roadmap, the PM is the scapegoat, you can do everything right and still fail, the accumulation takes a toll, you are often the last to know, and the role is lonely. It is written for people considering the job and people finding it harder than the description said.

The first one is the one I want. No framework eliminates schedule risk, he writes, because software development is investigative work and the estimate was always a guess. Then the fix:

Plan for roughly 70 percent of the team's theoretical capacity and hold the remaining buffer without advertising its existence. Not to be deceptive, he says, but because the buffer will be consumed, reliably, by what you could not predict. A team at 70 percent of nominal capacity that delivers consistently is more valuable and more trusted than one that commits to 100 and delivers 75.

His key principle for that section is that the question is how to build enough buffer that the slip does not become a crisis, and how to communicate about timing in a way that preserves trust when plans change.

I agree with the diagnosis and with the 70. The four words I would strike are "without advertising its existence."

A hidden buffer works once

Here is what happens to a buffer nobody is supposed to know about.

It gets found. A team lands something early twice in a row. A finance partner lines up headcount against commitments and sees the gap. An engineer mentions in a hallway that the date had room in it. Any of these is enough.

From that moment the stakeholder does their own arithmetic. Every date you give is heard as the date minus whatever they have decided your padding is. Now there are two hidden numbers in the conversation, yours and theirs, and neither of you can see the other's. You pad a little more to compensate. They discount a little more. The schedule that leaves the room has stopped describing the work.

That is the opposite of the trust his key principle is after. The 70 percent team is more trusted because it delivers what it said. A team whose padding has been discovered is trusted less than the team that committed to 100 and missed, because the miss was at least honest.

It is the behavior he warns about, pointed up

His seventh truth is that the PM is often the last to know what is actually happening. The engineer who found an architectural problem three days ago and is quietly trying to fix it before saying anything. The designer sitting on research that contradicts the direction. His answer is relational: make it clear through consistent behavior that you want difficult things early, not polished things late.

A hidden buffer is a PM holding a difficult thing (we can reliably deliver about 70 percent of what the plan says) until it never has to be said. The team watches that. You cannot ask the people below you for early, unpolished truth while showing the people above you a polished date with the truth removed.

I do not think that is his intent. It is what the advice does when it is followed.

The slip no buffer covers

Take a schedule failure that was not an overrun.

At a company I advised, a feature was scheduled to launch mid-quarter. The PM tracked it. The customer knew about it. The CEO had mentioned it in a board update. Engineering had de-prioritized it in favor of technical debt, and the PM found out a week before launch. Then came the hard choice between slipping the customer feature and cutting the debt work, with the customer upset either way.

Thirty percent of buffer does nothing for a feature with zero commits. What would have helped is a daily cross-check of the roadmap against actual engineering activity, which would have shown the divergence a month earlier.

That is the reason I built the agent in Build Your Roadmap Progress Agent. Every weekday at 9 AM it reads the roadmap status, the engineering tickets, the commits, and the PM updates, and flags anything marked "in progress" with no commits in five days. It also reports ETA accuracy: how many recent items landed on time or early, how many ran late and by how much, the average variance in days, and the velocity trend over four weeks.

What replaces it

Publish the buffer. Three parts.

Say the capacity number once, out loud. "We plan at 70 percent of theoretical capacity, because the other 30 gets consumed by things we cannot predict, and here is the last quarter showing that it did." That is one uncomfortable meeting. The hidden version is an uncomfortable meeting every time a date moves.

Put the measured variance on every date. If the last 30 days ran two days late on average, the date goes out with those two days on it, labeled as such, and with the trend beside it. A variance that is shrinking is the best argument a team has for more trust. A variance that is growing is a conversation you want to have before the stakeholder starts it.

Report the burn. When the buffer is consumed, say what consumed it: the sick week, the vendor API, the dependency that slipped. Bart's own list of what eats the schedule is a good template for the line items. A buffer with a ledger is a plan. A buffer without one is padding.

The deeper reason this matters now is in The Cost of Being Wrong Is the Only Number That Matters Now. When shipping took two quarters, the slowness was itself a buffer, and nobody had to account for it. Building is fast now, the gap between a commitment and its consequence is short, and the padding that used to hide inside a long cycle is visible to anyone who looks. Write the decision down while you are at it. The Decision Log Template: Train Judgment Like a Muscle is where the "why did the date move" entry goes, and Bart is right that the record is the only protection when memory gets selective.

This sits in Product Leadership, where the argument is that coordination work calibrated to the old build cost has to be named and retired out loud. The secret buffer is a small piece of that: a private translation layer between what the team can do and what the company is told. Retire it, keep the 70 percent, and let the number be seen.

Related answer: Should a product manager hide schedule buffer?

Sources: The Dark Sides of Product Management Nobody Talks About, Dr Bart Jaworski, Dr Bart's Newsletter, October 2, 2026. Build Your Roadmap Progress Agent, falkster.com, February 8, 2026.