Most project tools are optimized for planning — not finishing work

If you look at most project tools, this is what they optimize for:
Structure. Visibility. Planning, and to be fair — they do that really well.

Boards, timelines, sprints, estimates… everything is there to help you organize work, and from the outside it feels structured and under control.

But finishing work still feels harder than it should. After years of building software — both solo and in teams — I’ve started to feel that something is off.

Not intentionally. But by default.

The gap between planning and finishing

I’ve used Scrum, Kanban boards, Jira, Basecamp — the usual stack. They all try to improve structure in different ways: clearer planning, better prioritization, more visibility into what’s going on.

And to be fair, they do that well.

But finishing work rarely depends on how well it was planned. In practice, it depends much more on things that are harder to model in a tool — like having clear ownership, being able to focus without constant interruptions, and not reshuffling priorities every few days.

Most tools help you decide what to do.
They don’t really help you follow through.

Where things start to break

Over time, I noticed a pattern. The more features a tool adds to help teams plan better, the easier it becomes to avoid actually finishing things.

There’s always something more to do before doing the work:

another refinement
another estimation
another discussion

None of these are bad on their own. But together, they create a system where work is constantly being prepared instead of completed.

And ownership often becomes abstract. It’s not one person responsible — it’s “the team”. Which works in theory, but in practice it usually means no one feels fully accountable for pushing something across the finish line.

A small shift in thinking

At some point, I stopped asking:
“How do we plan better?”

and started asking:
“What would a system look like if it was built around finishing work?”

That question removes a surprising amount of things you normally take for granted. It shifts focus away from coordination and towards execution.

Instead of optimizing for flexibility, you start thinking about clarity and commitment.

What I’m building now

I’m currently building a project tool called Grunnaro, based on that idea.

The goal isn’t to compete feature-for-feature with existing tools, but to explore a slightly different foundation — where finishing work is the primary concern.

Some of the core principles I’m working with:

Every item has a single owner
Work is ordered — not estimation-driven
Once something starts, it’s protected from constant reshuffling
Ideas and execution are clearly separated
No recurring rituals are required to keep things moving

It’s intentionally a bit opinionated. Not because that’s always right, but because trying to support every workflow usually leads back to the same complexity I’m trying to avoid.

What I’ve learned so far

One thing that’s become very clear while building this is how easy it is to add features — and how hard it is to say no.

Most features you consider adding make sense in isolation. They solve a real problem, or improve something slightly. But over time, those small additions stack up and change the nature of the system.

You don’t notice it happening.

And suddenly you have a tool that does everything… except make it easier to finish work.

Saying no is less about discipline and more about having a clear idea of what the system is supposed to protect.

Where it is right now

Grunnaro is currently in public beta, but still very early.

Right now I’m mostly using it myself and slowly refining the core flows. The focus is less on adding new features and more on making sure the existing ones actually support the idea of finishing work.

Before pushing it wider, I want to be confident that:

the core workflow feels natural
ownership is always clear
the system doesn’t encourage unnecessary planning

It’s tempting to push for users early, but I’d rather have something that holds up when people actually try to use it for real work.

Still figuring it out

I don’t think there’s a perfect system.

Different teams need different things, and a lot of existing tools are successful for a reason. But I do think there’s space for something that leans more towards execution and less towards coordination.

That’s what I’m trying to explore.

If you’re building solo or working in a small team and this resonates,
I’d genuinely like to hear how you work today and what feels broken:

https://www.grunna.com/grunnaro/