There's a pattern that plays out at almost every company that adopts a new project management tool. Week one: enthusiasm, careful setup, everyone dutifully filling in their cards. Week four: a few people are still updating things. Week eight: the board is a graveyard. The real work moved back to Slack. The spreadsheet came out of retirement. And the PM tool quietly became another line item no one wants to cancel because canceling it would mean admitting the experiment failed.
This is the dirty secret of the PM software industry. Adoption is the pitch. Abandonment is the reality. Teams don't stop using these tools because they're lazy or undisciplined — they stop because the tools make work harder, not easier. The tool becomes the job, and at some point the team decides they'd rather just do the actual job.
The onboarding tax
Every PM tool comes with a model. Jira has epics, stories, and sub-tasks. Asana has goals, portfolios, and projects. Linear has cycles and triages. Notion has databases and views. ClickUp has everything, layered on everything else. Before your team can track a single real task, someone has to understand the tool's conceptual model well enough to set it up correctly.
That person is usually a team lead or an engineering manager — someone already overextended. They spend a weekend building out the workspace, configuring the workflows, writing the internal guide on how to use it. They do it with good intentions. What they've actually done is create a knowledge dependency that will silently drain the team for months.
Because the onboarding tax isn't a one-time payment. It compounds. Every new hire needs onboarding to the tool. Every contractor who joins for a sprint needs a walkthrough. When the team lead leaves, their mental model of how the workspace is structured goes with them, and whoever inherits it spends three weeks just trying to understand why there are eleven different custom fields on the task template.
The deeper problem is that the tool's model is rarely the team's model. Teams think in terms of problems to solve and people to solve them. They don't naturally think in sprints or swimlanes. Forcing a team to adopt a tool's vocabulary is a tax on every conversation, every standup, every planning session. Someone always has to translate.
The best tools don't require learning a model. They adapt to how you think. The worst ones require you to think like them before you can do anything useful. Most PM tools are the worst kind.
The update burden
PM tools are supposed to reduce overhead. In practice, they create a second job. The first job is doing the work. The second job is telling the tool you did the work. For a lot of teams, the second job starts to feel more demanding than the first.
Think about what a proper status update actually requires. You stop what you're doing. You switch context to the PM tool. You find your task — which might mean navigating through several layers of hierarchy. You update the status, add a comment, maybe adjust the estimated completion date. You switch back to work. You've now spent five minutes on reporting that could have gone toward the thing you were reporting on. Multiply that by every team member, every day.
The people hit hardest by the update burden are the people doing the most work. The engineer deep in a tricky debugging session isn't going to stop to update a Jira ticket. The designer iterating quickly on feedback isn't going to pause to log every design decision. The people who are most productive are also the ones least likely to maintain the board, because maintaining the board competes with being productive.
So the board drifts. It becomes an approximation of reality, then a rough sketch, then a fiction. The project lead starts asking people to update their tasks before standup — which is an admission that the tool hasn't worked, delivered as a management request, creating resentment. "Update your tasks" becomes code for "the system we chose isn't capturing reality, so please manually fix it."
When a tool creates more work than it saves, rational people stop using it. That's not failure of discipline. That's good judgment.
The information asymmetry
Here's who wants the PM tool to exist: project managers, team leads, and executives. They need visibility. They need to know what's happening, what's at risk, what's on track. The board gives them a place to look. For them, the tool has clear value.
Here's who pays the price for that visibility: the individual contributors actually doing the work. Every status update, every ticket comment, every card move is labor performed primarily for the benefit of the people above them in the org chart. The ICs don't need the board to do their work — they know what they're working on. They maintain the board so their manager knows too.
This asymmetry is why PM tool adoption collapses from the bottom up. Leads and managers love the tool — they're getting value without doing much of the maintenance. ICs quietly check out — they're doing the maintenance without getting proportional value. By the time leadership notices that the board isn't being updated, they've lost the trust of the people they need to buy in.
The classic response is to make status updates mandatory. Add it to the standup ritual. Put it in the team agreement. Send reminders. This works — briefly — and then the updates become perfunctory. Tasks get moved to In Progress and sit there. Comments become one-liners. The board is maintained in the letter, not the spirit.
Accountability without friction works. Accountability enforced on top of friction just creates resentment. The friction is the problem. Making it mandatory doesn't remove the friction — it just adds a social cost to not tolerating it.
The only way to fix information asymmetry in PM tools is to stop making ICs do the reporting and start making the tool do it for them. Easier said than built — but that's the direction the problem points.
What conversation-first changes
The reason PM tools fail isn't the features. It's the interface model. They ask you to interact with structure — boards, tickets, fields, hierarchies — when what comes naturally to humans is interaction through language. We describe what's happening. We say what needs to change. We talk about what's blocked. We don't fill out forms about it.
A conversation-first tool flips the primary interface from structure to language. Instead of clicking into a ticket and updating a status dropdown, you say "the auth work is blocked waiting on the API keys." Instead of creating a new card and filling in the fields, you say "we need to add error handling to the payment flow before launch." The tool listens, understands, and handles the structure on your behalf.
The onboarding tax disappears because there's nothing to learn. If you can describe what you're working on, you can use the tool. The model you bring is your own mental model of the project — which you already have, because it's your project. The tool adapts to that model, not the other way around.
The update burden shrinks because a conversation is faster than navigating a UI. Telling an AI what's happening takes seconds. It also happens in the same interface where you're already communicating — you're not context-switching to a separate tool, you're adding to an ongoing thread. The update happens because it was easy, not because someone enforced it.
The information asymmetry shifts because the AI can synthesize across what everyone has said and surface summaries to leads without requiring ICs to write status reports. The IC says what's happening in plain language. The AI translates that into the structured visibility the lead needs. Each side of the relationship gets what it needs without either side carrying the full cost.
This isn't a minor UX improvement. It's a different model of how project tracking works — one that starts from how people actually communicate rather than from the structure that makes reporting convenient.
The board is the output, not the input
Boards are genuinely useful. A well-maintained board gives you instant visibility into project state. You can see what's in flight, what's done, what's blocked. You can spot bottlenecks. You can understand workload distribution. That value is real.
The mistake is treating the board as both input and output — making people interact with the board to do their work and to report on their work. That collapses two different jobs into one interface that doesn't handle either well. Boards are great at displaying state. They're miserable at capturing it.
The right model is to separate the two. Conversation is the input: fast, natural, low friction, happens where work is already discussed. The board is the output: a live representation of what the conversation has produced, updated automatically as new information comes in. No one is responsible for maintaining the board. The board just reflects the current state of everything that's been said.
When a task gets mentioned and assigned in conversation, it appears on the board. When someone says it's done, the board moves it. When something is blocked, the board shows the block. The board is always accurate because it's generated, not maintained. You can't forget to update it — there's nothing to update. You just keep talking about the work.
This also means the board becomes something people actually want to look at. When the board is manually maintained, you never know if it's accurate. You have to check before you can trust it. When the board is generated from the conversation, it's as accurate as the conversation itself — which is the most accurate source you have.
The implications reach further than project tracking. When the board is the output of a conversation, you can replay the conversation to understand why a task exists, what changed, and who made which decisions. The board has a history that isn't just a changelog of field edits — it's a record of intent. That's a different kind of institutional memory, and a more useful one.
The best tool is the one your team actually uses
There's a version of this problem that never gets solved because companies keep asking the wrong question. The question they ask is: "What PM tool has the features we need?" The question they should ask is: "What tool will our team still be using in six months?"
Features don't matter if adoption collapses. A tool with half the features that the whole team uses daily beats a tool with every feature that half the team ignores. The ROI on perfect-but-abandoned software is zero. The ROI on good-and-actually-used is compounding — every piece of context that gets captured is available to everyone, forever.
Adoption comes from removing friction, not from adding capability. The teams that sustain PM tool usage long-term are the ones who found tools that fit naturally into how they already work — not tools that required them to change how they work to accommodate the tool's preferences.
Conversation-first is a bet on that principle. The hypothesis is simple: if the interface feels like talking instead of filing, people will use it. If it generates structure from their natural language instead of demanding they produce structure themselves, the board will stay accurate without anyone managing it. If leads get visibility without taxing ICs, both sides win.
We built Lova around this hypothesis. Chat is the primary interface. The board builds itself. Status comes from what your team says, not from forms they fill out. If your team has been through the PM tool cycle — excitement, gradual neglect, quiet abandonment — it's worth trying something that starts from a different premise. See how it works.