The Feature Matrix

By Evan Miller

October 20, 2012

What makes for great software? Software should have useful features, yes, while remaining usable, ideally. That much is trite. But how big should an app be? How many features should it have, exactly? When does the raw number of features start to hinder the user's productivity?

When I design a piece of software, I start out by doing the obvious thing: sitting down and making a list of features I think it should have.

But in my mind, great software is not defined by its feature list so much as its feature matrix.

Software starts to become really useful not just when it hits a certain number of features, but when there gets to be a dense web of connections between features, that is, when each feature complements other features in the program.

I like to think of features being arranged as a matrix, with a row for each feature, as well as a column for each feature. Conceptually the matrix is like a distance matrix found in the back of old road atlases.

If two features interact, you put a check in the cell that links them. If two features don't interact, you leave that cell empty. Each check essentially represents a use-case for the software, for example, “Import from Format 1 and export to Format 2,” or “Create X and run it through Z.”

A great piece of software will have a dense feature matrix; that is, most features will interact somehow with most other features, and you'll see a lot of check marks in the matrix. A dense feature matrix looks like this:

  Feature A Feature B Feature C Feature D
Feature A
Feature B
Feature C
Feature D

Bad software has a sparse feature matrix; that is, most features are dead-ends, and you'll see a lot of white space. A sparse feature matrix looks like this:

  Feature A Feature B Feature C Feature D
Feature A      
Feature B      
Feature C      
Feature D      

So when you are trying to decide whether to add a feature to a program, ask yourself: does this new feature interact with and increase the value of existing features? That is, will this addition make the program's feature matrix more dense, or more sparse?

You know it's time to split a piece of software into two pieces if you can arrange the features in a way that gives you roughly a block diagonal matrix, like this:

  Feature A Feature B Feature C Feature D
Feature A    
Feature B    
Feature C    
Feature D    

By splitting this matrix up, you can form two dense feature matrices (that is, two great products) instead of one sparse feature matrix (that is, one mediocre product).

One consequence of the feature matrix is that if an application was not carefully designed in the beginning, the cost of maintaining greatness increases in proportion to the stock of existing features. Whenever a new feature is added, the developers must expend effort connecting it to all of the other components. This is probably a large part of the reason it's more fun working on small software projects than large ones, and why users of “mature” products often pine for simpler days when all the pieces fit together nicely.

The UNIX operating system was carefully designed to avoid this problem. The UNIX command line is an example of a great piece of software. Essentially every command-line utility can interact with every other command-line utility via pipes. When you install a new command-line utility, it increases the value of all the utilities that are already installed.

The original Macintosh was a great piece of software. Any time you installed a new program, the value of other programs increased because you could copy-paste and drag-and-drop between the new program and the existing programs.

As an application suite, the original Microsoft Office for Windows was a great piece of software. PowerPoint and Word documents could connect to Excel documents via Object Linking and Embedding. Installing Excel increased the value of the other programs.

Google used to be a great piece of software. There were no holes in Google's feature matrix because there was only one feature: search.

A tabbed interface is a sign of less-than-great software. The content inside a tab cannot interact with the contents of other tabs, so the feature matrix is necessarily sparse.

One of the easiest ways to add value to a piece of software is to add support for importing and exporting file formats. Each additional export format increases the value of all the import formats, and each additional import format increases the value of all the export formats. The new row in the feature matrix is automatically full of checks.

“Modular” software achieves greatness if modules are allowed to interact with each other; that is, if adding a module can increase the value of other modules. If each module is a dead-end, the program will tend to seem complicated for the amount of utility it provides.

“Secure” software tends to have a sparse, even diagonal feature matrix. The central concept in software security is isolation; as a result, “secure” software tends to have many isolated parts expressly forbidden from interacting. In my experience, software designed for security is usually not much fun to use.

When marketing a great piece of software, probably the worst thing you can do is to emphasize the list of features. The feature list is a one-dimensional slice of what is really a two-dimensional picture. It is better, I think, to describe all the rich interactions that the user should expect to experience while exploring the nooks and crannies of a dense feature matrix.


Back to Evan Miller's Home Page