The Truth About GTD Software Tools

I completely disagree with Allen here. His statement even seems internally contradictory to me. As far as I understand what he said, the GTD system cannot be implemented in any application because it is "holistic." Firstly, this would mean that it is even more impossible to implement it "on paper," because "paper" solutions are inherently static. This would mean that Allen has created a brilliant yet unimplementable system. Nonsense.
Unless by "holistic" he doesn't mean "comprehensive," but "infinite," but then we're back to square one.

Secondly, claiming there's no market for a given product without trying to sell it is pure guesswork. Period.

Thirdly, I got the impression that Allen hopes that GTD will define the next steps so that you'll know exactly what needs to be done. Unfortunately, this isn't the case, especially in highly creative fields like programming. Someone will soon tell me that you can define a task as "Implement class XYZ / function ABC." To a certain extent, yes. But writing a program is really an iterative process with many steps forward and backward, constant corrections, etc., etc. It's often better to write down the next action in more general terms and simply think creatively as you go.

Fourthly, I don't understand his objection to lists. After all, that's a part of GTD. And here, software is much more user-friendly than "paper." If I have dozens or hundreds of next actions, and it's 7:00 PM on a Wednesday, and I'm low on energy and have an hour to spare, I can filter out potential actions faster in my Evernote than on paper.

In summary, I think it would be better to say: we don't intend to certify any program because it's too risky, or we simply don't want to, than to claim we're not doing it because it's impossible.
 
I haven't been able to watch the video yet, but to me the lists are just where I store the results of my thinking. While they are important, they are only part of the system. The GTD habits are at least as important, and are not easy to implement in software.
 
I completely disagree with Allen here. His statement even seems internally contradictory to me. As far as I understand what he said, the GTD system cannot be implemented in any application because it is "holistic." Firstly, this would mean that it is even more impossible to implement it "on paper," because "paper" solutions are inherently static. This would mean that Allen has created a brilliant yet unimplementable system. Nonsense.
Unless by "holistic" he doesn't mean "comprehensive," but "infinite," but then we're back to square one.
@Tom_Hagen If you assume that GTD = list manager then you're right. But it's a wrong assumption. GTD is a holistic approach to focus our attention where we want it to be focused. List managers (analog and digital) are just tools that free our minds from remembering the details of the outcomes of our thinking process. A list manager for a GTD system is like a shovel for building a house.

Secondly, claiming there's no market for a given product without trying to sell it is pure guesswork. Period.
In this video @DavidAllen says that he tried to develop the GTD app twice but failed. Why? Because such app would have to integrate with (ro replace) many different business applications that we use to store information relevant to our Goals, Areas of Focus, Projects, and Actions.
 
if you discuss with people the very near question they will probably ask is : what tool do you use ? And after which is the best ? I agree with David there is no answer. For me Gtd is not complicated. It is collection of behaviour and process. AI is and softwares can help but i hope they will never decide for us. A collection of lists on sheets of paper can be better than the best complex tool or an ERP. i stopped searching tool when i understood that i had to drive my own life conscientiously. The bullet journal helped me and still helps me for that purpose. Wanting to manage everything from a software is an illusion. It is like driving on an highway and dropping the flying hoping that the car will naturally go in the right direction..,
 
I'll respond collectively:
@TesTeq I never claimed that GTD is all about lists. You attribute that claim to me and then argue with it. The "holistic" argument is too general. It would be best to point out which functionality/aspect of GTD cannot be translated programmatically.
It just so happens that I've been administering and working with ERP software practically from the beginning of my career. These are "behemoths". Yet they can encompass the entire complexity of company operations: projects, warehouse management, accounting, logistics, production, picking, and much more. And they can be versatile enough to be implemented in companies with diverse business profiles.

With all due respect to GTD, this system isn't as complex as ERP systems.

The fact that Allen or his team failed to create a suitable application doesn't necessarily mean that such a thing is impossible. It's quite possible that they lacked the necessary skills. Designing a productivity system is one thing, but translating it into an IT system is quite another. I'd love to know the details of where they "failed."

I use Evernote, and although it's not a dedicated GTD system, I managed to implement all the levels, such as vision, AOF, projects, etc., in it. I don't see anything difficult about it. This is also true in the context of a new application.

@cfoley Like TesTeq, I'm not saying GTD is just lists.

@FocusGuy I agree with you. But as far as I understand Allen's statement, he's not saying it's impossible to write a perfect program for everyone (because that's truly impossible), but rather that writing an application that meets GTD requirements seems impossible to him. And I disagree with that.

Unfortunately, Allen's statement is too general. A long time ago, I came across a post of his where he was drawing up a design for a suitable application. There was a dashboard, if I remember correctly, and many other elements. As a programmer, I see no problem with implementing a dashboard and implementing everything GTD addresses.

So, I'd love to know what element can't be implemented. Of course, the system won't completely do the thinking for us. But that's like expecting a spreadsheet to figure out what data we want to work with.
 
I'll add one more thing: why doesn't Allen's point seem consistent to me? Let's assume he's right that it's impossible to write a good program that meets all the requirements of GTD. What conclusion does that make? Well, we have two solutions:
1. Either you can implement a system with all the requirements in a different way, and then we're left with only one: analog, i.e., paper.
2. Or you can't implement GTD at all to meet all the requirements, and then it means Allen designed a utopia.

I think we can reject point 2.

So the question arises: what paper solutions can't be transferred to the digital world?

PS. There's also a third solution: that GTD is so complex that it requires a mix of paper and digital tools. But this contradicts the message from the book, in which Allen doesn't mention—or at least I don't remember—that a computer is absolutely necessary for GTD.
 
Fourthly, I don't understand his objection to lists. After all, that's a part of GTD. And here, software is much more user-friendly than "paper." If I have dozens or hundreds of next actions, and it's 7:00 PM on a Wednesday, and I'm low on energy and have an hour to spare, I can filter out potential actions faster in my Evernote than on paper.
I don't think he objects to lists. Managing lists is essential to GTD. I think his problem is developing a way for a program to interact with lists in a way everyone likes. I certainly interact with my lists differently than most people on the forum. And that difference is what breaks down the development of a comprehensive program. He also noted the many inputs that necessarily have to be dealt with. He would need to have an integrated email system, a quick note taking system and those all would have to somehow be transferred to projects, reference or any number of clarifying decisions. How can any programmer know from beginning to end the desired outcomes of each individual user? And only you can decide if an item is Defer, delete, delegate, or do.
 
There's no problem writing a program integrated with emails. PIM programs existed as early as the 1990s. Converting emails into projects or other elements is trivial.

However, the processes you're describing are implemented by creating a workflow framework. At the company I work for, we have two systems with something like this. A simple example: we want to implement the 2-minute rule (this is a GTD principle) and we want it to be configurable, as Allen described. I don't see any design problem in implementing it so that the user defines that the 10-minute rule applies on Mondays, Wednesdays, and Fridays from 5:00 PM to 9:00 PM during daylight saving time. The remaining times are 2 minutes. This way, other processing elements could also be created.

Allen once wrote that perhaps one day systems will be so intelligent that they will suggest: "Hey, you have some tools on your shopping list, and you're next to a hardware store. Maybe you should buy them."

Well, such solutions are also within reach. We have access to GPS APIs, and we have AI that's perfectly capable of associating a hammer or nail with the information that we're 50 meters from a hardware store.

That's why I'll keep coming back to the question: what GTD features can't be implemented in an app?
 
I use GTD because it gives me freedom in the moment to make choices which can make my life richer and more meaningful. That freedom is precisely what cannot be realized by rote adherence to GTD as a set of algorithms. My bible in this is Ready For Anything, which for me explains David Allen’s thinking about GTD.
 
I hate chiming in on the discussions around GTD tools & software since they are all superfluous discussions. However, there is a conflation here with the term "GTD".

When David Allen is talking about GTD, he's referring to the five phases: Capture, Clarify, Organize, Reflect, and Engage.

When most other people are talking about "GTD", they are referring to the reminders structure/organization schema/classification system/etc. (i.e. an actions list, a projects list, contexts, a waiting for item, etc.).

The clip referred to here, which is part of an older video that may have more context when viewed in full, has David Allen talking about GTD in terms of the five phases. In that case, he's 100% correct that it can't ever be digitized since it's just human behaviors: capturing what is on your mind, deciding what you are going to do about it, recording that decision somewhere for future reference, checking your recorded decisions to decide what you can/should do, and then actually doing the task/work. You can no more digitize GTD, as it is being used in this context (no pun intended), than you can digitize exercise(ing).

In the case of the reminder structure or "system", it absolutely could be digitized since, as David Allen says, it's all just a bunch of lists. There can be integrations between various software applications and various features, functions, and facets to the particular program you use, sure. Does the optimal or ideal software application exist? That is the same question as "Does the optimal or ideal food exist?" and it has the same answer. :)

Hope that helps!
 
Last edited:
Interesting discussion. One might take the view one's phone and all apps one is using to free the mind, plan, reflect and organize IS one's GTD trusted system. Apps today work so seamlessly together, particularly if one is on a given platform say all Apple-stock apps or Google apps, etc. I recently ran an interesting experiment. Google has apps for everything — calendar, contacts, notes, mail, file management, tasks, documents and on and on. Gemini can now work with every single app taking into account user personality and preferences if one opts to program that. Under such as system it is possible to speak naturally and have Gemini handle things much as a real world assistant would. Gemini executes deeply within the platform in ways not yet possible through traditional agents like Siri or Alexa, though that is likely to change in the near term. The software, Gemini with its abilities to work with anything within the Google ecosystem can even work in the car, some cars will be deploying integrated Gemini in the next year so its possible to be driving and get analysis and discussion on anything in one's trusted system, add to it in terms of notes or tasks in ways so natural it is unlike anything previously done with a voice assistance. I had it read and summarize email, create tasks from email, create notes, plan meals for the week based on a curated set of recipes in Google Drive, mark projects done, read and review my schedule, and on and on. Yes, some of this has been possible with non LLM voice assistants, but I have seen nothing like what I was able to do with this experiment. So if one puts everything into a given platform then the platform itself with its deep integration and abilities can be viewed as the trusted system, and the magic happens when the LLM assistant has access to everything on the platform. So in that sense the platform becomes the one app to rule them all. This is still in development phase, but I think the large computing platforms in their totality can be viewed as the one "GTD" app with natural input and interaction and retrieval. It does look like that level performance is on the way in the next couple of years. One still has to do the "work" of GTD of course, but this represents a potentially significantly more friction-free way to practice GTD. A system of this kind integrates paper well as it is easy to scan paper notes into the system and then the LLM reads the notes, creates tasks and adds them to the right app, etc. I'm not endorsing a given platform, just adding to the discussion in terms of what these platforms are now able to do and how the platform is likely the "GTD app" to rule them all. An "app" as a "platform" cost billions to make and decades to develop, but this seems to be within the realm of large computing companies and their platforms, particularly as LLM get plugged into the traditional inputs across the multiple apps on a platform where we store most if not all GTD-esque inputs, including lists, etc.
 
Last edited:
I use GTD because it gives me freedom in the moment to make choices which can make my life richer and more meaningful. That freedom is precisely what cannot be realized by rote adherence to GTD as a set of algorithms. My bible in this is Ready For Anything, which for me explains David Allen’s thinking about GTD.
I'm sorry, but this is so general that there's nothing to address. This statement can be boiled down to: my freedom cannot be translated into algorithms. Please be specific about what cannot be translated into processes.
 
Hope that helps!
Valuable points. When I write about a GTD app, I don't mean something that will replace a human. I don't think anyone has that in mind. Instead, I'm talking about support. I once watched another video where Allen described his dream app, and the support was "more intelligent" than simple lists. But I also remember that what he described there, including the dashboard, was perfectly feasible.

Getting back to that support: no one expects Word/Writer or a similar app to write a book or article for you, but to enable you, check for errors, etc., etc.

In all these discussions, what's missing is specifics. I keep reading "it can't be done," because it's too complicated, because it's my freedom, because Allen said so.
 
Interesting discussion. [...]
Thank you for this post. This is more or less what I'm talking about. There's a "vast gulf" between the technology when Allen was trying to design the app and today.

If GTD can be implemented "analog," then it can be implemented in software today.

As I've emphasized many times in this discussion: no one here is providing specifics on what can't be translated into a programming language. I suspect many people treat Allen as an oracle who can't make a mistake. He can. And even within GTD itself, he's modifying his stance (see: the first and second editions of GTD and his approach to daily lists).
 
I'm sorry, but this is so general that there's nothing to address. This statement can be boiled down to: my freedom cannot be translated into algorithms. Please be specific about what cannot be translated into processes.
Consider the threefold nature of work: doing work when it shows up, doing pre-defined work, or defining our work. Those are distinct modalities, but I don’t need or want any external prompt for or logging of transitions between them. Another related example is work at different horizons; next actions, projects, areas of focus, and so on. I have reminders to review the higher horizons, but at any time I may perceive a need to change levels. David Allen is pretty explicit about his belief that no simple algorithm is adequate; as he says, “Trust your gut.” In the early years of our marriage, my wife and I would sometimes use a standard approach to making important decisions: list relevant factors, assign those factors weights, et cetera. When we did this exercise, we always ended up ignoring the final result of the process. Our preferred choice was always clear to us. I think it’s wonderful and crucial that each of us can improve our approach to GTD, including the tools we use, but the most important component of a “GTD system” is the person using GTD.
 
Consider the threefold nature of work: doing work when it shows up, [...]

I still don't see anything concrete here beyond the slogan "trust your intuition." To me, this is illogical: claiming that we can implement GTD analogue but not digitally. If I manage projects, next-step lists, agendas, and a calendar in one planner, that's a valid GTD implementation. But when I implement the same or even more in an app, that's not the case! It's internally contradictory.

The fact that you ignored the final result in your decision-making process means you adopted a poor algorithm and assigned either incorrect weights or calculated the wrong factors altogether.

I'm sorry, but any: it's not possible because it's too complicated, it's not possible because "people are the most important," it's not possible <insert another amorphous statement here> doesn't convince me.

What I'm writing isn't just theory, as a few years ago I wrote a GTD app for my own needs, with features I found useful.

For example, if I marked an action as completed on the next actions list, and it was part of a project, the next action from that project would immediately appear on the next actions list.

Of course, if I needed to, I could make it configurable, designate the action as a milestone, define dependencies, and so on. After all, I wrote it myself – just for myself – and I've used it successfully.

I had a dashboard there, the program calculated the estimated completion of the project based on the progress so far, etc.
 
@Tom_Hagen Who claims it? David Allen says that you can use paper or any capable software as a LIST MANAGER. As a tool for GTD, not as GTD itself.
yes tools are different than philosophy and implementation. How would you program an app that does both and to the satisfaction of each user?
 
I still don't see anything concrete here beyond the slogan "trust your intuition." To me, this is illogical: claiming that we can implement GTD analogue but not digitally. If I manage projects, next-step lists, agendas, and a calendar in one planner, that's a valid GTD implementation. But when I implement the same or even more in an app, that's not the case! It's internally contradictory.
I’m not claiming that. I don’t think anyone is.
The fact that you ignored the final result in your decision-making process means you adopted a poor algorithm and assigned either incorrect weights or calculated the wrong factors altogether.
I think you are likely more optimistic about the replacement of human intuition than I am.
I'm sorry, but any: it's not possible because it's too complicated, it's not possible because "people are the most important," it's not possible <insert another amorphous statement here> doesn't convince me.

What I'm writing isn't just theory, as a few years ago I wrote a GTD app for my own needs, with features I found useful.

For example, if I marked an action as completed on the next actions list, and it was part of a project, the next action from that project would immediately appear on the next actions list.

Of course, if I needed to, I could make it configurable, designate the action as a milestone, define dependencies, and so on. After all, I wrote it myself – just for myself – and I've used it successfully.

I had a dashboard there, the program calculated the estimated completion of the project based on the progress so far, etc.
I’m sure it worked well for you. We know that many implementations of aspects of GTD are possible. Can anyone write something that works well for everyone? I think probably not. But there are core parts of GTD decision making which seem to me to be subtle and difficult to capture in a simple way that works for everyone.
 
Top