I have used a lot of project-management software. The genuinely good kind, the wildly overhyped kind, and the kind that a company bought for everyone and quietly abandoned eight months later. Over thirty years you see enough of these come and go that you stop getting excited about features and start paying attention to something else: whether the tool actually disappears into the work, or whether managing the tool becomes a second job.
That distinction is the whole thing. Almost everything I believe about building software for project managers comes from it.
The tool is not the work
The work of a project manager is mostly invisible. It is anticipating the thing that has not gone wrong yet. It is the quiet conversation that keeps two teams from colliding. It is knowing which status to chase today and which to let ride. None of that lives in a tool. The tool exists to hold the facts so your head is free for the judgment.
The moment a tool demands attention for its own sake (a workflow to configure, a field to maintain, a ceremony to perform) it has inverted the relationship. You are now serving the software. I have watched whole teams spend more energy keeping the system tidy than doing the work the system was supposed to track.
Every team drowns in the same three things
Tools change. The problems do not. Strip away thirty years of trends and the same three things sink projects:
- Nobody can see the timeline clearly. The plan lives in someone’s head, or in a chart so detailed it is unreadable, or in a deck that went stale the day it was made.
- The work in flight is a fog. What is actually moving right now, what is stuck, and who is waiting on whom is genuinely hard to see at a glance.
- What the team knows is scattered. Decisions, context, and the “why did we do it this way” are spread across chats, docs, and inboxes, and the answer is always somewhere you are not.
If a tool does not make at least one of those meaningfully better, it does not matter how clever it is.
Why all-in-one platforms fail PMs
The industry’s answer to those three problems has been to build one enormous platform that promises to do everything: planning, docs, chat, automation, reporting, the lot. On paper it sounds efficient. In practice it tends to be mediocre at all of it, expensive, slow, and so sprawling that no two teams use it the same way.
Worse, it makes your work hostage to one vendor’s roadmap and one vendor’s servers. When the thing is down, you are down. When they change the pricing, you pay it. When they deprecate the feature your process depended on, you rebuild your process.
The alternative is not novel. It is the oldest idea in tools: do one thing well, and play nicely with the others. A focused app you understand completely beats a platform you use ten percent of.
What thirty years changes about how you build
When you have actually lived the job, you build differently. You stop adding features to win a comparison chart and start removing everything that does not earn its place. You assume the user is busy and a little stressed, because they are. You make the common action instant and the rare action possible, rather than giving every action equal weight.
You also get ruthless about respecting the user’s data and attention. Thirty years of watching tools come and go teaches you that the company behind the software might not be here in five years, but the user’s work has to be. That belief is why everything in the Akigo! suite is local-first and focused rather than cloud-bound and sprawling. It is a direct consequence of the lesson, not a marketing angle.
The test a tool has to pass
Here is the bar I hold our own apps to, the same bar I wish more software had cleared over the years. After a week of using it, do you think about the tool at all? If the answer is yes, something is wrong. The goal is for it to fade, for the timeline to just be there, for the board to just reflect reality, for the note to be captured before you have finished the thought.
That is what “experience amplified” means to me. Not more features. Less friction between you and the work you are actually good at. Thirty years did not teach me a clever trick. It taught me to get out of the way, and to build tools that do the same.