It can be a very murky world working on a software product. Calendaring is a great example. Lots of competitors, tough challenges, no interoperability, and many frowny-face emoticons to overcome. When attacking a problem like this, I look for a slicing concept. This is the kind of concept that divides the murky space into oil and vinegar. Once you have your slice, you will have your feature set. What's more, you will have a framework for making decisions about new features. Oil? Vinegar? Can't be both. If it's the Vinegar release then you've got it made, you don't even have to have a meeting about it. The feature's in.
Let's talk about some assumptions about the calendar space, and why it's so hard to prioritize the features. One assumption - which I completely agree with - is the next wave of this technology will be supported by new adopters of the technology. This "new adopters" group - the ones with the sticky notes and the day planners today - will be the ones championing the technology tomorrow. Even more importantly is the converse: if we don't bring on the new adopters as our key champions, as our core base, then any new wave of technology will be short lived, or (worse) unnoticed. These people are the key. That's the first assumption. The next assumption is that you would like to prioritize features that will have the effect of reaching these new adopters. By "reaching" I mean turning them into rabid, drooling evangelists indistinguishable in chat rooms from MVPs. By "reaching" I mean in a religious way. That's the second assumption.
To summarize: we want these folks, and we want them to be thrilled. Let's prioritize the thrilling stuff, shall we?
Without our slicing concept, our task of prioritization is swimming in the murkiness that will sound very familiar. Should we fix time zones? Recurrences? How about developing an industry-wide standard for synching protocols. Can we come up with reminders that actually don't fire on device 2 if you have already dismissed them on device 1? What about publishing and privacy. Already our cute, friendly, and well-meaning calendar application that we wanted people to write sonnets about in their spare time has turned into a journey into the center of the earth. A feature meeting ensues. One person thinks the Gregorian calendar is for weenies. Another wants military time. It's hard to say which of these is more important. Certainly both seem broken. But fixing both will only make sure customers don't feel pain when encountering these edge cases, they won't name their firstborns after the application if you fix them. I'm not saying don't fix them, I'm saying that there is not yet a slicing concept that gives you a solid framework for decision making.
Let's try out a couple of slicing concepts and see how they work. Repeat after me. "The murky world of calendar application development can be clarified by dividing all potential new features into a) competitors have it / don't have it, or b) it's a bug fix / it's an innovation."
A) Competitors. Right now there are lots of big names in the calendar space. Apple. Outlook. Yahoo. MSN. There are web apps like Trumba and EVDB. Chandler is in there somewhere. The matrix will show a certain level of base offerings (such as: ability to enter an event) and then the checkmarks for the matrix start getting a ragged edge when the features get more advanced (such as: invite friends, or sync to device). A new product, or a new release of a product, could decide that this competitive matrix was the driving mechanism behind the feature set. For this new product, every box below the deep water mark must be filled in. If the other guys have it, we need it too. The trouble is, this type of reactionary product design will get you more bugs, more features to support, and a diluted fan base who doesn't know if you're a business or consumer app. (And no, the answer isn't "we're both business and consumer!") So, competitive matrix fails as a useful slicing concept.
B) Bug fix or Innovation. This one is pretty tempting. You line up the world of calendaring and take an honest look at what parts are broken. Yes, recurrence is buggy. So are time zones. Inviting people outside of your walled garden has its flaws. For a whole set of features like this, which have become standard calendar fare, the polish has not gone into them because the consumer demand is not there to fix this. How many iCal invites have I received via e-mail that I have been unable to import into my web calendar? Yes, the problems are hard, but the real reason why they haven't been fixed is a chicken and egg problem. There is not a clamoring of demand for these features, because - get this - the people using these features are not running households. Households are still run on sticky notes. Even in the workplace, above a certain level an executive will get an admin to run their calendar. The data in the calendar files themselves is stale and painstakingly entered if it gets there at all. So fixing bugs, while admirable, does not slice up this murky space in a useful direction. What you would have is a bug-fix release that would benefit a few.
Now, Innovation (this is still part of slicing mechanism B), is an interesting way to look at the feature set. It's a simple question, does it innovate beyond the current expected baseline for a calendar application? A product doing an "innovation" release would have perhaps thin coverage on the competitive matrix, and thin coverage on bug fixes, but a big spike in depth on one or two innovations. Some example innovations: Layering of calendars. Sharing and publishing. Integration with location awareness.
But let's back up a bit. How do we know which innovation to choose? After all, if people are going to laugh at us anyway for not fixing time zones this time around AGAIN, what can we possibly give them that will be such a WOW that this won't matter? And the head scratching continues. For while we would all like to innovate, the real motivation behind using the bug fix / innovation slicing concept to drive your feature set is to not have people (like Walt Mossberg) laugh at you. again. And to be honest, that's no way to get dressed in the morning.
So thus far we've had a couple of slicing concepts fall flat. When push came to shove, we were unable to use them to generate the feature set for our new calendar application. We could choose one, or combine a couple, or do a focus group. Those at least seem like rational acts. But, getting the new adopters to fall in love with our application will not be a rational act. We will have to romance them, by giving them everything they want and more, and eliminating all barriers to adoption. Not only will this be painless, it will be a thrill. It's just a small step to love from that point.
I present to you, the slicing concept useful for prioritizing the feature set of a new calendar application: Will it reach the new adopters?
Let me elucidate more on who the new adopters are. These are folks right now not using digital calendars. They live on sticky notes on the fridge, dayplanners, or printouts from their admin. The problem isn't that they don't use calendars, or don't use OUR calendar. The problem is that the information is not digital. This is where all the other slicing mechanisms fall flat. What does it matter if the time zone converts backwards to the wrong day, if the information isn't digital in the first place? What does it matter if it can be published, or synced, or burned onto a gold LP record and sent to Alpha Centauri if it isn't digital in the first place? The digitization process is just too hard. This is the pain point that the next killer calendar application will eliminate. Data entry at the computer. Data entry at the telephone pole, looking at the poster. Data entry at school or in the car. Data entry at point of use, which is the point where the event is actually discovered (or, likely, discovered to be changed). Once the data is digital, the other features start to matter.
Another reason why the clamoring hasn't happened, the throngs of people demanding us to fix recurring once and for all for example, is that customers have not been given the candy. Some pain with data entry might even be acceptable if users understood that they would be soon treated to something new. This is where innovations such as publishing a calendar fall short of the dreams people have for their time. The real use for calendaring is to make room for success. To align your activities to make success inevitable. To solve problems. To become a better person. To give friends, family, and important events their just planning and respect. This is power.
I think the candy that users are missing, the candy that would make all the data entry and smart-synch worth it, would be an advanced visualization tool that would allow analysis and problem solving from a time perspective. A new adopter would be able to say "I had no idea how much time I was spending doing XYZ every day. Now that I have this (new feature), I am able to get my MBA and stay married. Thank you, (new product)!" Corny, but think about what quicken did to broaden the horizons of people's finances. There's e-mail and communication, arguably a way to visualize communication asynchronously. Calendar visualizations could really take off in an empowering way.
My point is not that this specific feature needs to be written, but that calendar applications need to get out of their murky space, where it is impossible to prioritize one feature above another. They need a great slicing concept, and the current ones are failing. It is not working to achieve parity with the competition, or to fix a certain number of bugs, or to ship a certain type of innovation that should have been shipped years ago. Although that's a start. Really, the focus needs to be on these new adopters: digitizing information, and rewarding them once it is there. Take away the pain, and hand out the candy. A release like that would make it super easy to determine which features should make it in, and which are better solved over time.
