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

I think Phillip makes some great points, particularly about  
simplifying the positioning statement and removing some stuff from  
the marketing message. I worry that we are trying too hard to put too  
much information into the initial description. Maybe I am saying that  
I don't think the "pony" has to be in the tagline or elevator pitch  
for instance. I know there is hesitation to call the product a  
Calendar because it does MORE than that but in the end it might make  
it easier to present the other unique features in a compelling way.  
We can leave all the details for the "why should I care?" or "so  
what?" message.

Recently, I demo'd the product for a couple of friends. Despite all  
the work we did with branding and preview I still really struggled to  
describe the product to others in a concise way. I seemed to babble  
on. As soon as I start going into the bits about triage, getting  
stuff out of your head, edit/update etc, people eyes start to glaze  
over. It seems to be either too much detail or I haven't found a  
compelling way to communicate this. Any reference to PIMs or Task  
Managers just gets me into trouble ie: contacts etc.

Personally, when I demo to others, I find I go into way too much  
detail. I wish I had a slick 2 minute demo I could just put in front  
of people. If someone walks by my desk, I really need to be able to  
show the top 5 things and leave them with an impression.

Sheila

On Dec 19, 2007, at 10:31 AM, Phillip J. Eby wrote:

> 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

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

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