4. Too many to do list applications. As a Web Worker
Daily writer, of course I’m interested in to do lists and applications implementing them. But just because you can build one with whatever web framework you’re trying to learn doesn’t mean you should release it as a beta and expect me to write about it.

...

8. Getting Things Done. The productivity virus so many of us have been infected with in 2006 and 2007. Let’s move on. Getting lots of stuff done is not the way to achieve something important. You could be so busy planning next actions that you miss out on what your real contribution should be.

Ken Camp chimes in:

It’s the weekend. I’m quite focused on getting little or nothing done. And finding a different sort of appreciation for tools like Twitter that allow my to note what friends, colleagues, and strangers are doing
in passing. Send a little chirp of input if I like, yet still step back and recharge batteries, and in what would be an anathema to David Allen acolytes everywhere - get nothing done.

Stephanie Booth pushes back:

To me, GTD is “a solution to finally be able to enjoy free time without feeling bogged down by a constant feeling of guilt over everything I should already have done.”

Maybe not everyone has issues doing things. If you don’t have trouble getting stuff out of the way, then throw GTD out of the window and continue enjoying life. You don’t need it.

But for many people, procrastination, administrivia piling up, not-enough-time-for-stuff-I-enjoy-doing and commitments you know you’re not going to be able to honour are a reality, and a reality that is a source of stress.

To me, it seems like blogging is getting done on the topic, but the real topic is being missed by all. (Either that or we're all debating over the nature of an elephant.)

The real issue, I feel, is what Peter F. Drucker put so well:

Efficiency is doing things right; effectiveness is doing the right things.

These eleven words are part of premise of Franklin-Covey, the gold standard when it comes to productivity management systems.

--And no, it's not "time management": you can't manage time, it happens no matter what you do; all you can do is manage what you do with the time.

"Getting Things Done" suffers from an inept title -- and I confess haven't allocated much of my own attention towards trying to figure out its merits or lack thereof -- so I'll leave off on further commentary there.

But Franklin-Covey suffers even more by keeping their system paper-based, with the only (proprietary) software available able to run only on Windows machines or on hard-coded Palms or in a new online system where even a demo is hidden behind required registration. (Hint to Franklin-Covey: Establish value before picking our privacy pockets.) On the other hand, Kinkless has made "Getting Things Done" relevant for people who live and work primarily on computers (but not me, as it does strike me as rather focused on the doing rather than the what-to-do).

Meanwhile, on my office shelf sits my Franklin-Covey planner in its gorgeous red leather cover, rarely used because when it comes to something dynamic like planning, turning away from the computer to a paper notebook seems neither efficient nor effective.

As someone who spent a lot of her career being the cutting-edge, push the mass market troublemaker, having a job being the one who says No, is an interesting experience--but it is also incredibly cool.

Working with a team of smart people who are passionate about the customer experience, the product AND the business objectives is tremendously fun--and sometimes, completely harrowing.

I've learned that No can cover a myriad of things:

* We're not going to do this right now.

* We won't do this ever, not on my watch.

* This isn't ready to be executed.

* You need to think this through more.

* What are you, nuts?

* Oh geeze, I wish we could do this..but we're not going to, not now.

While what Susan says is aimed more at internal R&D projects, Boris notes the same can be true for client work:

Many web projects, the "launch" of a site is just the beginning. *Maybe* the functionality and content are done, on simpler sites, but now it's time to start marketing and promoting the site. In most other cases, there a bunch of items that fall into a staged launch schedule (say "no" for launch and plan it for a later rollout) or in a big "future features" bucket (say "no" to it at first, and dump it in the future features bucket) which can be revisited over time. And of course, feedback from the users of any website should be taken into account when looking at these lists.

Boris says that in general he's "too nice." I can relate. After 15 years of professional work replete with enough of those hard lessons that I really should know better, I still try maybe a bit too hard to be agreeable to client requests for changes.

In comments on Boris' post, Khalid writes:

It starts with "can you add X?" and you say yes. Then "oh, and it would be nice to have Y too!", and you again say yes. Then "we cannot launch without Z! It is a must!", ad nauseum ...

Not only does this burden you, the site builder, but it takes valuable time and effort from basic features, and can delay the launch.

So, saying "No" is a way to prevent this scope creep.

There is always phase 2 ...

Indeed.

Part of this tension arises from the fact that, in the end, we want the project to conform to the client 's desires. After all, it's not our website (or DVD or video), it's the client's, and when the client wants something, the first instinct is to say "okay." And yet, and yet ... when budgets are bumped up and timetables pushed back, quite often nobody is happy. (And it can be especially problematic when you're the developer and you have other projects scheduled and limited resources to apply to them all.)

It goes back to the post to which Susan refers, by Fred Wilson:

There's always the desire to please the customers. But knowing what you are going to do and focusing on it is so critical. Saying yes might seem like no big deal. It's only a few lines of code, right? Wrong. It's never just a few lines of code. So say no as often as you can. It's counter intuitive to the entrepreneur mindset, but it's critical.

I can't say I agree with any categorical rules like this, but I can understand the root of such sentiments. I often find myself stuck between wanting to accommodate the client now vs. wanting to keep the often-complex project on track.

Susan writes:

Yep, I say No a lot more than I used to--but it makes it feel so good when I get to say yes.

I wish I could relish saying "no" as much as Susan does.

[Apologies to Kenny Rogers for the title]