[Design] What's the 'pony in the product'?

Phillip J. Eby pje at telecommunity.com
Wed Dec 26 10:20:07 PST 2007


At 08:27 AM 12/26/2007 -0800, Mimi Yin wrote:
>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 :)

And I'm pointing out that it's not *my* perception you'll need to change.  :)


>>>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.

Actually, it's open source shared calendaring for small groups with 
web interop and offline.  No, it doesn't have much oomph, but the 
oomph it has is far more *communicable*, because it's easier to go 
viral.  A person can relay that message to their friends, but the 
"GTD alternative" message is difficult to communicate, even for 
you!  The average person won't have much of a chance.


>I'm not sure I'm following. The pitch I'm referring to *is* the
>problem we originally identified and designed Chandler to solve.

I understand that.  The problem with that pitch is that it's a new 
entry into an old and fragmented category (PIM), which inherently 
means that the competition is based on a "value" proposition, i.e. 
lower price and/or better features.  And in the PIM category, we 
mostly lose on features without being any better on price than some 
alternatives with more features.

If you want to go after a PIM-ish market, we will have to define a 
*new* category in which we are the leader.  But the approach you're 
proposing is that we compete (philosophically) with David Allen and 
by extension, every tool that says "we do GTD".

And if we do that, we will lose in the marketplace, because the 
product will not be perceived or believed as being superior, even if 
it really were.  (And I don't believe it is, for reasons I'll go into 
later below.)


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

That can be done, but it costs a LOT of time and money.


>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.

So now you're saying "lightweight PIM", essentially, unless you want 
to put some proof behind the "can actually stick with" part to create a USP.

If "can actually stick with" is the USP, then we'll need story/evidence as to:

* why people don't stick with other PIMs
* how Chandler avoids this problem
* examples of people who didn't stick with other PIMs, but did with Chandler

Of course, to do this, we need to define what "sticking" means - 
using it for a month? three months? a year? - and collect some evidence.

I'm not saying this to discourage the idea - if we could *prove* that 
USP, it'd be fantastic because it *would* be a new category.  But 
it's not enough to *say* it's a PIM people can stick with, we have to 
have some explanation and evidence to back that up.


>>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.

Again, if the USP is going to be that you'll stick with Chandler, 
we'll need a compelling reason to *believe* that.  Otherwise, from 
the listener's perspective, it's just standard marketing fluff.  Why 
will they stick with Chandler, if they didn't stick with those other tools?

I think you'll find that what actually gets people to stick with an 
approach is the *religion*, not the tool.  Which is why, if we're not 
targeting features to attract members of "established" religions 
(such as GTD and F-C), we will likely have to create our *own* 
religion.  (Meaning someone will have to write our scriptures and 
preach our gospels, thereby adding more work to the process.)

Now contrast starting our own, to leveraging partnership with the 
existing "churches".  A free GTD or F-C tool increases the value (via 
the law of complements) of GTD training or F-C training -- the bread 
and butter of those "churches".  This means that we could get those 
organizations to promote Chandler at essentially no cost to us, with 
a host of other benefits accruing.  (That is, they would have 
financial motivation to collaborate with us.)

In contrast, creating our own religion means we have to do all that 
stuff ourselves, or convince other people to.


>The emotional pay-off is relief that I have a *trusted system* where
>everything is, it's easy to keep up-to-date,

How is this different from me writing everything on 3x5 cards and 
putting them in a card box?  That's also a "trusted system where 
everything is", and is "easy to keep up-to-date".


>it's shared with others
>so that organizing myself = organizing everyone else too,

Really?  How does putting *your* tasks into the system "organize" anyone else?


>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.

What work?  Sending emails?


>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.

To be honest, I don't think we've solved that problem, or even 
adequately defined it.  But even if we had, that's an orthogonal 
problem to communicating or selling the solution.

To communicate, we have to have a message that gets people's 
attention -- specifically, the people in the target audience, which 
can't be defined as "everyone", because a message to everyone is a 
message no-one specifically wants to hear.  (Spam, in other words.)

To cut through the fog, it's necessary to have either a sufficiently 
well-specified group that the target audience identifies with (e.g. 
left-handed firemen), or a sufficiently clear benefit/USP that the 
target audience will say, "yes, I want that" (e.g. pizza in 30 
minutes or it's free).

So if we're not niching by identity, we need a USP, which has to be 
concrete.  For example, if we're going for, "the PIM you'll actually 
use", we'll need to be specific about what that means and offer proof.


> 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.

Except we are not actually *addressing* that problem, because 
Chandler actively *discourages* turning "stuff" into action.  This is 
the place where it diametrically opposes the GTD philosophy, which 
states that the only way to actually get things done is to convert 
your "stuff" into actions that are concrete.

It's almost like saying, "Chandler: the NEW way to avoid actually 
managing your work!"  :)

Now, I don't know what you mean by "bugzilla-like", but I sure as 
heck don't like bugzilla and wouldn't use it as a model for anything, 
let alone group task management.  In my last position, I designed and 
implemented a "viral" group task manager that successfully took over 
a 2400-person company, even in the face of management opposition, 
displacing various purchased solutions whose costs ranged from 
$100,000 up to $10,000,000.  (These systems could probably be 
described as Bugzilla-like, in the sense that they were also 
abominations against humanity that should be cast into the nearest 
lake of fire.)

So I know a little bit about group collaboration -- large as well as 
small.  Enough to know, anyway, that the success of a system will be 
determined by what things it makes easy and what things it makes 
hard.  What it shows you, and how many steps it takes to see or do 
something, will determine what people will actually do.

And based on that experience, my hypothesis is that people using 
Chandler will not do anything significantly different from what they 
already do (or don't), nor anything significantly different from what 
they would do if they were using a paper calendar and a to-do 
list.  Because Chandler provides no cognitive support for doing anything else.

In other words, it doesn't make it any easier for you to turn "stuff" 
into action, than to just keep putting off your "stuff", the same way 
you already do.


>The way I think of GTD is  that we're solving the same problem GTD
>solves for the individual.

I'm sorry, I don't know any nice way to put this.  The only way I can 
conceive of someone making this statement about Chandler is if they 
have completely missed the point of GTD.  Because Chandler totally 
*ignores* the single biggest problem GTD sets out to solve: the 
ill-defined (and therefore non-actionable) nature of work.

GTD solves this by defining a system of workflow whose purpose is to 
*eradicate* "stuff" -- not keep it around!


>  And then we're also solving the GTD
>problem for groups.

No more than for individuals, which is not at all.


>Additionally, Chandler possesses a different set
>of benefits/deficits than the tools David Allen had available to him:
>Paper, Palm, Outlook, etc...

Actually, the only benefits/deficits that are relevant to any of the 
"established" religions are those of the human brain.  The only 
things that the tools do, is change how easy it is to implement the 
intended workarounds for brain shortcomings.

F-C emphasizes workarounds for strategy-level shortcomings of the 
brain, while GTD emphasizes workarounds for tactical 
shortcomings.  OPA/RPM is somewhere in the middle.

None of these religions have anything to do with the specific tools 
used to *implement* them; all have changed and refined their tools 
over the years, while remaining largely invariant in terms of the 
cognitive shortcomings they're designed to work around.


>As a result, our take on GTD turns out to be substantively different
>from GTD methodology as described by David Allen.

Definitely!


>But the spirit of
>GTD is very much in the product.

Then one of us has a deeply profound misunderstanding about either 
GTD or Chandler, or both, because as far as I can tell, what you've 
said (and what Chandler does) is diametrically opposed to GTD.


>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.

[silent sound of jaw dropping]

I think you have this backwards: Chandler is actually the horse 
carriage in this analogy.


>I fully acknowledge however, that trying to shed people of their
>expectations around GTD and information managers is really, really
>hard.

It's even harder if you don't understand what GTD is or why people 
actually like it.  Of course, I'm not saying that every GTD user 
actually understands GTD, either!  But GTD fans aren't going to pick 
a tool that doesn't at least superficially mimic the totems of GTD, 
cargo-cult style.

If you want to sell *against* GTD, then you need to have an appealing 
alternative philosophy.  For example, LifeBalance claims that their 
approach improves on GTD by organizing your priorities and balancing 
the amount of time you spend on different things.  Whether this is 
true or not, it at least *sounds* like it would be an improvement, 
because it offers a believable explanation, backed by the product features.

At the same time, LifeBalance at least offers a strong implementation 
of GTD-style contexts, and thus attracts GTD fans.  (It also has good 
support for projects in an almost-but-not-quite-GTD way.)

My point isn't that LifeBalance is "better" than Chandler or GTD, 
just that it is designed in a way that lets it *sell* to people 
interested in GTD -- or Franklin-Covey, for that matter.

Why?  Because it focuses on automating the *tedious* parts of using a 
personal organization system like GTD or F-C.  In contrast, the only 
part of Chandler that helps reduce an individual's tedium in applying 
a personal organization system, is that you can use collections for 
contexts.  And even then, it's only a time saver over paper when the 
action needs to live in *multiple* contexts.  (Since on paper I can 
just write the action down on the right 3x5 card to start with.)

I'm not aware, right off, of any other way in which Chandler is an 
improvement over paper, for an individual who's trying to apply GTD, 
F-C, RPM/OPA, or any other time/life management "philosophy" I've 
encountered.  (Or at least, an improvement that isn't also provided 
by a significant number of other PIMs, and is thus reduced to a 
required bullet point, from a marketing perspective.)

In contrast, successful PIMs nearly *always* offer at least one 
"killer" feature that actually uses the computer to do something that 
would be woefully impractical if you used paper.  That is, they offer 
"car" features instead of just "horseless carriage" 
features.  Chandler's few "car" features (recurrence, timezones, date 
parsing, and putting the same item on multiple lists) are just 
keeping up with the competition, not putting it ahead.  (That is, 
they are all features found in last year's "car" models.)


>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*.

Yep.  We are in agreement about that at least, although we differ as to why.


>We may end up pitching ourselves as low-maintenance group calendaring.

I like that turn of phrase, it's a good addition.  "Low maintenance" 
sums up the benefits for the IT/sysadmin audience that would be most 
able/likely to viralize the message.


>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.

Actually, the big tension I see here is between "what we are" and 
"what we'd like to be" or "what we set out to be".

Compared to that, the tension between "what we are" and "what we 
pitch" is quite small, I think.



More information about the Design mailing list