Your PM Tool Shouldn't Be a Project | GritShip Blog | GritShip
GritShipProduct PhilosophyProject Management
Your PM Tool Shouldn't Be a Project
Somewhere along the way, project management tools became projects themselves. You configure them. You maintain them. You hold meetings about how to use them. This is a manifesto against all of that.
By Imtiaz··10 min read
You opened Jira to move a card. Forty minutes later, you'd configured a custom workflow transition that required a field that only appeared when another field was set to a specific value. You didn't ship anything. You didn't plan anything. You managed your management tool.
This happens every day, in every company, at every scale. And we've normalized it.
We hold meetings about how to use our project management software. We assign someone to maintain the board. We create documentation for our documentation tool. We build workflows to manage workflows. We hire Jira administrators — people whose entire job is keeping a PM tool running.
At some point, the tool stopped serving the work. The work started serving the tool.
The moment a tool becomes a project
A tool becomes a project the instant it requires maintenance. Not usage. Maintenance. There's a difference.
Using a tool: Open it. Create a task. Move a card. Close it.
Maintaining a tool: Configure custom fields. Build automation rules. Fix broken workflows. Train new team members. Migrate data between views. Attend a webinar about a feature update.
ℹ️ The maintenance test
Ask yourself: does your PM tool require regular upkeep that isn't "doing your work"? If yes, it has become a project — one that ships nothing, serves no customer, and produces no value except keeping itself alive.
Most PM tools fail the maintenance test within weeks. The moment someone on your team says "I'll fix the board this weekend," the tool has crossed the line.
How we got here
This wasn't always the case. The original Kanban board was a physical wall with sticky notes. You wrote a task. You stuck it on the wall. You moved it when it was done. Setup time: zero. Maintenance: occasionally resticking a note that fell off.
Then software happened.
The first digital PM tools replicated that simplicity. Trello launched in 2011 as a digital board with cards and columns. It worked because it did almost nothing. You could learn it in 90 seconds.
Tired of bloated PM tools?
GritShip is project management for developers who'd rather ship than configure.
Then the feature race started. Every tool competed on feature count. Enterprise buyers demanded longer checklists. Product teams added Gantt charts, time tracking, resource leveling, portfolio management, OKR tracking, docs, whiteboards, and AI everything.
Pendo's Feature Adoption Report analyzed 615 software products and found that 80% of features are rarely or never used. Just 12% of features generate 80% of daily usage. The rest is dead weight that everyone pays for and nobody asked for.
The irony? Project management tools — products designed to eliminate waste — became the most wasteful products their users touch.
The configuration trap
The most dangerous feature in any PM tool isn't a feature at all. It's customizability.
"Make it work however you want" sounds like freedom. In practice, it's a trapdoor. Because "however you want" means you have to decide. And deciding means debating. And debating means meetings.
40 min
To move a card
When custom workflows collide
80%
Features unused
Pendo, across 615 products
3 hrs/week
Feeding the tool
Manual sprint metric updates — Zenhub
Here's what configuration looks like in practice:
"Should we use labels or custom fields for priority?"
"What's the difference between a Story and a Task in our setup?"
"Why does this workflow transition require approving a field I've never seen?"
"Who changed the board layout and where did my column go?"
None of these questions produce value. They produce process overhead. And process overhead is the enemy of shipping.
Zenhub's research found that engineering teams using general-purpose PM tools spend up to 3 hours per week manually updating sprint metrics. Three hours of a developer's week spent on tool maintenance — not coding, not reviewing, not designing. Feeding the machine.
What your PM tool should actually do
A project management tool has one job: make the current state of work visible so you can decide what to do next.
That's it. Not manage resources. Not generate Gantt charts. Not track OKRs. Not replace your docs tool, your chat tool, your time tracking tool, and your whiteboard.
💡 The five-minute test
A PM tool should be productive within 5 minutes of signup. No onboarding webinar. No admin configuration. No "getting started" checklist with 14 steps. If the tool needs a tutorial, the tool is too complex.
The best tools are opinionated. They make decisions so you don't have to.
One way to view tasks. Maybe two. Not seventeen.
Built-in priorities. P1 through P4. Not "create your own priority system using custom fields and color-coded labels."
One level of nesting. Tasks and subtasks. Not tasks > subtasks > sub-subtasks > epics > stories > themes > initiatives > portfolios > programs.
Keyboard shortcuts for everything. Because reaching for the mouse to create a task is already too slow.
Opinions are features. Every decision the tool makes for you is a decision you don't waste time on.
The tools that got it backwards
We've normalized absurdity. Consider these real patterns:
Jira has 14+ issue types out of the box. Story. Bug. Task. Subtask. Epic. Initiative. Change. Incident. Problem. Service request. The list goes on. A solo developer shipping a SaaS product needs exactly one: a task.
ClickUp offers Docs, Whiteboards, Mind Maps, Goals, Dashboards, Time Tracking, Automations, Forms, and an AI assistant — on top of the actual task management. One Trustpilot reviewer noted it's "aptly named because you will be clicking all day." A Proofhub analysis found that ClickUp's depth of features "can lead to mental overload."
Notion gives you a blank page and says "build whatever you want." Some people build beautiful productivity systems. Most people, as one review noted, "stare at emptiness for 20 minutes before giving up and going back to their simple to-do list app."
Monday.com's flexibility means nothing works out of the box. As Proofhub documented, "those gorgeous demo boards someone spent hours building, testing automations, and configuring integrations." Hours. On the board. Not on the product.
The Industry Pattern
What works
●More features = more enterprise deals
●Customization satisfies diverse use cases
●All-in-one reduces tool count on paper
●Enterprise compliance requirements met
What doesn't
●Individual developers pay the complexity tax
●Onboarding time measured in hours or days
●Performance degrades as workspaces grow
●Dedicated admin often required
●The tool becomes another project to manage
The anti-bloat manifesto
We built GritShip on a single belief: a project management tool should take less time to use than the work it tracks.
That belief led to a set of constraints:
Every interaction under 200ms. Not a target. A constraint. If a feature can't meet this budget, it doesn't ship. Your board loads instantly because we chose to keep it light, not because we optimized our way out of complexity.
No features that need configuration. Priorities are built in: P1, P2, P3, P4. Not "create a custom field." Columns exist. Drag cards between them. No workflow transitions, no approval gates, no conditional visibility rules.
No features that generate maintenance. No custom automations to debug when they break. No workflow templates to keep updated. No admin role. The tool runs itself because there's nothing to administer.
No features designed for someone else. GritShip isn't for a team of 200 with three project managers. It's for indie hackers, freelancers, and small teams who want to track work and get back to building. Every feature earns its place by serving that audience — not an imaginary enterprise buyer.
Deliberate exclusions. No Gantt charts. No time tracking. No resource leveling. No whiteboards. No AI summaries. Not because we can't build them. Because building them would make the tool slower, heavier, and harder to use for the people it's actually for.
The subtraction principle
The most underrated product decision is removing something.
Pendo's data proves this. If 80% of features are rarely used, the right move isn't to build more. It's to cut the 80% and make the remaining 20% exceptional.
💬 The subtraction principle
The best tools don't do the most things. They do the right things so fast and so well that you forget you're using a tool at all.
Apple understood this with the original iPhone. Google understood it with the search homepage. The best productivity tools — the ones that actually make you productive — share this DNA. They're fast because they're focused. They're focused because someone had the discipline to say no.
The hardest feature to ship is the one you deliberately don't build. Every "no" is a bet that the tool will be better without it. Every "no" means a potential customer who wanted that feature and walked away. But it also means every remaining user gets a faster, simpler, more focused experience.
That's the tradeoff. We take it every time.
What happens when you switch
Something strange happens when developers move from a feature-heavy tool to a focused one. The first reaction is panic: "Where's the Gantt chart? Where's the automation builder? Where's the custom field configurator?"
Then, about a day in, the panic fades. Because they realize they never used those things. They used a board, cards, priorities, and a search function. Everything else was furniture they walked past every day without sitting in.
The second reaction is speed. Creating a task takes one keystroke. Moving a card is instant. Searching is instant. The tool stops being a destination and starts being a reflex — something you do without thinking, like checking your rearview mirror.
The third reaction, weeks later, is the one that matters: they stop thinking about their PM tool entirely. It disappears into the background. The work moves to the foreground. That's what a tool is supposed to do.
This is a line in the sand
If you're a developer, a freelancer, or part of a small team, you have a choice.
You can keep spending hours configuring, maintaining, and working around a tool that was designed for a company ten times your size. You can keep attending the meeting about the tool. You can keep being the person who "fixes the board."
Or you can use a tool that does less — and gives you back the time to do more.
Your PM tool shouldn't be a project. It should be invisible.
Frequently asked questions
Why do PM tools keep getting more complex?
Enterprise buyers compare feature checklists. More features win more enterprise deals, so PM tools add capabilities even when most users don't need them. This creates a cycle where individual developers pay the complexity tax for features designed to win procurement reviews.
How much time do developers waste on PM tool maintenance?
Research from Zenhub found that engineering teams spend up to 3 hours per week manually updating sprint metrics in general-purpose PM tools. That's nearly a full half-day per week feeding the tool instead of writing code.
What makes a PM tool 'focused' vs 'bloated'?
A focused tool has opinionated defaults, hard performance budgets, and deliberate feature exclusions. It works within 5 minutes of signup. A bloated tool requires configuration, training, and ongoing maintenance — it has become a project itself.
Is it possible to manage real projects with a simple tool?
Yes. Small teams (2-10 people) rarely need Gantt charts, resource leveling, or custom workflow builders. A board, priorities, assignments, and real-time sync cover 95% of what small teams actually do day to day.
What should I look for in a PM tool for a small team?
Three things: speed (every interaction under 200ms), simplicity (productive within 5 minutes), and focus (built for your team size, not a Fortune 500 company). If the tool needs a training session, it's too complex.