I say this again below, but I wanted to reiterate that I think this
discussion is really helpful and exactly what we need to do to get to
a solid pitch. You're forcing me to articulate a lot of things I
thought I had articulated, but either hadn't really or did so in the
wrong context. I'm sure I'm not the only one, so please jump into
this thread if you can!
(Aside: I realize that some additional context might be necessary for
my *call to action* above: Why is it important for us to to air out
all of our assumptions? to get on the same page? The reality is, this
is a group effort. We don't have a marketing department to carry out
the will of a single vision by fiat. Instead, we need to rely on
ourselves (this includes our small but active user community!) to see
to it that Chandler succeeds. And just as it was really hard for us
as an organization to design and implement a coherent product until
we defined target users and usage scenarios, we won't be effective at
*selling Chandler* until we can each clearly and authentically pitch
the *same* product.)
See more in-line...
On Dec 21, 2007, at 4:15 PM, Phillip J. Eby wrote:
At 12:26 PM 12/21/2007 -0800, Mimi Yin wrote:
I agree with the sentiment that we need to market Chandler in terms
of what people already 'know' they want or need a solution for. I'm
not sure it should start with calendaring.
Fair enough. It's simply the most obvious and fully-grown pony, as
far as I can tell. :)
Yes, I'm trying to change that perception :)
For one, how do we differentiate ourselves from other web calendar
services? The offline functionality doesn't seem compelling enough on
its own.
Doesn't that depend on who the user is?
Just to clarify, I'm not saying that offline mode isn't incredibly
useful. It's just that in my mind, 'Shared calendaring, now offline
too!' feels like it lacks oomph as a pitch.
Second, I *have* had success demo-ing Chandler to people by pitching
it as something that ties all the bits and pieces of information you
have floating around in your head, Inbox, random text files together:
Personal and shared 'source of truth' manager. I agree that this is a
hard pitch to get right, but I don't think we've given this angle a
fair shot yet. We're only starting to articulate it in the long-hand
form now.
From a marketing perspective, this is a bit backwards. You don't
make a product and then figure out how to sell it, you figure out
what people want to buy and then make it. What specific pain do
people have that they would be motivated enough to spend money (or
at least time/effort/learning) to eliminate, and what emotional
payoff will they receive from eliminating it?
I'm not sure I'm following. The pitch I'm referring to *is* the
problem we originally identified and designed Chandler to solve.
In many ways, the design
we have today is in response to the 'just build a filtered view'
approach to information management.
So what about it is better (as opposed to merely different)?
(Where better is defined in terms of ultimate impact on the person
using it.)
That, was the topic of my first email :) My claim is that if we can
figure out how to orient people so that they approach the product in
the right state of mind (e.g. don't expect it to be a PIM, email
client, traditional project manager)...it's an information / work /
task manager people can actually stick with.
This 'thing' we've had trouble articulating doesn't have to be what
we communicate in the marketing pitch. But I think that to come up
with a compelling pitch, we need to start with a clear understanding
of it. Otherwise, how can we go about helping others to see and
experience it?
We need to start from the other end: who needs this, what is their
pain, and what *emotional* payoff will they get from the solution?
Yes. The pain is: I have too many bits and pieces of information to
keep track of all in my head, but I can't seem to stick with any of
the information-manager-type things I try, be it a paper-based list
system, excel, project managers, task lists, outliners, etc.
The emotional pay-off is relief that I have a *trusted system* where
everything is, it's easy to keep up-to-date, it's shared with others
so that organizing myself = organizing everyone else too, AND it
doesn't feel like a lot of busy-work because it's actually helping me
get work done too, not just helping me keep track of the task
representations of work.
My extremely limited perspective on this is that I see IT guys
whose users are bugging them for a calendar. Their pain is they
don't want to do Exchange, but they want something better than some
random PHP intranet app, especially if they have remote users. The
competition for this niche is low, especially under 25 users.
(E.g., Zimbra sells in blocks of 25 seats, and their marketing is a
little too corporate-speak for smaller groups, anyway.) The
emotional payoff is that they save the day and the budget and look
good for picking the right thing.
Yes, this is a path we could have gone down. But the reality is, we
didn't. Chandler wasn't designed to solve this problem. We partially
solve this problem, but our target has been the thing I tried to
describe in my initial email...It feels wrong to give up on that
problem before we've given it a proper chance.
This is part of our target. But I think we can reach beyond this
audience. People start using tools like OmniOutliner on their own, I
don't see why Chandler can't reach the same kind of users.
To a PIM geek, Chandler isn't even in the same league with
OmniOutliner (or its likely inspiration from the PC, Ecco Pro).
Now, it might be that I'm wrong, and there are non-PIM geeks who
buy things like OmniOutliner. Certainly some of them must be. But
my general impression has been that PIM enthusiasts and other
people with the "productivity" otaku are the primary ones who
already *know* they want a PIM. And Chandler compares less well
within that category, IMO, than it does in the calendar category.
From our user interviews, I believe there is a significant
population of people who spend a lot of time *managing their stuff*,
but they aren't served well by bugzilla-like models for task/project
management because the things they need to deal with aren't really
concrete. They're things that people used to just keep track of in
their head, but the modern workplace is swarming with this kind of
amorphous 'stuff' coming at you from all different directions,
pertaining to a dozen different contexts and it's now impossible to
just rely on your head. In this way, we are trying to address the
same problem as GTD.
As Katie has put it, we have a few different centers of gravity:
"Outlook killer" -- we simply don't stack up
"GTD" -- Chandler's design philosophy directly contradicts that of
GTD on occasion, doesn't accept GTD's premises in other areas, and
doesn't provide any GTD-specific tools that aren't done
significantly better by other PIMs (even ones that aren't
specifically designed for GTD). The only differentiating factor
here is open source+GUI. Note that there are open source GTD tools
based on text-only/command-line operation, which just goes to show
how *much* demand there is for good GTD tools. If we built an
actual, scripturally-correct GTD application, we'd have GTD fans
all over us -- but that would be a non-trivial effort, to say the
least.
The way I think of GTD is that we're solving the same problem GTD
solves for the individual. And then we're also solving the GTD
problem for groups. Additionally, Chandler possesses a different set
of benefits/deficits than the tools David Allen had available to him:
Paper, Palm, Outlook, etc...
As a result, our take on GTD turns out to be substantively different
from GTD methodology as described by David Allen. But the spirit of
GTD is very much in the product.
In other words, in the same way that cars eventually stopped looking
like horse carriages and were better off for it and synthesizers can
do way cooler things than reproduce 'real', analog instruments, we're
solving the same problem as GTD, but with different tools and
materials, so the house we build is just going to look different.
I fully acknowledge however, that trying to shed people of their
expectations around GTD and information managers is really, really
hard. It's probably why my instinct is to avoid pitching Chandler
around GTD and PIMs. But as you point out, that leaves us in the no-
man's land of *products that nobody knows they want or need*.
"small team collaboration" -- this is the only niche we actually
have any competitive oomph in right *now*, but even so we will not
compete without defining a *new* subcategory/niche to be the leader
of. That's primarily a marketing question, and it's primarily
directed *outward*, to the question of what people want, as opposed
to what we have.
Unfortunately, I am not a "real" marketing person, so all this is
perhaps not as clearly elaborated on my part as I would like it to be.
Well, none of us are real marketing people. So we'll need to consult
a real one before drawing any definitive plans for how we pitch the
product. This discussion however is critical to helping us prepare
for that consultation. Maybe we'll get really lucky and end up with a
pitch that's smack on target with the problem we've been trying to
solve all along. We may end up with a pitch out of left-field. We may
end up pitching ourselves as low-maintenance group calendaring.
Regardless of what our pitch is, we still need a crystal clear
picture of what we *actually are* as opposed to *the thing we pitch*,
because there's *compromise for the sake of reaching a goal* and then
there's just going after whatever's available. I think we can
probably all agree on that one.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
