The Rise And Fall Of Complexity: Experience Versus Features

[For earlier posts in this series, click here and here.]

Imagine that you're dining at a new Italian restaurant that just opened in your neighborhood. You've heard that the chef is well known and widely respected, so you're expecting a great first experience.

You sit down, and the waiter hands you a menu. Actually, it's not a menu, but a listing of all the top-quality ingredients in the restaurant's refrigerator. Some ingredients suggest the kind of recipes that the chef might prepare: For example, the veal shank might be destined to become Osso Bucco. Since you're not an expert in Italian cuisine, it's hard to guess what kind of recipe might require some of the other ingredients (rabbit, goat, boar, etc.).

The waiter is no help. He'll dutifully return to the kitchen with the ingredients you tell him the chef should prepare, but he won't tell you if that combination will transform into a delicious meal or an indigestible lump. 

In this scenario, chances are slim that you'll get the sort of dining experience you expected. If you were hoping for an experience you've never had before, the kind that a world-class chef could provide, the odds are even worse.

Sadly, this is exactly the way in which technology companies have pitched their products. Rather than explaining the experience you should have, they leave it up to you to figure out what experience might be possible, given the ingredients (features and functions) available in the product. This approach has two pernicious consequences:

  1. Users struggle to find the value in adopting the technology. While developers might think in terms of features, users see the world as a series of experiences. Features create experiences, but it's not immediately obvious to the user what those experiences might be. For instance, B2B software companies assume that the value of mobile versions of their applications is self-evident. But how many accountants can immediately visualize, in their mind's eye, what Get secure access to your financials from anywhere really looks like? If they can't picture it, chances are, the value of doing it won't be visible.
  2. Developers build too many features. If you can't articulate the experience that you're trying to create, it's probably not clear in your own mind. In that case, it's hard to decide which components to include or omit, since any single ingredient might turn out to be essential. Consequently, you load up the recipe with ingredients, when a better dining experience usually depends on the quality of the ingredients, or the ways in which they complement each other.

A vendor that appears to have avoided this trap is Sococo, which provides a cloud-based application for team collaboration. While their tool is certainly applicable to a lot of use cases, Sococo is focusing on Agile development teams as their early adopters, since these teams have an urgent need to collaborate at a fast clip, regardless of geographic or bureaucratic distances. Sococo puts everyone in a virtual office building, in which they can communicate via chat and audio, share applications, and congregate for daily Scrum meetings or more ad hoc conversations.

From that description, Sococo might sound fairly ho-hum. Why not use a web conference tool? Or Second Life?

Sococo answers those questions in terms of the experience they're creating, not the features they're providing. A web conference lets you share applications, but it does not provide a picture of how teams collaborate. If I spend my day with a virtual office building in my field of vision, I might notice that a meeting is happening that might be important to me, based on who's there and what they're sharing with each other – an experience that a web conference tool can't provide.

While web conferencing provides too little functionality to create the intended experience, Second Life provides too much. Three-dimensional avatars of team members and locations is overkill, when simple icons representing users is all people need. (And you really don't need to add bat wings or a Roman centurion costume to your icon.)

During the briefing, we spent a fair amount of time talking about how Sococo's vision of their intended experience cut down the list of planned features. When you're working on a collaboration product with a muddier use case, you can easily invent arguments for adding hundreds of features, when in fact most people will need time to settle into just a few well-selected ones. Adoption of a new technology takes time, both to understand the experience that users might have and to tailor it to their individual preferences. In the first few days of using a tool like Sococo, you'll probably do some modest experimentation before really embracing the tool. In these early moments of adoption, you might not use some of the essential features, such as audio communication. Later, you'll reach out for features like VOIP that you haven't used yet, if they appear to be necessary for the experience that you expect to have with that tool.

Even among the most expert customers, experience is what sells a product, and what should guide its development. Agile development teams certainly qualify as experts on software, since that's what they're building. They usually don't need much more than what a good Wiki, or Open Space, or a tool like Sococo provides. In the same fashion, even the greatest expert on Italian cuisine doesn't want to instruct the chef in what recipes to cook; instead, they want to be wowed by the experience the chef creates.

[By the way, an earlier entry in this series talked about the boundaries of what we mean by the term "application." Colleague Phil Murphy has a great blog post on this subject, which started an interesting conversation in the comments section. I recommend giving that post a look.]