Analyzing software features

In my post on scope I discussed the idea of limiting scope - both to budget and to goals. Brad Feld in this post, mentioned an interesting methodology, which quantifies the method we've used in our projects in a neat and tidy way. Since we work with early seed companies and startups in the Family, Friends and Acquaintances funding mode, we are constantly working to see what features we can build into a project for a small dollar budget. Obviously we need to leave some features out, but how best to decide?

Brad neatly summarized the decision as chartable on 2 axis. Along one axis is appearance vs substance (though I prefer the term functionality), and along the other axis is what users say they want vs whether they are willing to pay for that feature.

I would add a 3rd dimension - what the cost to code, test, implement and train are vs the speed at which the new feature can earn back it's investment. I know this is a purely ROI sort of view of the data, but it lets you see whether it's really worth it to put limited dollars into a particular feature. Perhaps in Brad's discussion they were talking about once there is Venture money already in the development and it's more a choice based on having enough money to do everything but not wanting to overburden the product with features. In our world though it's literally what can we afford. If Feature A has strong functionality, and users are willing to pay for it, but it would cost 2x as much as we have in the budget for development - then trying to build it won't help anyone until we get more funding.

In any case, it's an interesting thought exercise, and one that each entrepreneur should go through as they try to narrow down their feature set and build their demos and proofs of concepts. Take each feature and chart it three dimensionally. This will help you visualize your feature set, and decide which features to build, and which to build first.