When you're drawing the line around your software, make sure you're not leaving in marginal utility features in an attempt to add more value. These little wannabe-features hang around unloved, bloating your app, hogging the UI and adding to maintenance costs.
So far so good. However, I'm not convinced by the two-dimensional evaluation graph that Des proposes to decide which features to build. By reducing features to two questions (who will use it and how often), it reminds me of the Pritchard method for evaluating poetry, discussed in Dead Poets Society (script), where poetry is also reduced to two dimensions: the perfection/form of the poem, and the importance of its subject.
Deciding which features to include is not quite as much of an Art as poetry, but it's still complex, multi-faceted, and can be fairly subtle.
As a simple counter-example, Woobius's commercial model means that only a small proportion of users (project managers and company owners) will want to use the account upgrade feature, and they will do so very rarely (probably just once during their lifetime as a customer). This would place the "upgrade" feature down in the bottom left corner of Des's graph - and yet upgrading is obviously an essential functionality if Woobius is to make money.
So, my suggestion is to use Des's model as one data point in evaluating feature, but not as the only one. Products are complex creatures.
If you read this far, you should follow me on twitter here.