Who is our target user?

For a while now, when anybody has asked, "Who is the target user for Kibble?", the answer has been: Info-centric early adopters.

There's been a lot of discussion as to exactly what constitutes info-centric (see DevelopingPersonas). Now I'm wondering about "early adopters."

Early adopters are users who actively seek out new applications to try. Users who keep abreast of innovation. Users who configure and customize the software they currently use. Users who will play around with something just because it's new and cool, even if it's not particularly useful to them. Users who actually enjoy the process of learning new software. Users who are perhaps more tolerant of UI hiccups because they're more interested in the innovative aspects of new software.

Early adopters are not necessarily engineers.

This is non-controversial until we start trying to do specific feature prioritization and asking ourselves questions like, "If we don't have this feature, will early adopters still use Chandler?".

But, what do we mean by use? Try out? Play around with? Supplement other applications with? Use in parallel with? Completely switch to? I think thus far, we've been imagining "completely switch to" scenarios. However, I'm wondering if that's setting the bar too high for Kibble, even if we're talking about early adopters.

PIMs are too important for even early adopters to fool around with

PIMs are the lifeblood of the modern day information worker. For most people, they are open and used all the time. They are synced and carried around in PDAs. They are accessed via web clients. Early adopter or not, desperate for a new solution or not, it is unlikely that anyone will completely replace their current system with Chandler unless Chandler:

1. Matches or has other solutions for all existing core functionality (aka up to par features)
2. Has a polished UI experience

We already know that Kibble is not going to meet these standards. (ie. Unpolished UI, No real contacts management. No email threads. Really simple rules and filters. Poor IMAP integration.) Perhaps imagining that Kibble will completely replace whatever application or constellation of applications users call their PIM is too ambitious for a pre-1.0 release?

Should we be talking about other scenarios?

• Early adopter supplements current system by using Chandler as a task manager (via Triage workflow)
• Early adopter supplements current system by using it to share emails and tasks with work partner
• Early adopter supplements current system by using the Chandler calendar for calendar sharing (ie. small business)
• Early adopter tries out Chandler and keeps it active and updated with fresh email in addition to their current system. It's not their primary PIM, but periodically, they will take a look at their data through the Chandler lens, learning new features and workflows along the way.

A slightly different way to look at it is to ask, "Where can Kibble patch holes?"

• Early adopter is competely wedded to Eudora, which they have spent 10 years customizing with rules and filters and keyboard shortcuts. However, they have no solution for calendar.
• Early adopter uses Outlook for work stuff (it's all paid for) and Chandler for personal stuff (was just using yahoo mail at home before)

Or perhaps there is a segment of the early adopter community that is starting from a clean slate?

• Early adopter has given up on PIMs in general and has no system to speak of right now, unless you count writing on their hands and the refrigerator door.

Maybe these more modest conversion scenarios that stop short of complete replacement are okay for Kibble? Maybe it's enough for us to simply establish an interested and invested early adopter user base that is eagerly awaiting post-Kibble improvements to Chandler? Maybe mostly, we need to get something out to door to:

• Get user feedback
• Get the community excited and set up to contribute to the project: which is really the way we should think about how we're going to catch up with current PIMs in the realm of traditional PIM functionality?

Do we have a clear picture of success

Maybe these goals, which are very compatible with the idea of a clock-based release schedule, are in conflict with our other goal of wanting Kibble to be good enough to replace someone's PIM?

I think the tension resulting from these conflicting goals coupled with risk and uncertainty from engineering makes it very hard for us to envision success (as David Allen might say). When do we know Kibble is good enough to ship? This in turn makes it hard to prioritize features. For example, should we really be worrying about making it so that non-Chandler users can view shares if Chandler users still can't undo text errors in the notes field?

The fear is that by aiming too high (ie. Kibble is good enough to replace existing PIMs), we'll arrive at the end of the Kibble timeframe with a strange constellation of functionality: some advanced capabilities coupled with a lack of basic features.

Innovation v. Keeping up with the Joneses

If we give up on complete replacement as an adoption scenario for Kibble, we should look back at our original description of an early adopter and revisit our age-old question, "Does our target user care more about innovation or up to par functionality?" with fresh eyes.

Next steps???

Should we re-evaluate previously designated killer features. Perhaps in this new universe, they are not so killer?

• Rules and filters
• Sharing ACLs
• Free / busy
• Robust IMAP reconciliation
• Spellcheck
• ???
• Syncing with other PIMs

Something else to keep in mind...

Whatever we decide, we should remember that while Kibble as a "supplemental solution" may seem like a step back away from our goal of mass adoption, Chandler is expressly designed to overcome the very barriers that allow and encourage people to use PIMs in segments.

Most people using Outlook (especially without Exchange) will use it for years without ever feeling any urge to explore the Taskpad or Calendar areas of the app. In anything, they are loathe to wander away from what is tried and true. Chandler on the hand is designed from the ground up to be an integrated PIM experience.

In other words, maybe it's okay if users start out thinking Kibble isn't robust enough to replace their PIM (ie. It doesn't sync very well. I can't import all of my IMAP folders. I can't see my calendar at work on Outlook, etc.) because once they start using a part of it, they'll inevitably get drawn into using the whole thing.

Comments

ChaoLam: Mimi, I think you make several insightful points.

I agree the goal is not to displace another application, the primary goal is to ensure that Kibble is used on a day-to-day basis (or at least week-to-week) by "early adoptors" in some key workflows. While some early adoptors are people who just generally like to try out new things, I believe another class of early adoptors are people whose pain points are high and are actively seeking a solution to fit their needs. These early adoptors don't need to be a large number for Kibble, but we should provide them with compelling reasons to adopt Chandler that satisfy their immediate pain points.

So, what are the compelling reasons to use Chandler? I can see two high-level categories:

1. Non-consumers and non-consuming contexts. Even though the PIM category has been around for a long time, many people are still uncomfortable or unhappy with existing electronic PIM software or organizers and do not use them.

I think Apple iCal demonstrated that many people can find a simple and basic calendaring application useful in their lives. Perhaps, Kibble can be such a basic calendaring application for Windows or Linux?

As Mitch mentions, there are really no general good (inter)personal task management software on any platform today. Maybe Kibble can be the iCal for task management, offering simple but natural and usable task management uses?

Then, there are many non-consuming contexts that Kibble can tackle. For example, while office calendaring is fairly pervasive especially in the enterprise, there are no general, good calendaring solutions for, say, spousal or social contexts. Certainly, we can improve on Evites? We need to find segments of users where such usage contexts have reached a big enough pain point that they are willing to try Kibble.

2. Overshot consumers Outlook/Exchange is overkill for LPFI and other small organizations. That was one of Mitch's original raison d'etre for initiating Chandler and I think the same reasons still hold. Cost is a huge issue (Are there many lean 15-person organizations that find the $2k + sys admin costs a year prohibitive?). But there's also the issue of usability and customizing a software for smaller organizations: because Exchange is primarily designed for a variety of large enterprises, many of their design choices seem awkward for small organizations. Can Kibble fill this niche?