D (3:49)

Let me, let me add a little piece to this. And, and Eric, I was, you know, always delighted to have you poke at us and say, okay, let's, let's take this to a next level of conversation that the world might be interested in. Be very easy for me to be bored and go, who cares? Because I've been talking about this for 30 years and nobody's come up with anything yet except, you know, a bit that Eric has did to build some things around Lotus Notes with the productivity and the software he built around this. Based upon what I thought, hey, if the software world would be really cool if it could help me, help me with the thinking I already know I need to do. But it'd be nice to have that thinking triggered by the digital world that I could then play with, because I thought that's a, that's an option. And we actually built some little versions of that with ActionAir. John, you were around those years in the, in the, in the late night, mid to late 90s, you know, in San Francisco. And so the fact that nobody's actually come up with a whole lot of this stuff that seemed so simple and so obvious that it would be pretty easy. And I kind of, you know, so let me admit right now, I'll just apologize right now that I'm a bit of just talking out of my boredom. Nobody seems to do it. Why aren't they doing it? So that you're totally allowed to be.

B (5:20)

Cranky about this after, after repeating yourself for 30 years.

D (5:25)

We can also frame that conversation because I know the audience listening to this might be people out there that go, wow, you're right. And there are things we could do that could improve toward where, Eric, you might help lead us in terms of what you did to design the best thing you could around all this and what people might be able to learn from that. So that's my introductory blab about that. So, Eric Malls, in your part, what would you say?

C (5:52)

Sure. You know, the genesis for this conversation was the fact that at the GTD summit in 2019, you got up on stage and said, I'm going to reveal and share the ultimate GTD productivity system. And you mapped it out. And much to people's surprise, it was a set of drawings and a vision that you had shared with me 20 plus years earlier. And it was part of the stuff you were looking at with Actioneer. And even prior to that, I still get contacted by People every once in a while who wants, want some help or want to think through an application or usually are trying to convince me why their application really needs to be on David Allen's radar. In fact, at the GTD Summit, you were kind enough to say, eric's down here in the front row. And immediately following your presentation at the break, I had several developers come up to me very quickly. Developers and a couple investors all say, oh, well, you know, we could make this happen in just a few months. You know, it's just not a problem. And Wendy is, pardon, pardon us for chuckling at this.

B (7:06)

We've just heard this.

C (7:08)

She's doing her best against. And I told people, I said, look, I don't, I don't mean to be insensitive, but if you think that this can be done in a couple of months, then you and I are really talking about a totally different software application. Right? Because it just doesn't work that way, largely. And maybe, David, you alluded to this because it is, on one hand, it's so common sense that it's uncommon and people look right over it on their path to, oh, this button does this, and this launches a macro to do that and whatnot. So, David, do you want to just share just a little bit quickly about your vision there as a refresher? And then we can put, John, we can put in the show notes a link back to that GTD Summit presentation if somebody wants to drill down further.

D (8:03)

I don't want to rehash too much that people may already know, but, you know, let's rewind the tape back to the early 1990s when I wrote an article about why PIMs don't work. PIM. PIM, Personal Information Managers. Why they didn't work.

C (8:20)

I remembered that right?

D (8:22)

And I wrote that article and shared it with my good friend Patty Sebold at Tom Hagen. They said, gee, David, this is not an article. This is a business plan. And so that's why Tom Hagen, you know, 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 I, in 1995, I sat down in a, in the Boston Marriott, Cambridge Marriott one night, and I had a pen and pencil or pen and, and graph paper, and I drew, okay.

E (9:06)

Here'S what I would like as my.

D (9:07)

Screens if I, 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. 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 just legally just wanted to keep it to myself because I thought at some point somebody actually might do this. And because by night, by 2019, after, you know, what was that, 20 plus years, nobody'd done anything close to that. I said, well, screw it. Let me just share with the world. Let's say, okay, anybody else want to try this? You know, do that. So that's kind of where this came from. I don't know if Eric. That was what you were talking about, but he gives a little bit of an intro about this. But that's, that's. Yeah, that's where all this came from. Yeah.

C (10:18)

You know, it's interesting, I realized that when you were sharing those at the summit, that although I had seen those slides in conversation with you before starting my journey to develop GTD software, I had not recalled those slides and in fact was very focused around just projects, actions, tasks, weekly review. And so I came at it more from a raw approach of saying, okay, David, set forth in the book, here's how the GTD system works. How can I create the tools to support that without getting in the way? Living in the constraints of the development environment that I had to use at the time. I'm curious, David, what kind of response and reaction did you get from people after 2019 when you shared all of those plans publicly?

D (11:11)

Not much, except every week I get somebody telling me, gee, David, like you, Eric, I've now designed the software and I take a look at it. I say, sorry, you know.

C (11:24)

Right.

D (11:24)

You have to convince me otherwise. Basically, people just, all of them just picked up a piece of this, which is what happened. You know, that's why actioneer never really went anywhere, was because actioneer was trying to be encompass as I did the whole thing. But the problem was that parts of the whole thing were done better by Microsoft and by whatever, and Outlook was beginning to own the desktop and there was the Palm Pilot and all of those that showed up after we did all that thinking and so the whole tech world started to show up and do, well, we can do this piece, we could do this. And they were doing that with a whole lot more money and a whole lot more tech than we had access to to be able to pull it.

C (12:10)

All and a lot more glue to try to stitch these things together.

D (12:15)

Sometimes they didn't, frankly, Eric, they didn't even try to stitch it together. Or at least if they did didn't, it wasn't anything like what you needed to do. You still had to be in charge, in charge of your own world. And you know, and that's a lot of what our topic is right now. It's like, is like if people don't understand their own world from a GTD perspective, none of this works. Or, you know, you have to then kludge the different pieces that you have to then pull together and make, and then you yourself have to configure how it all works together and how they intersect with each other.

B (12:51)

I have one thing here to, to put a little reference on this, which is one of the things that often shows up when someone has developed software to do gtd, is that frankly, they don't understand GTD nearly as comprehensively or as much depth as they need to. They may have skimmed the book, they may have looked at a short article, and they don't necessarily really, to use a sci fi term, grok, what GTD really is all about. So they're, they're doing things like designing software that they hope will do the thinking for someone. And if you really understand gtd, you realize that you have to do your own thinking. That's part of this, is you have to think for yourself. The software can make it easier to take action and track things, but it, it can't prioritize or do your thinking for you. That's, that's one of the things that showed up is these. A lot of people haven't understood gtd.

D (13:51)

Well, not only that, John, they didn't actually. The software can do some of the thinking for you. And Eric built some of that into E Productivity. 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. There is thinking done for me. Right, that the software facilitated. Yeah. And nobody's done anything like that.

C (14:23)

Now we're going to see a bunch of productivity software apps come out with frowny faces.

D (14:29)

Yeah, no, but that was great. That was Eric. And we can talk about the history of how you develop heat, productivity, and you and I going back and forth about all that. But you know, that 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, you know, and what's the next action? And if I label it a project and 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 that 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? You know, 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, 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. That's what I, that's what I put in there. And again, nobody's come close to that that I could see yet, ever.

C (16:01)

It's so nuanced, that fine line between supporting thinking and getting in the way of thinking.

D (16:10)

Right.

C (16:11)

No, Ed, one of the benefits.

D (16:12)

Come on, come on. John, you, you remember when we built actioneer, the first versions of actioneer, you know, one of the things we had to do because they were still the sort of agile tech, the agile model had just shown up then. Okay, what's the, what's the first thing we could build that might be useful to people out there they'd be able to buy. And that was the Post it note feed. Post it Note we put on there and then building in automatically that if you wrote that, you could then program it, that if you wrote call on your Post it note, it would automatically stick it on your calls list.

C (16:44)

Yeah, I am seeing some promising stuff showing up in the Microsoft to do environment. Unfortunately, there's a couple of leaks and we'll get to that, that repel me from that. But there are some promising developments that I've seen there that, that I hope they'll continue with.

D (17:01)

Yeah, well, maybe we could talk about that because quite frankly, at age 77. And again, after 30 years of this, where nobody really doing anything about this, I just go, you know, I just tell anybody that asks me by your stuff and say, by the way, I am not interested in the tech world anymore about any of this other than, you know, what I kind of already know and already use.

A (17:25)

And.

D (17:26)

And I said, but. And I get so many. I get a request a week to review stuff, and anytime I review anything or say anything about it or get involved with people, people, David, could you partner with us, you know, so you can do this? And I go, you know, come on. As soon as I implicitly endorse anything, it's going to change in a week or two anyway. Right? So I hopped out. I hopped out of that whole world.

B (17:50)

Yeah, yeah. And it's. It's not that you didn't give a.

D (17:55)

A go more than once.

B (17:56)

In. In addition to actioneer, a few years later, you partnered with Intentional Software. And they had a lot of resources and put a lot of. A lot of time and effort and thought into how to do this. And even they didn't come up with a way to glue all these parts together and take advantage of all the subtlety.

D (18:14)

It probably could have done that if they thought there was a market that would buy it. Yeah, that's the problem. You know, most people we have. We have a lot of problem trying to convince people to even to do the GTD thinking process, much less try to try to build it into software. Sure, sure.

B (18:32)

Well, Eric, do you want to talk about the workplace is broken and say a little about that? That's a. It's a dramatic thing to say. And I know you have a few words about why you say the workplace is broken. And that might be helpful too, here.

C (18:46)

I guess it's kind of a parallel discussion, because some of the reason I think the workplace is broken is precisely because of what's missing and what these design principles that I want to share hopefully address. But when I talk about the workplace being broken, I mean that the environment and the tools have shaped our thinking rather than our thinking guiding this choice of tools that we use and how we use them. And so often I think of it this way. When you hear of systems, I think of systems as something that is pushed down from the top. Okay. You walk into work and they say, here's your new messaging system, here's your new calendar system, here's new whatever. And you typically get very little, say, or input as a user into how that system works or how you get to use it. In fact, sadly, I'm seeing that very little people, very little training is done, in fact, for people into use of these systems. Now, a tool, in contrast, is something that is picked up. A tool is something that is made personal by the fact that somebody grasps it and use it. You have your favorite pen, your ruler, your stapler. A mechanic has his box of tools, and he'll be quite hesitant to loan those tools out because those tools have become personal to him. And so what I try to do is I try to look at all of these applications that are available to us as tools, and they sit in my toolbox. And some I use more than others. And there are reasons for that. Some I use only for one specific purpose. So, you know, in this day and age, it's so common to find a tool that achieves some success and then they start adding all kinds of extraneous features to it to do more and more and more and more when their key benefit that they brought to the table was their first piece. So, for example, the software application you see running behind me, I love it. I use it for very specific things, but I don't necessarily care that they too have a calendar and they too have a task manager, and they too try to give me a project list and so on, because I feel like that that muddies the value that I get from that tool. That's not to say it's a bad tool, but for me, it's not working in that context.

D (21:22)

Right.

B (21:23)

And one of the things that David has emphasized over the years is how much friction does the tool introduce into his workflow? If is the tool getting in my way or is it helping? And I often see with software that shows up, there is so much to ignore because of all the features they add it. It's something we, we don't really necessarily think about much, but how much attention do I have to put on not paying attention to the stuff that the software is trying to throw at me and make me, make me think about it.

C (21:59)

And, and at, at some level, regardless of how well engineered the system is, regardless, at some level, you have to take personal responsibility for the tool and the way you're using it and what you know and how you're applying it. Because when you don't, that's when the tool begins to shape your work. Okay, so PowerPoint and I use these as illustrative examples, but PowerPoint, Word, Outlook are all excellent examples of a class of tools. But if what happens is people begin to think in terms of PowerPoint or they think in terms of Outlook or they think in terms of fill in the blank software, they've allowed that tool to shape how they organize their thinking. Instead of saying, let me think in the great expanse of how things could be and then let me step back and say, what tools do I have to help me either convey that idea or to capture that action and the like.

D (23:01)

Okay. 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 Demic, you know, let's roll the tape back to Deming in Japan where he studied Toyota and the whole Kanban idea, you know. So, Eric, to your point, you know, you're talking about sort of the digital personal systems, but the whole organizational systems. Let's go Kanban, Scrum, Agile, tqm, you know, all those things were models that were actually useful, you know, to a large degree. But. And if you have a crummy system, even if you have great people, you're going to come up with a crummy product. But you, but conversely, you have a great system, but people that manage it crummily 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 gtd, and then you have people who have to be able to then utilize that in some way that's functional. And, and those two things together produce the highest productivity, if you will. But yeah, and I think that's still true that down at the software level, at the software personal productivity level, at the software, whether that's Microsoft or Asana or we can talk about channel creep too, which is another big issue out there.

C (24:59)

Yeah, I think it really involves a shift in mindset. And that's really kind of what my whole practice is about, is helping people shift that mindset in terms of how they think about what they know, who they know, what they know, and the tools that they're using to take personal responsibility for their work. And I think the reason I was so attracted to GTD 30 years ago, before it was called GTD, was the fact that you provided a framework for how to think about work. And that was just gold. And so, you know, in those days, I was coming at it from, oh, well, I could write software to solve anything. And I could, I was pretty good at stuff but the reality was that wasn't the problem that needed solving. And I don't think I really learned that until I had the opportunity to work with you and your team, David, over the years serving you that I realized, okay, ultimately the best software in the world is not going to solve this problem, because here was a company that I was serving that gave me pretty much no limits on what we could use. And yet every once in a while, people would hit a wall with something that didn't work well or whatnot. But the people in your organization were efficient, effective, focused, and they had something that was missing from the tool. And I call that the method. Right. That's the GTD methodology. They had the method. And then ultimately that led me to go back to university and study in information and knowledge management, how we think about our work and how we think about what we know and what we share and so on. But, you know, I think I probably ventured way off topic. John, I came prepared to talk with you about five principles of productivity software design. Would you like me to go through some of those?

B (26:59)

Yes, that's where I was going to go at the next pause.

D (27:02)

And by the way, by the way, Eric and I had such fun batting heads with each other for how many.

B (27:08)

Months or a couple of years back then?

C (27:13)

Yeah, four years.

B (27:15)

Eric would come in with ideas for features and things and David would push back on it. Or David would say, oh, now I.

D (27:21)

Go, well, that's really cool, but just show me. Eric can tell you the story here. Go ahead, Eric.

C (27:27)

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, you know, it's, it's a game changer. I kind of look at it through the same kind of, 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 30, 60, 90 test. Next is add productive value, not burden. And finally, would David Allen or Eric Mack use this? And so if you're, 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.

B (28:46)

And the other thing is, David, as Eric's going through some of these, if you have any examples, you recall of something.

C (28:54)

Yes, please.

D (28:55)

Okay.

C (28:56)

First 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. So a leak is anytime. In my definition, a leak is anytime I have information that I've parked, that I depend upon that is not brought back to my, 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, 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, there's something happening here that I need to go back and take, take action on.

B (30:46)

And also supports the weekly review habit.

C (30:50)

Absolutely.

B (30:51)

What David calls the critical success factor. If, if, 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. And if you could just at a glance, know which ones need next actions.

C (31:08)

Precisely. 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 to. 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.

D (31:37)

Yeah.

C (31:38)

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. But that behavior. We were always trying to shape your behavior toward the GTD methodology, by the way.

D (32:34)

You know, interesting as you say that, Eric, and I think maybe for anybody listening to this, that can catch the subtlety of this. When I design my ideal system, it would say on your home screen, you would have a little temperature gauge that would tell you how many unprocessed things you had right then, no matter what. And it wasn't good or bad. You said, look, here's how many things you have. Would you like to go process these? And you could click that and then it would bring you back to it. And then, Eric, you built at least a version of that as best you could in that game. Yeah.

C (33:13)

These days I would love. I'd love to have something like a dashboard, almost like what Microsoft Planner does that just says, here's what's going on in my project world, here's what's going on in my activity world, and so on. Let me move on to the next one. So we keep this going. 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 that would repel them from even using the tool. 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, they're, 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 tacked 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, back in the day was we had done that introduction that integration with gyronics 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.

D (36:51)

By the way, have you seen anything like that show up?

C (36:54)

Not really. I've seen, 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. You know, 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. John, any other thoughts on that one before I move on?

B (37:40)

No, no, I think that's good. And now we get to the 30, 60, 90.

C (37:44)

Okay, 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. And in one of my.

D (39:36)

Let me stop you for no, there are Saturday, rainy, cold Saturdays where your inner geek, 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.

C (39:55)

Right. And you don't want to have to think about all those options.

B (39:58)

Yeah, that's what I meant about that.

C (40:01)

I talk about how we dealt with that.

D (40:03)

Right, right.

C (40:04)

So for every proposed new feature, are 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. Now, to me, this, this did not strike me as rocket science, but it proved to be a very pivotal point in what we decided to keep and what we decided to cut away, as it were.

B (40:51)

One comment on that. To me, it seems as though so much of what gets included in software is based not on what the customer needs or what functionality is really required, but what does the sales team, what does the marketing team think needs to be done in order to sell more of it?

C (41:09)

I think there's some of that. I think there's also, you have a lot of brilliant developers who are doing a great job. And just because they can implement some new feature doesn't mean that that feature adds value. I often would say, kind of along with software dogfooding, I would often say that every developer should be locked in a room for six months and forced to use their own software.

B (41:37)

Yeah, I have said about packaging. I was opening a package of cereal this morning and I said, if the owner of this cereal company had to use this packaging, she or he would not allow this product to be sent out in this packaging.

C (41:52)

Precisely. Precisely. Here we are at add productive value, not burden. We talk about, don't burden the user with noise, distractions or decisions, okay? Unless the user wants them or needs them and can opt in or something. And I'll talk about that on the third point number two. Everything must be intentional and seen as such by the user. In other words, what's most important is what the user thinks. 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 that with limited training or instructions, just 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. So 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 eco 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. We really tried to do that as much as we could.

D (44:37)

By the way, Eric, I have to stop you here because you have a great case study where in the German company Unnamed, they implemented Eproductivity as you had designed it without them having to have necessarily any formal GTD training or necessity that they understand this. But just using the software, you know, allowed them to think in appropriate ways that then change the behavior maybe of the company. I know you can speak to that maybe a little bit.

C (45:11)

That was really unexpected. David. 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 the 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. I still was able to get invited back later on 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. And I would attribute that, David, to the feedback I got from you and the butting heads and the challenges in terms of does this feature need to be here? If not, what are we doing for the user?

B (46:27)

It was all very civilized. Eric will talk about butting heads with David, but it wasn't as though they were wrestling in the, in David's office on McNell Road in Ojai. It was a little very civilized, but there was definitely some back and forth about this or this and what to implement.

C (46:44)

David, you were.

D (46:45)

I, I, I, I'm sorry. I needed my system and I couldn't unhook my system and use Eric's system unless I was ready to use Eric's system. Totally right. So, you know, because again, Eric, back to your thing. No leaks. I can't do a partial system either. This has to be the way I do this or not. And if it's not, you know, come on, I'm going to have to then cludge together all my other stuff that happens.

C (47:15)

You know what, David, this is a good time. Before I go into the last slide.

E (47:26)

I'd like to give a short message to those of you who've been participating and playing with GTD Connect for a while and sort of remind you that all of us with this GTD methodology and this set of practices go through cycles. You know, I still go through cycles myself initially. There's, there's kind of the inspiration and there's a lot of material to ingest and to get familiar with. And so people oftentimes when they first come onto Connect, are just potentially overwhelmed by how much information there is. In a way, it's just a huge library where we've been able to archive so much different information from so many different perspectives and people and points of view and so understood that it's like walking into a library going, gee, where do I start? So that's oftentimes the initial phase of this and many people after a year or two, you know, probably get on some level or some plateau where they go, well, I kind of got it now. I've got my system set up and everything's fine and I'm fine tuning and you may find yourself at that point Also finding yourself saying, gee, I'm now becoming a resource of this methodology for people around me, you know, people asking me for assistance and help in this. And we've seen in the forums a number of people now sharing ideas about how to get your teams more involved or families more involved with this information. So some of that information is in there as well. But I think you'll find yourself going through cycles of this, and you may find that much like if you've ever read a software manual. I remember when I learned Microsoft Word to begin with, for instance, and I read the manual, wow, this is really cool. And I started to use the tool and didn't need the manual anymore. As a matter of fact, a good example of that right here, the manual for this camera that's taking this picture right now, initially at. Right, read this, got it all set up. That's really cool. And that's really fine. And so pretty much everything was under cruise control. I didn't need to go back to my library to make this really work. And then, of course, as I started to get more sophisticated in terms of the stuff I wanted to do, got more inspired about some things I saw other people are doing. I go, how do I do that? Went back to the manual. I went, oh, God, I didn't realize I could do that. I didn't realize I could do that. And I remember at least two or three iterations of going back to Microsoft Word back in the. In the days when there actually was a manual for that, as opposed to just all online and realizing, oh, my God, I didn't realize that, oh, I could do that now. I could do that now. And I think that's what you might find with Connect, too, is that it's a gold mine of stuff. Well, many people have read getting things done, you know, more than three or four times, and every time they read it, they get something new out of it. So I think you may find Connect the same way and probably even easier because, hey, it doesn't take much to just click on, surf around, see what might be new or what might be of interest to you, and pay attention. You know, there's more than meets the eye in there.