[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
>what?" message.

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 mailing list