Mitch and I had a discussion on feature prioritization 8/27/03. Here's a strawman plan on how we should proceed to plan out Canoga and beyond.

• We have mapped out all ChandlerComponents (let ChaoLam know if any component is missing, earlier the better)
• For each component, we want to specify the baseline functionality of the component. The baseline features should be the minimum functionality that is usable by anybody and should be the non-controversial features that are expected in any PIM. This combined set of these features will act as a baseline for Canoga. We should use the relatively light-weight features of Apple's iApps as inspiration for what our baseline features should be.
• For each component, we also want to map out the more "Debatable Features". Such features usually have one or more of the following characteristics:
  1. unsure how useful it is for our core info-centric users
  2. requires too much resources for intended benefits
  3. uncertain payoff (but balanced with our desire to innovate. See cool features below)
  4. requires a lot more design work and iteration i.e. smells like a research project
  • We will then go through each debatable feature for each component, and decide which of the following buckets to categorize each feature:
    1. Canoga 1.0 Feature
    2. Canoga 1.X Feature
    3. Westwood Feature
    4. Pasadena Feature
    5. Blue sky Feature
• For each component, we also list general anticipated usage scenarios for each component. This acts as a sanity check to guide/validate our prioritization.
• An example for this methodology has been started for Contacts, chosen primarily because this is a simple and well-understood component
• For now (9/03), we will use a bottoms-up approach by going through the major components one-by-one, using MitchKapor as our prototypical "target user" to decide on the feature set (but mindful that Mitch shouldn't be our only user :). It is hoped that we can then discern general principles from this approach, which will then allow us to more generally scale up and speed up this plan.
• In addition to this baseline functionality, we want to add a limited set of "cool features" that will pull and excite our core audience. I believe we need to carefully select this list of features so that they are synergistic and reinforce each other (as opposed to a scatter shot approach). They should thus be in areas highlighted in our ProductRoadmapNov2004, primarily in the following components:
  1. Flexible data framework
  2. Extensible Document Architecture allowing for task-centric views
  3. Sharing and Collaboration
  4. Search and filtering

There are some caveats, obstacles and risks to this approach which we should be mindful:

• There are a set of high-level decisions we have yet to make which could change our plans quite dramatically
• There are big holes in Chandler's design, both end-user design and architecture design which could result in plan changes
• Our continual lesser ability to estimate our own productivity and to break down and estimate tasks accurately makes it hard to bucketize features to a timeline
• How well does this work for more "back-end" components?
• Will this process take too long?
• Will this plan ensure the widest adoption of Chandler eventually (we are less concerned about wide adoption for Canoga)?

Next steps:

• Meet with Michael and Mitch on this plan. Get buy-in and/or revise plan accordingly

[done. Got buy-in and revised 15 Sep 2003]

• Create actual FeaturePrioritizationWorkPlan
• Go through more components (e.g. email, calendar)

-- ChaoLam - 05 Sep 2003