← Back to blog
·6 min read

Why PM tools fail (and what we think is different)

Here's a stat that should embarrass every PM tool on the market: according to research from Wellingtone and others, roughly 77% of high-performing teams don't use any project management software. Not because they can't afford it — because it makes their work harder.

We've been thinking about this a lot. Not as a market opportunity (though it is one), but as a design failure. How did an entire category of software manage to be so widely available, so heavily funded, and so consistently rejected?

The setup tax

Every PM tool starts with the same ritual: create a workspace, invite your team, configure your workflow, customize your fields, set up your views. Before anyone does a minute of real work, the tool demands hours of administrative labor.

This is backwards. The tool should earn its place by making work easier from minute one. Instead, it front-loads a setup cost that most teams never recoup. Sprint 1 goes great — everyone's excited, the board is fresh. By sprint 3, half the team has stopped updating their cards.

Boards die because updating them is work

The fundamental problem with boards is that they require manual maintenance. Every card move, every status update, every comment — it's all work about work. The more diligent your team is about updating the board, the less time they spend on the actual project.

This creates a perverse incentive: the people doing the most work are the least likely to keep the board updated, because they're busy doing the most work. The board becomes a fiction — a hopeful representation of reality rather than an accurate one.

The notification problem

PM tools try to keep everyone informed through notifications. But notifications are interruptions. Every @mention, every status change, every comment reply pulls someone out of their flow. Teams end up muting notifications, which defeats the purpose, or drowning in them, which defeats the purpose differently.

What teams actually need isn't to be notified of every change — it's to understand the state of the project without having to process dozens of individual updates. That's a synthesis problem, not a notification problem.

Status updates are a management tax

"Can everyone update their tasks before standup?" This sentence is uttered thousands of times a day across companies worldwide. It's a confession that the tool has failed. If the tool worked, the status would already be visible.

People don't resist writing status updates because they're lazy. They resist because writing a status update is a context switch. You have to stop thinking about the problem you're solving, open the PM tool, find your task, and translate your current state into whatever format the tool expects. Then do it again tomorrow.

What we think might be different

We don't have the full answer yet. But we have a hypothesis: the interface is wrong. Boards are a visualization tool, not an input tool. They're great for seeing the state of a project at a glance. They're terrible for capturing the state of a project in the first place.

What if the primary interface wasn't a board at all, but a conversation? You tell AI what needs to happen. AI structures it. The board exists, but it's an output — a live dashboard of what the conversation has produced — not the thing you spend your time interacting with.

What if status updates were one tap instead of one paragraph? What if the tool watched your work and narrated progress back to the people who need to know, instead of demanding that everyone write reports for each other?

We're building something based on these ideas. It might work, it might not. But we're convinced that the current model — make the board, fill the board, maintain the board — is fundamentally broken. The 77% who've walked away from PM tools aren't wrong. The tools are.