Cut Features; Add Value

By Joy Beatty October 22, 2012

The concept of a “minimum viable product” is commonly used in the startup world to identify the subset of features needed to deploy a usable product and test it in the market. Yet 65 percent of features in software aren’t used (according to a Standish Group survey), and those unused and rarely used features are everywhere you look.

Product managers and business analysts are in the unique position of being able to drastically cut scope to deliver more usable products faster and for less cost. Some use intuition as their primary approach for understanding the minimum set of features that a product should have. This is, however, neither practical nor scalable. Instead, we need an approach to logically cut unneeded features, so that we implement only the features that deliver the most value.

The key to systematically being able to cut product scope, while still delivering a great product, is to link the value the user needs to receive to the actual features in the product. To understand that value, consider what problems the product is solving and what objectives the user has for the product. This will help you derive the most valuable features.

Ease of access to these features (usability) is also vitally important. You can have all the right features, but if users can’t find them or don’t understand how they work, they won’t use them or your product.

You can use a variety of objectives, people, systems and data requirements models to help link the user’s value to features and increase usability.


You can apply a “business objectives model” to understand the user’s desired value. First, make sure you have a grasp of the problem the user needs to solve with the product, then identify what successfully solving that problem would mean for the user—thereby defining an objective for the product. You can then determine whether there is a clear strategy to develop features to meet the objective, or if you should continue to identify relevant lower-level user problems and objectives until you can identify features that can clearly be linked to the objectives.

For example, a team building a new mobile music player for the athletic market should talk to athletes to understand what they need. In Figure 1, notice that the first set of problems and objectives doesn’t tell us very much to help us determine specific features. In fact, we might implement a video screen or a book-reading interface based on the first problem and objective. But when we dig deeper, we might find those features don’t add value for this set of users.Figure 1. An Example Business Objective Model

Remember, we want to cut the features that provide the least value. “Objective chains” help you compare the dollar values to make that determination by comparing the relative order of magnitude value of features. You select the highest-value features, consider their costs and focus the team’s efforts on the biggest return. In our example, if you are developing software for the music player, you could compare features such as continuous play, playlists, sharing songs with friends, import, export and album covers. You can estimate the value of each of these features, considering how many users would likely buy (or not buy) the mobile player based on having the feature or not. If the potential value of the product sales is $10 million and you choose not to build the expected continuous play feature, your sales might drop to zero—therefore you can say that feature is a $10 million feature. Meanwhile, showing album covers on the music player might only be useful to a small subset of the users, so maybe it’s a $10,000 feature

Process Flows

After understanding the features, it’s equally important to think about how the user will experience the functionality step by step. “Process flows” can be created to show this, by thinking about what the user is trying to do (what the initial problem is they are solving) at each step and describing the flow in that manner. The flows should be based on how the user will receive value, not how they access specific functions in the product. If a user just bought the music player, the first step in the flow is to open the box. Then what? The flow should have a very short path to get their old music onto the new device. Keep in mind that different types of users might have different problems to be solved and different expectations, so there might be different process flows for different personas.

It is important to think about product usability, since we not only must implement features that add value for the users, we need to implement them in a way that meets users’ needs so they will adopt the products. You can use the process flows to improve the usability of the product. Consider how many steps a user has to go through to receive the desired value from a feature, and try to reduce those.

In our mobile music example, a user opening the box shouldn’t face a long setup process including settings they won’t use immediately, until finally (and frustratingly) they can at last play music—but they have none loaded. We want them to get to a basic set of functionality right out of the box and worry about other features later.

Requirements Mapping Matrix

The process flows can also be used to identify specific requirements and business rules that are needed to support the in-scope features. And by organizing your requirements by process flow steps in a “requirements mapping matrix” (RMM), you are able to later understand the impact of cutting a feature or changing the user’s flow to access it. An RMM provides “traceablity” and the ability to demonstrate completeness. It is like a traceability matrix, but allows more mappings at once—such as mapping user’s objective to process flow steps to requirements and business rules. Figure 2 shows an example of an RMM.

Figure 2. An Example Requirements Mapping Matrix 

Using an RMM, you can also tie these models and the individual requirements back to the user’s original objectives. As you add requirements, you can verify they contribute to the user’s overall objectives. As you cut requirements, you can ensure that they are safe to cut and that the processes they support can still be executed.

Models to Identify the Minimum Viable Product

There are a few basic requirements models that can be applied easily and immediately to any product development effort. The intent is not to propose that you create a lot of useless requirements documentation. Instead, if you select the right models, you can ensure you cut scope and only work on requirements documentation for the needed features. All the while, you are creating a more successful product that will have only the features the user actually needs—and you will have delivered it for less.

Categories: Requirements
Joy Beatty

Joy Beatty

Joy Beatty is a certified business analysis professional who is vice president of research & development at Seilevel. She has 14 years of business analyst experience. She drives innovation for new business analysis methodologies, such as the RML® (requirements modeling language), and training that improve elicitation, requirements modeling and approaches to centers of excellence. She has applied her expertise as a requirements architect with numerous Fortune 1000 companies, has trained more than 600 business analysts and is currently serving as an International Institute of Business Analysis core team member for BABOK (Business Analysis Body of Knowledge) version 3. She writes about Seilevel methodologies in refereed papers, whitepapers and blogs and has a new book on requirements, Visual Models for Software Requirements (Microsoft Press, 2012).

Looking for the latest in product and data science? Get our articles, webinars and podcasts.