It’s Not What Your Software Does, It’s What People Do With Your Software

<i>The features don’t matter. It’s all about the outcomes. What can people do with your software?</i><p>I've seen software with the opposite problem-- simulation tools applied to problems outside the range they were designed to handle. For example, a tool that idealizes gases in a room as well-mixed, used to analyze smoke movement during a fire. Or a program that assumes ducts have no air leaks, used to estimate energy losses in a duct system. In cases like these, the results aren't total garbage, but they do have to be interpreted very carefully.<p>For some software, a feature list isn't just "what the software does." It's also a list of warnings about where the results should be taken with a grain of salt.

"The creators of Garageband for iPad didn’t care about what their software could do. They cared about what people could do with their software."<p>Aren't they the same thing? Feature lists describe what your software can do, which shapes what people can do with your software.<p>That GarageBand for iPad is accessible to all might be more to do with the platform than the featureset.

It’s not what people do. It's what your software does to people.

To paraphrase a philosophical statement: "If a Software Feature falls in a forest, and no one is around to use it, is it a Feature?"

RockBand is an example of successful application with minimal features. There are many failures that you newer hear about because they lock feature.