How To Define A Task

Every task in trydeepwork asks a simple question: how long will this take?

Sometimes that question is easy to answer. Sometimes it feels strangely dishonest. That usually shows up when the work isn’t fully clear yet.

Task estimation assumes something very specific: that you already know what the work is, how to break it down, and what “done” looks like. That assumption holds for a lot of execution-heavy work like replying to emails, fixing a known bug, refactoring a small, well-understood component. In these cases, estimation works because the shape of the work is already known.

But plenty of work doesn’t start that way. Sometimes you’re doing something for the first time. Sometimes you don’t yet understand the problem space. Sometimes the whole point is to figure out what to do next. In those cases, estimating duration feels awkward because the question itself is premature.

What a task actually represents

We often treat a task as a container for effort, something like “work on X for N hours.” But that framing isn’t very useful, because it tells you nothing about whether anything actually changed.

I’ve started thinking about it differently: a task is a unit of progress you want to notice and track. Not time spent or effort applied but progress made.

When I can’t tell what changed after working on something, that’s usually a sign the task was too vague to begin with.

What breaks with very long tasks

This becomes especially clear when a task stretches into tens or hundreds of hours. Over time, a few things quietly break:

• Completion becomes fuzzy. There’s no clear sense of “done.”

• Progress is hard to articulate. Each session blends into the next.

• Scope grows unnoticed. The task absorbs more and more work without anyone deciding it should.

We can keep logging time, but after a while we are no longer tracking progress, we’re just tracking effort.

This is also where motivation starts to drop. I’ve felt this myself: logging time against the same task for a week straight starts to feel like feeding a spreadsheet, and almost traumatic. It just doesn’t feel like we’re making progress. Working on the same never-ending task day after day is draining, even when things are moving. It’s a feedback problem.

Why feedback loops matter

Small, bounded tasks create tight feedback loops: we work, something changes, we can tell what changed. That loop is what lets us reflect, learn, and adjust.

Very large tasks break that loop. Effort accumulates, but insight doesn’t. Reflection stops being useful because it’s no longer clear which effort led to which outcome. We are left with a vague sense that we have been busy, but not much else.

This is why I’m opinionated about task size. The tool works best for tasks that can be completed within about a week, ideally somewhere between 30 minutes and 8 hours, with a clear sense of “done.” It’s about keeping the feedback loop intact.

When tasks are small enough, progress stays visible, completion feels meaningful, and reflection actually teaches you something. Beyond that size, tracking degrades quickly - at least in my experience.

But what about big, open-ended work?

Long-term projects are real. Exploratory work is real too. I’ve found that trying to represent all of that as a single task usually doesn’t work very well.

Big work doesn’t disappear, it just needs a different shape. Instead of one massive task, I try to ask: what can I do in the next few hours that would make progress feel tangible? That might look like:

• “Explore X and write down what I find”

• “Figure out the right next steps”

• “Test whether Y is worth pursuing”

I don’t need full clarity upfront. I just need enough clarity for the next few hours. Exploratory work becomes a sequence of probes rather than a single blob of effort.

I’m honestly not sure this works for every kind of creative or research work - that’s why there’s no hard limit on task duration. Some things genuinely resist decomposition. But it’s a better starting point than a 50-hour task called “figure it out.”