Practice: Product Feature List

Practice Product Feature List

Objective

The objective of this practice is to expand the product vision, through an evolutionary product requirements definition process, into a product feature list (similar to a manufacturing parts explosion list).

Discussion

A product feature list, an expansion and refinement of the one developed in the Envision phase, identifies and documents the features gathered for a product from feasibility or marketing studies, initial requirements-gathering efforts, and/or product visioning. For existing products, customers, developers, product managers, and customer support staff are constantly making suggestions about product enhancements. Part of a product manager's job is to constantly sift through this list and sort it (with customer involvement) into priority order. This list and the accompanying feature cards are the major inputs for release, milestone, and iteration planning.

Feature details evolve over the development phases. In the Envision phase the team creates a preliminary feature or product breakdown structure in which features are identified and structured (as shown in Figure 5.6). In the Speculate phase, the team expands this list, and for each feature creates an index card that contains basic descriptive and estimating information. During the Explore phase, in the specific iteration in which the feature is planned for implementation, the feature requirements are determined in detail, and the feature is built and tested .

There are tremendous differences between developing an automobile, an electronic instrument, a software application, or an airplane, and so the specifics of analyzing and specifying requirements and features vary widely. Some products will require more early requirements specification than others based on the cost of altering designs late in development. Since software is more malleable than nearly any other product, an evolutionary specification process will usually serve it best. However, as mentioned before, even the most sophisticated industrial products are undergoing evolutionary development via the use of simulations and modeling.

The results of the requirements specification process, whatever the engineering discipline involved, should be documented as a hierarchy of product featuresproduct, component, group , and feature. [1] For business software products these categories could be product, business subject area, business activity, and feature (as explained later in this chapter). Small software products might use only the features level, while large industrial products with embedded software may use the entire hierarchy.

[1] Depending on the type of product, this "parts explosion" feature breakdown may be hierarchical, but it might also be nonhierarchical, particularly in the case of software.

For a growing number of computer, instrumentation, and electronic products, a feature hierarchy will include both hardware and software features. Part of the design process will be determining whether low-level features will be implemented in hardware or software. Products that were once considered "hardware" products with rudimentary embedded software now have such a large set of software features that they could be considered software products with supporting hardware. In just a few years , for example, cell phones have progressed from hardware with minimal software to hundreds of thousands of lines of software code that drive (or "support," depending on whether you are a hardware or a software engineer) all aspects of the hardware.

So what is a feature anyway? In general, a feature is defined as a piece of a product that delivers some useful and valuable functionality to a customer. Features for a software product (the ability to check a customer's credit rating) or an airplane (a comfortable seat for the passenger) will be very different, but they both focus on delivering value to the customer. In planning a product, however, some items that need to be delivered may not soundat least to customers or product managersas though they provide direct benefit. An interface component deep in the bowels of an electronic instrument may have minimal interest for an end customer but be a necessary "technology domain" feature.

For project planning and delivery purposes, teams need to include these technology features or components in the feature plan, where they are usually identified separately from customer-oriented features. However the project team decides to include these technical features, there is a danger in building too many technical or infrastructure components before building something that has direct meaning to the customer team. The longer the technical team "stays dark"building techie stuffthe further off track the project can get before receiving feedback from the customer team. Getting off track like this can occur either because of the technical team's emphasis on infrastructure or the customer team's lack of adequate time to spend on the project. In either case, the project manager has to take action, even if it means halting the project until the issue can be resolved.

From the list of potential features, the product team and the engineering team will discuss prioritization and scheduling issues during the assignment of features to development iterations. One characteristic of APM projects is the volatility of the features on this list. For a more sedate project in which the requirements are firmly established in the beginning, this feature list becomes the input for a plan that becomes relatively fixed. In an agile project, the use of the list is much more dynamic. During the planning for each iteration, the list of features to be included in that iteration can change significantly from the original release plan.