Requirements data: Use cases, not features

[Click these links for the first and second posts in this series.]

There's no way around discussing features. Every release, you're going to add some piece of functionality. You can come up with academic-sounding names, or cute nicknames, but at the end of the day, you're talking about a feature.

However are features the right place to start? If you had to invest your time in documenting what customers want, is it better to describe a use case or a feature? Or, to use other language, should you be writing a story, or a vignette that fits into the larger story?

Increasingly, technology companies are putting more emphasis on stories, a.k.a. use cases. (Yes, I know, many people prefer to keep stories distinct from use cases different. However, for sake of this post, I'm going to blur these differences.) That's a very good thing, but not without its costs.

Looking at the choice between (a) a use case, and (b) a list of features, there's almost no contest between them. Use cases have several immediate advantages:

  • Clear definition of how technology provides value. In other words, use cases make it easier to figure out why someone would want to use a piece of technology in the first place. Or, perhaps more importantly, why not. For example, entering "activity" into a CRM system seems on the surface like a good thing to do--except when it gets in the way of the daily work of a salesperson.
  • Easier decisions about the relative priority of new capabilities. It's easier to answer the question, "What would help our target user more successfully complete this task?" than, "What's more important, a hyperspace shunt or an ion flux regulator?"
  • More meaningful success parameters. Every feature has a few ways you can implement it well, and a thousand ways in which you can implement it badly. You can give someone powerful business intelligence capabilities, but it's not useful to them if they need a Ph.D. in mathematics to use them. Use cases make it easier to figure out what constitutes a successful implementation.
  • Clues to successful adoption. Every technology vendor has an interest in getting people to use their products, even if they don't always pay close attention to adoption. If you think through a use case, you can determine what will get someone excited enough to use your technology. These shiny baubles--coolness factor, sizzle on the steak, call it what you will--are often more important than a profound increase in capability.
  • Fewer steps to product marketing. Product marketing, the fine art of explaining "What will this technology do for you?" becomes way, way easier when the development team has done this work for you already.
  • Inspiration for innovation. Often, when pondering what people unlike yourself (developer, product manager, QA person, product marketer, etc.) will do with a piece of technology can get the innovation juices flowing. Even thought experiments about use cases can unlock new ideas. Einstein didn't start his career as a scientist by saying, "I'm going to overthrow Newtonian physics!" Instead, relativity began with the question, "What would happen if I tried to race a beam of light?"

The big downside to use cases is the time and effort needed to research them. You can think of a feature without ever leaving your desk. Usually, to understand a use case, you're going to have to do some field research. You can be smart about cutting down the amount of research needed, or filling in details as you go. However, the amount of information needed will always be more than if you just sat at a white board and came up with a list of "things our product does not do today that it might do tomorrow."

However, for all the reasons cited above, use cases are more helpful than features, and they're a better starting point for planning, too. Therefore, requirements documents should document use cases, and then propose features that will contribute to them.

Comments

re: Requirements data: Use cases, not features

The use of user stories and use cases has been around for years, yet many companies I have worked with seem to skip this step, or just haven’t done a good job of understanding their customers’ needs. Ensuring there is a collective understanding of customers and their needs throughout the product innovation lifecycle is crucial to bringing successful products to market. In software, for example, it goes beyond the production and should continue into the pricing, packing, and commercialization of that product.I agree completely about the time commitment being a consideration -- it's very difficult to spend enough time with enough customers to understand their collective challenges and look for opportunities to innovate. But that, I think, is where technologies such as web-based communities, idea portals, online surveys, and social networks come into play; they do make it easier for you to listen to your customers and their ideas.I would like to suggest some ways companies can increase the velocity of their innovation process. They can identify where their customers’ conversations are taking place (i.e. their own support sites, or unrelated public forums or blogs). In response, they can build and host their own customer community (e.g. to supplement technical support), or they can use a tool to mine conversations occurring externally. They also need to establish a process for vetting and prioritizing all the data they’ll be collecting. Finally, they mustn’t be shy about communicating results with their customers. Show your customers proof that you’re responding to their needs, and you’ll not only be encouraging more feedback – but creating more loyal customers.