Why Velocy starts with goals, not tasks.
Every project management tool starts with tasks. You open it, you create a task, you assign it, you track it. That pattern is so universal that it feels like a law of the category rather than a design decision. We think it is a design decision, and we think it is the wrong one.
Tasks are not the problem. They are a necessary part of how work gets done. The problem is treating them as the starting point. When a task is the atomic unit of your planning tool, the tool becomes very good at tracking tasks and not particularly good at tracking whether those tasks are producing anything. Teams end up optimizing for task completion because that is what the tool measures. The goals are somewhere in the background, referenced in a doc or a slide deck, hoping the tasks eventually add up to something.
They often do not. The tasks are real, the effort is real, but the connection between the work and the outcome is assumed rather than designed. That assumption is where time disappears.
We built Velocy around goals because that is where planning should start. You define the outcome first. The AI generates the tasks from that definition, scoped specifically to what the outcome requires. Nothing gets added that does not serve the goal. Nothing gets scheduled that cannot be traced to the outcome. The task list is a byproduct of the goal, not the other way around.
The practical effect is that teams stop doing work that feels productive but is not pointed at anything. They stop carrying planning overhead that exists to maintain a backlog nobody fully trusts. And they start seeing goals close on the timeline they set rather than two cycles later with no clear explanation for why it took so long.
That is the product. The insight behind it is simple: if you start with the outcome, everything else follows. If you start with the task, the outcome is just a hope.