[Design] What's the 'pony in the product'?
Phillip J. Eby
pje at telecommunity.com
Fri Dec 21 10:15:28 PST 2007
At 09:01 AM 12/21/2007 -0800, 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
Right, it's much easier to present the rest in the context of *why*
it's such a great calendar. :) That is, it's a great calendar
*because* it has the other features.
A wise person once said that good marketing is the act of "letting
people know about something they *already* want". People already
want group calendaring solutions, and they already know their choices
are mostly not very good. And Chandler has a nice combination of
advantages in that space: standards-based interop,
offline/online/web, overlay calendars from multiple sources, email.
Once you have people's attention with that, *then* they may care
about the rest. Before that, the rest is stuff they don't *know*
they already want, which is why it takes so much effort to get that
message across as the first thing.
>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.
I think the highlights would probably be things like:
* Download some calendars
* Change something, add an event, etc.
* Sync it to the hub
* Go to the hub and view it in a web browser ("your friends don't
even need to have the program, you can view this from anywhere, etc.")
And for maximum clarity/impact, it would help if there was a visible
indication that a sync was required, so you can see "why" you need to
hit sync ("see, here it shows that there is stuff waiting to upload,
so we just hit this and look... there it goes, now when my
friends/team sync they will see there was a change.").
And of course we should make a screencast of this, blog it, PR it,
etc... at least, after we review what parts of the walkthrough are
awkward to do or explain, and make the necessary changes to
terminology or interface.
We could later do additional screencasts for triage, edit/update, and
so forth, each being only a few minutes, but the calendar demo will
be the key seller, I think. Our edit/update capability right now is
way too primitive, and triage isn't different enough from what other
PIMs can do to be a big seller. In particular, it won't impress
early adopters and PIM geeks ("I can do that with a filter,
duh"). Calendar sharing (with mention of standards compliance and
the ability to have plugins) will be more impressive, and the
simplicity of the app will be a win for people who have to support
this. (Not to mention the open source part.)
In other words, the most likely way a workgroup will end up using
this is if their IT guy or resident techie sees that it gets the
calendaring job done and won't be hard to teach/support their
users. So the audience for this demo is actually those people who
would do the recommending. Thus, the commentary would need to
briefly mention things here and there about the SSL security, hub
account management, etc.
We are not *quite* ready to make and spread these demos, of course,
but I think we could define Chandler 1.0 (Desktop and Server) as
being whatever is needed to make these short demos shine under the
watchful scrutiny of an alpha geek who's looking for holes.
(To clarify, holes would be anything our hypothetical IT person would
spot as a monkeywrench in their installing the software for users,
from how installation is done, to security issues, to unsupported use
cases within the target usage area, to difficulty teaching/explaining
the software to their users.)
More information about the Design