Picture this... It's Monday morning, and your Product Manager is in a panic. The development team finished their sprint work early, and now there are three days left with no tickets ready to go. The PM scrambles through the backlog, dusting off half-baked ideas and "nice-to-haves" that nobody really wants, desperate to find something, anything, to keep the developers busy.

Sound familiar?

This scene plays out in software organisations everywhere, driven by a pernicious assumption: that a Product Manager's primary job is to be a "Backlog Administrator," responsible for maintaining a steady stream of well-defined, shovel-ready tasks. That developers without tickets are wasted resources. That an empty sprint is a failure of product management.

This is wrong. Dangerously wrong.

This "feature factory" mindset optimises for busyness, not impact. And worse, it's not the disease: it's a symptom of a much deeper dysfunction in how we think about building software.

The Misdiagnosis: Why "Developer Idle Time" is the Wrong Metric

Let's be direct: a developer without a ticket to work on is not inherently a problem. What is a problem is our collective terror of that reality.

This fear drives what I call the "tyranny of the urgent": the compulsion to keep the development machine running at all costs. When we optimise for utilisation rather than outcomes, we inevitably start prioritising low-value work: cosmetic UI tweaks, speculative features that "might be nice someday," technical experiments that solve no real problem. We're building inventory, not value.

Here's the uncomfortable truth: It would literally be better to have your developers sit idle than to mask the real problem with busywork.

Why? Because if you're manufacturing work to fill capacity, you're hiding your actual bottleneck. This is straight from Eliyahu Goldratt's The Goal: a system is only as fast as its slowest part. If your developers are idle, they're not your constraint. Optimising a non-constraint doesn't improve system throughput: it just creates waste and obscures where the real work needs to happen.

The Real Bottlenecks: Clarity and Decomposition

In every high-performing product organisation I've seen, the constraint is never developer capacity. It's one of two things:

First: Strategic Clarity. Does your Product Leader have a clear, well-understood vision? Not a roadmap with twenty initiatives. Not a list of stakeholder requests. A vision. What is the single most important mountain we're trying to climb this quarter? If your PM can't articulate this with obsessive clarity, no amount of backlog grooming will save you.

Second: Complex Problem Decomposition. Can your senior engineers take that big, ambitious goal and break it down into coherent, manageable pieces of work? This is an engineering skill, not a product management skill. It requires deep technical judgment, an understanding of system architecture, and the ability to sequence work in a way that manages risk and maintains momentum.

When developers "don't know what to do," the failure is almost always in one of these two areas. The backlog is just where we dump the symptoms.

The High-Trust Model: Redefining the Roles

Here's what the correct division of labour looks like:

The Product Leader owns the "Why" and the "What." Their job is to set direction and articulate vision with relentless clarity. They are responsible for ensuring that everyone understands what success looks like and why it matters. They are not responsible for writing tickets.

The Engineering Team owns the "How." They are expert partners responsible for breaking down complex problems, managing delivery, and solving technical challenges. They decide what needs to be built, in what order, and how to build it. They are not code monkeys waiting to be fed tickets.

This model requires trust. It requires Product Leaders who are comfortable saying "I don't know exactly what the solution looks like, but here's the problem we need to solve" and Engineering Leaders who are comfortable with the responsibility that comes with that autonomy.

It also requires both sides to understand something fundamental about software development that leads us to a deeper issue.

Conclusion: From Busyness to Impact

Stop measuring success by backlog velocity. Stop panicking when developers have slack time. Stop optimising for utilisation.

Start measuring progress toward your strategic goal. Start treating idle time as information about where your real constraints are. Start empowering your Product Managers to be strategists who provide clarity, not backlog administrators who manufacture work.

Give your engineers the space to solve hard problems, even if it means they're not "busy" 100% of the time.

The feature factory is comfortable. It's measurable. It feels productive.

But it's not building what matters. And deep down, you know it.

---

This is Part 1 of a three-part series. In Part 2, we'll explore why thinking about software primarily through the UI is like looking at only the tip of the iceberg, and why forcing development to march in lockstep with a top-down product/UX process is another anti-pattern that masks lack of maturity.