- Forrester Councils
- Councils Overview
- log in
Posted by Tom Grant on July 14, 2008
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:
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.
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »