There's been a lot of concern about the difficulty of incrementally shipping Chandler because of it's tightly integrated information architecture. Our efforts to break down silos and integrate traditionally separate data types into a single, flexible pool of information users can slice and dice on their own terms traditional "application" or "feature set" based increments of Chandler don't make sense.

Recently we've played with the idea of "turning off" or disabling all parts of the app except for Calendar in an effort to safeguard users from the "unfinished" portions of the application (ie. summary table view) and allow the development to zero in on polishing a focused "subset" of the UI.

However, a slightly different way of looking at the problem is that the "integrated" nature of the PIM can help spur adoption in a way that traditional silo-ed applications have found it hard to do.

Many users of Outlook and Entourage only use the email client portion of the application. The tighter integration of calendar event invitations and email has increased calendar usage, however most users till don't ever venture into the Notes, Journal or Task management parts of the application.

In Chandler however, it is so easy for users to start using the "other parts of the app" so-to-speak (ie. stamping, orthogonal sidebar), that it's very likely that users who intend on using Chandler "just for calendar" or "just for email" will find themselves stamping things as tasks and putting email invitations onto the calendar and vice versa, sending out tasks and events.