Why your bottleneck usually isn't the tool

“We need better software” is the most common diagnosis for a business that’s slowing down, and it’s wrong more often than it’s right. Most bottlenecks aren’t tooling problems. They’re process problems wearing a tooling costume.

How to tell the difference

A tooling problem looks like this: the work is clear, everyone knows what to do, and the software genuinely can’t do it, hits a wall, a hard limitation. That’s rare.

A process problem looks like this: the work is unclear, ownership is ambiguous, or a decision keeps getting re-litigated at every handoff. Any tool bolted onto that mess just becomes a faster way to be disorganized.

Why the tooling diagnosis is so tempting

Buying a new tool feels like progress, it’s a concrete action with a receipt. Fixing a process feels vague and uncomfortable, it usually requires a conversation about who owns what, which is harder than a purchase order. The easier move gets chosen even when it’s not the right one.

The test

Before buying anything, ask: if three more people were added to this process today with no new software, would the bottleneck improve or stay exactly where it is? If it would stay, the problem isn’t capacity or tooling, it’s structure, and no tool fixes structure.

What to do instead

Map the actual steps (see the earlier post on whiteboarding a workflow), find the step where work consistently stalls, and ask why specifically, not generally, that step stalls. Usually it’s an unclear owner, an unnecessary approval, or a handoff with no defined trigger. Fix that specific thing before buying anything new.

The honest caveat

Sometimes the tool really is the problem, some tools are genuinely bad. But that’s the less common case, and it’s worth ruling out the cheaper, more uncomfortable fix first before spending on the more comfortable, more expensive one.