Ep. 337: Five Principles of Productivity  ## Metadata - Author: [[Getting Things Done]] - Full Title: Ep. 337: Five Principles of Productivity - Category: #podcasts - URL: https://share.snipd.com/episode/4a1625c3-db8d-4b83-8a1a-1fd673e8f015 ## Document Notes ## Highlights - **Long Partnership That Shaped A GTD App** - Eric Mack built e-productivity as a GTD-aligned tool and David Allen used it for many years. - David still calls it the second-best GTD app because no one has built his ultimate GTD application yet. Transcript: David Allen My friend and colleague, Eric Mack, has been my trusted advisor and my personal coach in the use of tools and technology for the past 30 years. His work is grounded in GTD and personal knowledge management. He's focused on the relationship between knowledge, methods, and tools, and how we use these to accomplish more with less effort. Eric is also the creator of the second best GTD productivity software, the one I used for many years and the only one I certified as GTD inside. I say second best because my ultimate GTD application still does not exist yet. Seriously folks, Eric Mack gets GTD in the workplace in the way few others do. Two years ago, Eric moved our company to Microsoft 365. We're still learning the ins and outs of the new tools. At the same time, we're really missing some of the features Eric designed in his GTD solution, e-productivity, more than 15 years ago. While there's much we like about Microsoft 365, I often feel like I'm taking a step back with the loss of key productivity features that I've depended on for so many years. ([Time 0:00:10](https://share.snipd.com/snip/b0a9f462-ba7d-4e30-a999-923854b6bb2d)) - **Tools Should Support Thinking Not Shape It** - Tools often shape workflows instead of supporting preexisting thinking, which breaks workplaces. - A good productivity tool should support the user's thinking rather than impose its structure. Transcript: David Allen Designers of productivity software to incorporate some of these principles into their productivity tools. Microsoft and others, I hope you're listening. You know, a long-time GTD practitioner, Eric understands the relationship between knowledge, and tools better than anyone I know. Currently, he's doing a survey on work styles and key frustrations, and I want to encourage the GTD community to take his survey. I did, and I found it helpful to us in understanding how we work, what we can do to improve, and more. John will provide the details at the end of the podcast, so be sure to listen to the end. Hi, everyone. John Forrester This is John Forrester, and I'm here talking with David Allen and Eric Mack. Hi, gentlemen. Hey, everybody. Hi, guys. We're here to talk about software for GTD. The idea for this came when Eric said, I'd like to talk about the design principles I had in mind that I worked with David on when I was designing software to implement GTD. And that led us to this idea of talking about design principles that worked years ago, ([Time 0:01:51](https://share.snipd.com/snip/df4db21f-dcf6-48bd-b287-817eced025cb)) - **David's 1995 GTD Screen Blueprints** - In 1995 David sketched his ideal GTD screens on graph paper and kept them private as IP. - He later shared those drawings publicly when nothing close had been built in decades. Transcript: David Allen Don't want to rehash too much that people may already know, but let's rewind the tape back to the early 1990s when I wrote an article about why PIMs don't work. PIM, P-I personal information managers. Why they didn't work. I remember that. Right. And I wrote that article and shared it with my good friend, Patty C. Bolden, Tom Hagen. They said, gee, David, this is not an article. This is a business plan. And so that's why Tom Hagen became a partner with me and said, okay, let's try to see if we can create a company to build software around a PIM that actually does work. So that's where we got started with that. And so in 1995, I sat down in the Boston Marriott, Cambridge Marriott, one night. And I had a pen and pencil or pen and graph paper and I drew, okay, here's what I would like as my screens. If I could, and I'm not a software designer, I'm not a software engineer. I said, look, here's what I'd like on my screen. So give me this. And then I want to be able to click that to be able to then go to this. But if I do that, I want it to then tell me this and whatever. And, you know, I took a whole evening. I don't know if it was one or two nights, but that was it. And I drew those things. And that's a PDF file. I think we'll make available. Yeah. If they hadn't seen it yet. At some point I said, this is IP. And this is, I didn't, I was legally just wanted to keep it to myself because I thought at some point somebody actually might do this. And because by 2019, after, you know, what was that, 20 plus years, nobody had done anything close to that. I said, well, screw it. Let me just share with the world. ([Time 0:08:03](https://share.snipd.com/snip/729e2955-7245-4999-894e-fd8abeb164e3)) - **Decision Support Not Decision Replacement** - Software can provide decision support to facilitate thinking without doing the thinking for you. - David designed e-productivity to prompt project thinking, next actions, and short brainstorming to support decisions. Transcript: David Allen You know, the fact that once I used e-productivity, if I label something a project, put it on my project list, and it didn't have a next action that was automatically tied to it, it had A frowny face. Oh my God, dude. There is thinking done for me that the software facilitated. And nobody's done anything like that. Eric Mack Now we're going to see a bunch of productivity software apps come out with frowny faces. Yeah. David Allen No, but that was great, Eric. We can talk about the history of how you developed the productivity and you and I going back and forth about all that. But, you know, that was one of the things, you know, and again, part of my vision was look, if I just dump stuff out of my head and then have the software say, David, what is this? What's the next action? Can you finish this in two minutes or whatever? If you can't, then is this a project? And what's the next action? And if I label it a project, it said, by the way, do you want to go do some project thinking about this? And I can already build it in default that it gives me two minutes to do project brainstorming on anything. And I labeled a project, but it pulls up whatever connection I have to whatever project thinking tool I have. Gives me two minutes, then gives me alarm. Ding. You want to keep thinking, David? Are you okay? By the way, any next actions out of this? Keep going. So this is the algorithm of how I thought the digital world could facilitate the thinking, not do the thinking, but facilitate it called decision support. And here's what I need to think about this that I just put in there. And it could know that. Or how I need to think about that. It could know that. And I designed that. ([Time 0:14:00](https://share.snipd.com/snip/01eb50ca-befa-4609-84ba-543056566fe6)) - **System Plus People Equals Productivity** - Both a functional system and people who use it well are required for high productivity. - Good processes plus trained users produce better outcomes than either alone. Transcript: David Allen And so I'll apologize here for the paid political announcement. We have a new book coming out that should show up early next year in 2024 of team getting things done with others. And one of our chapters is about, well, one of the points we make in there is back to Deming. Let's roll the tape back to Deming in Japan, where he studied Toyota and the whole Kanban idea. So Eric, to your point, you're talking about sort of the digital personal systems, but the whole organizational systems. Let's go Kanban, Scrum, Agile, TQM. All those things were models that were actually useful to a large degree. But, and if you have a crummy system, even if you have great people, you're going to come out with a crummy product. But conversely, you have a great system, but people that manage it crumbly in a crummy way, you're still going to have a crummy product. And you have to have both. So you have to have both the system that's functional, that works, like GDD, and then you have people who have to be able to then utilize that in some way that's functional. ([Time 0:23:02](https://share.snipd.com/snip/a5012064-5c29-443d-adef-61ce25be020c)) - **Use Principles To Guide Tool Design** - Design productivity software around core principles to avoid feature creep and friction. - Use principles to evaluate tools even if you're not developing software yourself. Transcript: Eric Mack All right, so here's what I'm going to do. I'm going to share with you my five principles of productivity software design. I don't claim that these are the only principles, but these are the principles that I used that guided my work, past and present. I'm no longer involved in software development, but when I have to select tools for myself, I still come back to these same principles to help me evaluate the tool. And so all the people who send me software and say, oh yeah, can you just put this in front of David because it's a game changer, kind of look at it through the same kind of mental filter to See what's going on. So here are my five principles and I'll take you through them. The first one is no leaks. Next is attract more than repel. And if you've been around the GTD community for any length of time, you've heard some of this, But I'm going to get very specific in this. Next one is all features must pass the 306090 test. Next is add productive value, not burden. And finally, would David Allen or Eric Mack use this? And so if you're okay with that, John, what I'd like to do is I'll step through each one. Guys, feel free to ask any questions. ([Time 0:27:27](https://share.snipd.com/snip/dfc0003a-5eb2-4332-aead-d3843065227b)) - **Eliminate System 'Leaks' To Build Trust** - Prevent 'leaks' by surfacing unprocessed or unclassified items so users trust the system. - Show clear markers (e.g., sad/happy faces) and prompt users about unclassified captures at startup. Transcript: Eric Mack Design principle, no leaks. So I wrote, we're building a system that must be trusted. And what do I mean by that? That means there can be no inherent potential leaks in the system that are not visible or announced to the user. Leak is anytime I have information that I've parked that I depend upon that is not brought back to my forefront in thinking. So let me give you an example. In the GTD methodology, you could even argue that a project, since you don't do projects, you do actions, a project without an action is missing something. And that could be a leak in your system. That's why, David, when I sat down to try to figure out how do we handle this version one, we used to force you. You could not even exit the project without defining an accident. But then that put a burden, a cognitive burden on the user, and you'll hear about that later on. So then I changed it, and ultimately, after many iterations of testing, I ended up with a very simple solution, a sad face or a happy face. It was just enough there to guide you into the way of thinking that I wanted you to experience the full GTD experience, and yet it wasn't in your face. If you had a reason for creating a project and not creating an action at that very moment, that was totally okay. But following this principle of no leaks, later on, as you're working through the system, you would still see something come by with a sad face so that you knew, hey, there's something Happening here that I need to go back and take action on. John Forrester Which also supports the weekly review habit. Absolutely. What David calls the critical success factor. If you're struggling at all with getting into a weekly review, imagine how easy it would be to do the step where you review projects and make sure they have next actions. If you could just, at a glance, know which ones need next actions. Precisely. Eric Mack In fact, I had never intended to leave the smiley faces or sad faces in the final product. But when I took it out at one point, I had a CEO of a company call me and they said, why did you take that out? I have employees who were printing out their projects and actions list and dropping it in my inbox just so that I'd see all the smiley faces. And I thought, well, if it's having that much of a positive impact, you know, it's easy to leave in. And so the final point under the no leaks principle is to alert the user to unclassified or undecided items. So in GTD, context is very, very important. So while I made it very easy for you to capture items regardless of your context, and I even allowed you to capture an item without giving it a context, I made it my responsibility to notify You that there were items that were not classified in your system. And so that's why whenever you started up the program, the first thing it did is it did a miniature sweep of your system and it came back and you had three unclassified items. Would you like to classify these now? And you could always say, no, I need to get to work. ([Time 0:28:56](https://share.snipd.com/snip/a5fce830-7773-4cf6-98d0-3a108808f76d)) - **Design For Immediate Capture And Minimal Steps** - Make tools attract use by minimizing steps and friction: reduce clicks, prefill fields, and offer one-button capture. - Prioritize quick capture, quick review, and fast retrieval to encourage durable habits. Transcript: Eric Mack And please jump in, David, because you were on the opposite side of this. And John, you were aware of all of this as this was progressing. The second design principle is to attract more than repel. And I know you've heard that, and we've indeed talked about that on many GTD podcasts, but let me tell you what that means for me from a software design perspective. That means to be careful not to create unconscious resistance, keeping personal in productivity. And I even shared earlier, there's a fine line between thinking about the actions that you need to take to get something done versus thinking about the tool to manage those actions. All too often when I'm coaching somebody, I see them trying to go, well, how do I make this tool do that? Oh, you know, I don't know how to do this. And it completely just takes their focus off of the work they were trying to do and onto how can I cram my work into whatever this software has allowed me to do. And so while I wanted to give them much of an open slate, I wanted to make sure that I didn't impose a cognitive burden on them when they were deciding what to do would repel them from even Using the tool uh the next one is kind of obvious in the software world and yet it isn't so obvious based on what i see and that is require as few steps as possible user must be able to perform Tasks in as few steps as possible, reduce clicks, pre-fill where possible, anticipate or identify choices. But along with that, I also added limit distractions and reduce effort wherever possible. So just because I can have a drop-down box with many choices to choose from, if a radio button would be more efficient for the user, allowing him to see his three choices right up front, Do that for the user, make it easier for them, so that again, they're pulled in and want to use the tool as opposed to the tool becomes a chore along with the rest of the work they already Have to do. Finally, product features must have inherent perceived value to the user to encourage good and lasting habits. Quick capture, quick review, quick retrieval, search, those kinds of things are so important. And yet many times I see those on as afterthoughts. You know, the whole workflow begins with capture. And yet many times I see tools that are either lacking a capture component altogether, or it looks like they just stuck it on at the end, like, oh yeah, we need a quick capture tool and we'll Do that i'd like to see the simplest thing i think the coolest thing that we had going david um back in the day was we had done that introduction that um integration with gironics so that You could hit control q from anywhere in your system without any particular program running, and you could capture something, and that would then trigger the workflow process. I loved that. I would love to have seen more of those kinds of applications. David Allen By the way, have you seen anything like that show up? Eric Mack Not really. I've seen different tools that make capturing easy or easier at one level. What I really want is what we had with the BlackBerry, which is where I can assign one button on the side of the BlackBerry, and that's my capture button. I don't want to have to open an unlock screen. I don't want to have to switch to the app, even if it's as easy as a swipe. There's just too many steps. I just want to be able to, especially now that everything's voice-driven, I just want to be able to click the button, speak the thought, and go. Brain toss and your neck of the woods, David, they've done a nice job with some of that. But then we have the challenge of integrating that in. David Allen Yeah. ([Time 0:33:30](https://share.snipd.com/snip/ff530add-8686-4975-8471-8216c0525f59)) - **Keep Only Features That Stick** - Test features over time (30/60/90 days) and remove those that don't add consistent value. - Avoid shiny, unused features that create internal resistance and clutter the user experience. Transcript: Eric Mack So this was another one that grew out of our work. Now, sometimes people may think that, oh, well, just because I worked with you, David, and I had the opportunity of seeing you on a regular basis, that that gave me an inside edge. Well, I certainly benefited from the friendship and the bantering back and forth and the butting heads, but it was no easy ride for me to do that. In fact, it took about four years from version one to a version that you were willing to actually give up your palm and your other tools to use. And some of those things that we did is many times I'd come to you with an idea for a feature and you'd come back and say, well, let's put that on the calendar and see where you're at with that In 30 days. And as frustrating as that was to me, that ended up being quite wise because there were many features that I created that seemed fantastic in the moment that 60 days later or 30 days later, I wasn't even talking about them. And so that principle allowed me to really reduce the software down to the essence of what's really important. So I had three bullets here. First is every feature must add value. Be watchful for shiny but unproductive or unused features. If you look at a lot of the productivity software that is out there today, you could strip away probably a good 40-50 % of the features and not hurt the essence of the product. But the presence of those extra 40 or 50 features, the problem with that is that it begins to build internal resistance to using the tool. So it's a double-edged sword there. Let me stop. David Allen No, there are Saturday, rainy, cold Saturdays where your inner geek shows up, where all those things are so cool. That'd be so great. And then the sun shines on Monday morning and you go to work. Right. Eric Mack And you don't want to have to think about all those options. David Allen Yeah. Eric Mack So in fact, in the next slide I talk about how we dealt with that right so for every proposed new feature we talking about it 30 days later and then since I did recruit a rather large community Of people to help test the software I asked are a significant number of users still using it consistently 60 or 90 days later. I didn't just want the accolades from people going, hooray, a shiny new feature, a shiny new feature. I wanted to know, hey, I've used my weekly review now for six weeks, and here's how that feature helped me. ([Time 0:37:44](https://share.snipd.com/snip/50ab6462-4f57-4faf-b359-56f7160e7ba5)) - **Default To Simplicity, Let Power Users Opt In** - Make optional features opt-in and disable uncommon options by default to avoid burdening users. - Keep preferences available for power users but keep the default experience simple and intentional. Transcript: Eric Mack Is the user likely to grab for that feature at this time? If so, make it available to him or her. If on the other hand, it's a cool feature, but it's not in any way relevant to the task at hand, don't show it. Move it to a toolbar or just don't even include it all together. And here's a big one, because I certainly was guilty of creating all kinds of features that I thought would add value to the GTD mix or solve a particular use case. Maybe somebody wanted to double nest actions under a project or something. Yet having that feature would make the product too complicated. Certainly I wanted someone to be able to read David's book and walk right into the software with limited training or instructions just as if they truly got the methodology. I wanted the software to be intuitive to them. And so I came up with this sub principle. Any feature that does not add consistent, reproducible value to a user's workflow should be removed or at least disabled by a default in preferences. So in my product, eProductivity, we had about five pages of preferences, each organized around a given functional area, and you never, ever had to look at preferences. But if there was anything you wanted to do that was not readily apparent, chances were pretty good that we had already thought of it and added it as an option so that you could go in and you Could turn on things. If you wanted to lock yourself in so that for example you could never exit a project without defining an action we had a preference for that but we didn't force it upon you okay so most everything Was opt-in not like apple has done recently with the battery charging, the echo-friendly battery charging, where they've opted you in automatically. And that has an impact on my productivity. They should have said, would you like to do this? Click here to opt in. David Allen We ([Time 0:42:24](https://share.snipd.com/snip/c7cc0543-280b-4162-8af7-120c5e6c054f)) - **Software Nudged A German Team Toward GTD** - A German company rolled out e-productivity without formal GTD training and still improved. - The software nudged users toward useful behaviors even if their understanding wasn't GTD-pure. Transcript: David Allen I don't know you can speak to that maybe a little bit. Eric Mack That was really unexpected, David. The initially I wasn't even interested in selling the software to someone who hadn't been through your seminars or coached or something, just because I thought at the time that those Would be requirements. But over time, increasingly, people were asking, hey, let us try this software. Let us try this software. And so I did release it to a small number of people and they had tremendous impacts. And like this company in Germany, they rolled it out to their users and they said, well, let's just see what they discover. To help them do more with the software. But in fact, they rolled it out and people sort of got the idea of a project or an action, not in the clean, pure way that we would think of it from a GTD perspective, but people actually did Quite a bit. ([Time 0:45:09](https://share.snipd.com/snip/66f1169e-ddf9-4941-981c-887911eef781))