[Design] What's the 'pony in the product'?

[D John Anderson]

+1

I've been experimenting with just showing people how to set up an  
account, add an event and share it. Even after that amount of  
explanation, they begin loosing interest, but I think this has worked  
better than my prior demos which began with a bunch of background  
concepts

John

On Dec 21, 2007, at 9:01 AM, Sheila Mooney wrote:

> 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