[Design] What's the 'pony in the product'?
D John Anderson
john at osafoundation.org
Fri Dec 21 12:02:05 PST 2007
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
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.
> 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
>> 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*
>> 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
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Design" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design