Re: What's the 'pony in the product'?

"Phillip J. Eby" <[email protected]> Wed, 19 Dec 2007 13:31:41 -0500
Newsgroups gmane.org.osaf.design
Message-ID <[email protected]>
At 02:53 PM 12/18/2007 -0800, Mimi Yin wrote:
>I - THE PROBLEM WITH TASK MANAGERS TODAY: STRUCTURE GETS IN THE WAY
>
>To wrap their head around what they have to do, people always start 
>out by making a list/outline of all their projects and all their 
>tasks. This 'structure it in order to get a grip on it' approach to 
>task management has its deficits:
>
>1. The structure itself locks out possibilities that don't fit into 
>that structure. Have something random you need to follow up on that 
>doesn't fit into your structure? Doesn't get written down. That's 
>trivial, petty, you think to yourself. Besides, I don't know where 
>I'd put it in this outline. I'll just keep track of it in my head.
>
>2. As soon as new information comes to light, your outline gets out 
>of date as you struggle to fit today's information into yesterday's list.
>
>3. Lists and outlines don't allow you to focus on *just the stuff 
>you need to attend to NOW*. Instead you see everything that's 
>not-done, and a lot of it is stuff you're only hypothesizing you'll need to do.
>
>4. Lists and outlines don't scale to hold and keep track of the 
>disconnected ideas and thoughts you have that eventually coalesce 
>into the 'work' you need to do. So even if you have a way to manage 
>your *tasks* (aka *list of stuff you need to do*), you still have 
>nowhere to store and manage all the stuff that constitutes the 
>*substance* of those tasks. In that sense, task management seems 
>like a lot of 'meta-work', busywork that doesn't actually help you 
>manage the work you're actually doing.
>
>5. Lists and outlines presume that you do things in a given order. 
>First I will do this, then I will do that. In reality, we noodle on 
>lots of things, all the time, at the *same* time. Coming up with 
>ideas and questions, remembering one more thing to add to that list, 
>spouting fully formed introductory paragraphs to the dreaded 
>year-end summary, scheduling a meeting, coming up with an agenda for 
>that meeting, writing meeting notes for last week's meeting...

My initial reaction to this list is that these things are at best 
only relevant to paper-based organizing, and even there only to *ad 
hoc* paper-based systems, because all of the formal paper-based 
systems I know of (such as GTD, OPA (or whatever Tony Robbins is 
calling it this year), and Franklin-Covey) do not have these 
defects.  I'm also not aware of any PIMs of consequence in the past 
decade or two that don't have ways of doing the same things.  And 
quite a few modern PIMs support having a structured outline *and* a 
to-do list filtered by context+time.

Now, it's not necessarily the case that this would remove the above 
from being part of the marketing picture.  It's not necessary that a 
tool be the first to implement an innovation, it just has to be first 
to *tell the story* to the given customer.

But it seems like there would be a fairly narrow number of people who 
would not know about any paper *or* electronic organizational 
systems, and they are far less likely to be early adopters of a new 
tool.  They would have to be *sold* on Chandler by someone else, 
because there is little chance of them hearing about it.  (If they've 
managed not to hear of GTD or Franklin-Covey, *and* haven't been 
exposed to any PIM's, the odds of them accidentally hearing about 
Chandler seem fairly slim).

To market to the early adopters who would promote Chandler to those 
people by word of mouth, we need to either: 1) emphasize the positive 
*differences* between Chandler and other PIMs, or 2) successfully 
position Chandler as the leader of its own, *new* category.

And I think that the latter approach has a better chance of 
succeeding, because Chandler doesn't do that well as a pure PIM, when 
compared to PIMs that were written 10-15 years ago, from both a 
features and ease-of-use standpoint.

One category that Chandler could define and *own* right now would be 
"lightweight team+personal calendar".  We could in fact strip some 
features *out* of Chandler, and *still* lead this category.  In fact, 
it could be a *plus* to strip any features that detract from leading 
that category or confuse the mission/position in our minds or the 
customers'.  Simplifying the terminology and stripping out any 
too-"innovative" concepts that require users to think or read a 
manual, would be a big plus.  Meanwhile, most of the other features 
you mentioned in your email (cross-platform, connectivity, email, 
etc.) can all be positioned in terms of how they support the 
"lightweight team+personal calendar" mission -- and nothing else.

This would let us define a niche that Chandler could *dominate* -- 
and product that defines the niche can *own* the niche.  (It's 
actually a lot easier to get a lot of users if you can more precisely 
identify the users in question.)

By comparison, the "PIM" category in some sense no longer exists; as 
commercial products, there are only niche PIMs now.  Contact managers 
for salespeople, calendars for enterprises, bug and issue trackers, 
team project trackers, GTD-specific and quasi-GTD PIMs...  these are 
all things that used to be done by programs in the "PIM" category, 
which was too general for the market.  The things that used to be 
PIMs have now become a niche that might be called "customizable PIMs" 
or "power-user PIMs".

And Chandler isn't a viable competitor (IMO) in any of those 
niches.  It doesn't do contacts, it doesn't do Exchange, it doesn't 
do bug tracking or project tracking, it's opposed to GTD philosophy 
in some key ways (i.e., the whole idea of GTD is to *process* your 
"stuff", not to keep it as "stuff" indefinitely), and it's not a very 
customizable power-user PIM.

While other PIM's have had comparable team support (e.g. Ecco), they 
are not positioned at the "lightweight team+personal calendar" 
niche.  And a more narrowly-focused application has the positional 
advantage that people will prefer something that *only* does what 
they need, on the assumption that a specialist will be better within 
its niche, than a more general-purpose tool will.  (i.e. they'd 
rather use a chisel than abuse a screwdriver, if both are available.)

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design