In 2019, a mid-sized SaaS company’s product team was, by most appearances, highly organized. They used a popular task manager, tagged everything meticulously, and had weekly review rituals that would make any productivity blogger proud. Their list had hundreds of items across color-coded projects. It was beautiful. Nothing was getting done.

Not literally nothing. Small tasks were being cleared constantly. But the large, ambiguous, high-value work, the kind that actually moved the product forward, kept sliding. It lived on the list, week after week, accruing due-date extensions like parking tickets. The team wasn’t lazy. They were busy. The system was failing them, and they didn’t know it yet.

The Setup: A System Built for Capture

The team’s task manager was Asana (a common choice, and a reasonable one). Asana is genuinely good at what it’s designed to do: capture work, assign it, track it across a team, and show you what’s technically complete. The product is optimized for throughput and visibility. Add a task, check it off, move on. The dopamine loop is real and intentional.

The problem is that this design philosophy makes a quiet assumption: that tasks are roughly equivalent units of work. Write a changelog entry and redesign the onboarding flow both get a checkbox. The system treats them identically. When you’re deciding what to work on, the checkbox for the changelog is so much more appealing. It’s concrete, completable in twenty minutes, and the satisfaction of checking it is indistinguishable from the satisfaction of finishing something enormous.

The team had built a productivity system that was excellent at recording intentions and rewarding small wins. That’s genuinely useful. But it was also quietly selecting against the hard stuff, because the hard stuff never gets the checkbox.

Diagram comparing vague outcome-style tasks on the left with concrete action-verb tasks on the right
The verb test: if you can't start the task title with a concrete action, it's not a task yet.

What Happened: The Audit

The team’s engineering manager, frustrated by a quarterly planning session where too many initiatives had simply “carried over” from the previous quarter without explanation, ran an informal audit. She exported the task history for the prior six months and sorted it by time-to-completion. The pattern was striking.

Tasks completed in under two hours: cleared reliably, often ahead of schedule. Tasks estimated to take more than a day: average delay of three weeks past their original due date, with many never completed at all. The list wasn’t a productivity tool. It was a museum of good intentions, with a gift shop full of easy wins at the exit.

She noticed something else. The tasks that kept slipping shared a trait: they weren’t really tasks. They were outcomes dressed up as tasks. “Improve dashboard performance” is not a task. It’s a goal. Nobody knows where to start, so nobody starts. It sits on the list, getting bumped, while “respond to support escalation about export button” gets handled immediately because the next action is obvious.

This is a known problem in productivity theory. David Allen’s Getting Things Done framework, now decades old, is largely built around the insight that your brain resists vague commitments. A task without a clear next physical action isn’t a task, it’s anxiety with a due date. But most task management tools don’t enforce this distinction. They accept whatever you type and give you a checkbox regardless.

Why It Matters: The System Is Winning

Here’s the uncomfortable part. The team wasn’t failing because they were disorganized. They were failing because they were organized, in the wrong direction. The system gave them the feeling of productivity without the substance. Your most important work probably isn’t on your task list at all, and when it does make it onto the list, it often gets buried under a layer of manageable, checkbox-worthy noise.

This matters beyond one team’s quarterly review. The way you structure your task system shapes what you actually spend time on, often without you realizing it. A system that rewards capture and quick completion will gradually train you to prefer capture and quick completion. You’ll become very good at maintaining the system and progressively worse at the work the system supposedly supports.

The productivity industry has a financial incentive to keep you engaged with the tool. Features like streaks, completion counts, and visual progress bars are engagement mechanics. They work. They also subtly shift your goal from “finish meaningful work” to “maintain the streak.” This isn’t a conspiracy; it’s just product design doing its job. Your job is to notice when the tool’s incentives and your own have quietly diverged.

What They Changed: Three Practical Fixes

The team made three changes, none of which required switching tools.

First, they banned outcome-phrasing in task titles. Any task had to start with a verb that described a specific action: “Write first draft of,” “Schedule call with,” “Run query against,” “Delete unused.” If you couldn’t phrase it that way, it wasn’t a task yet. It was a project, and it needed to be broken down before it went on any list.

Second, they separated capture from commitment. They kept a weekly inbox (still in Asana) where anything could land, no due date required. Every Monday, items from the inbox were either broken into real tasks and scheduled, or moved to a “someday” list with no due date and no pretense that they’d happen this week. The inbox was where good intentions lived. The active list was where commitments lived. These are different things.

Third, they time-boxed by task type. Large project work got calendar blocks, not just task entries. The calendar is a harder commitment than a task list. If “redesign onboarding flow” has a four-hour block on Thursday, it competes directly with other calendar items rather than against “update Slack channel description” in an undifferentiated list. The calendar forces the tradeoff to be explicit.

Within two quarters, the pattern of carry-over work had reversed. More importantly, the team reported feeling less busy and more productive, which is the best possible outcome, because “feeling busy” is often the system’s signal that something is wrong.

What You Can Learn Right Now

You don’t need a new app. You need to audit what your current system is actually optimized for.

Look at your task list and count how many items have been there for more than three weeks. Now look at what they have in common. If they’re the vague, high-stakes, hard-to-start ones, your system is working exactly as designed. The design just isn’t working for you.

Apply the verb test to every task on your list this week. If you can’t start the title with a concrete action verb, it’s not a task. Break it down until it is. This takes fifteen minutes and will immediately tell you which “tasks” are really just anxieties wearing a checkbox.

Then put one important-but-slipping item on your calendar as a block. Not on the list. On the calendar. See what happens.

The goal isn’t to optimize the list. The goal is to make the list matter less, because the work is getting done.