Making epic tasks as easy as eating an elephant

Logseq is a great GTD tool. If you have an epic project you can create a page for it and break it down into tons of milestones and tasks.

Normally, if I have an epic I’m working on it multiple times a week for potentially months. And rather than attempt to continually add the right task to my daily to-dos, I systemize getting the thing done.

For example, if you have a project “Launch YouTube Clone” that’ll be a page with tons of stuff. I’ll create a TODO linked to the project page and schedule it on a repeater (e.g. every 2 days) and tag it with #25m or #50m, which signify pomodoros. This makes reaching the goal systematic.

I have a front page (Journals) that serves as my dashboard and includes my current list of TODOs based on custom queries. Then each time I complete that pomodoro the TODO gets momentarily pushed off the list and I get that instant sense of completing the work for the day. But soon enough, it’s back.

This is for those who, like me, are a little more whimsical about which particular task they want to work on in any given day. What it does is keep your epic goals continually in view until they get done while removing the fuss of trying to figure out which subtask to schedule.

7 Likes

I love this!!! Thanks for this idea!
I always struggle with tasks that are too big for one day, but too small for a whole project on its own.
This solves that very elegantly. I can still cross of the task, without actually crossing it off.
Very nice!

3 Likes

Right. That’s how I use it. The satisfaction of crossing off an item is a bit more motivating than not.

4 Likes

Stealing this for the project management video I’m working on. Love the simplicity of it.

3 Likes

I’ve come to operate in a very similar way. For anything more complex than an individual task or something that might take a few days or won’t be done for a while I will go ahead and create a page for that project and I usually tag them with something like Project so I can easily find all of my projects.

I then create a heading called Requirements or To Do and then make a list of tasks under that. I’ll keep breaking those down or even make their own pages. I end up breaking my larger projects into a bunch of lists of smaller tasks down that can be easily managed and quickly understood.

Once I have these lists of tasks that are all block referenced or block embedded together to create a grand roadmap I will use block embeds to the tasks and page links to document my ongoing work and progress towards a task. Each task I can expand and see what I did to solve that and I can easily recall it; whether it was last week or last year, it doesn’t matter.

The advantage off using block refs and block embeds is that I can easily remove the tasks which are completed or presently irrelevant in a non-destructive way. Basically I’m trying to make the progression of my graph completely additive and not destructive in any way so that I can preserve history and my working logs.

2 Likes

I read these posts long ago, found them inspiring:

It shows how the reason we avoid some projects is because we’ve failed to break down the task into easily doable bits. We resist the work because it’s too big or too nebulous.

I found you could follow the advice in the article or you could just do what I proposed above, my tack being a bit easier. Since much work is iterative and the breaking down is not usually completed in a single go, I find flagging it as a pomodoro good enough. Each time you dive in you decide and execute a next step. Of course, you can always break down the task a little each time, too, the pomodoro signaling that.

1 Like