Re: What's the 'pony in the product'?

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