The pie chart puts numbers to an intuitive conclusion I reached when I put features on a long tail or power curve.

In software products, the most frequent functions will originate from the code framework the vendor uses, rather than the vendor's own code. In fact the hits of the long tail will be accounted for by that code framework.

This acutally means that moving to SaaS as a means of achieving task sublimation on entering the late market is going to be facilitated by the change in platforms and with it changes in the code framework. As an example, on installed apps, you have little recourse to saving files, but with web apps you hardly ever save files. The weg app sublimates the technology used to save files and the tasks required to do so. The hit portion of the use frequency curve is swapped out for another one. Some of the vendor supplied functionality will be impacted and the features along the use frequency curve will be redistributed. If the previous distribution is required, then the vendor has a heuristic for what needs more work.

The use frequency curve can be organized by features, tool tasks, user tasks that aggregate tool tasks, or work accomplishments that aggregate user tasks. The curves will look similar, but reflect a different ordering of the enabling features. Work accomplishment requires some design by the user/users/customer, so the curve would be install specific.

The use frequency curve is a power law curve like the long tail.

New features could use a use frequency curve organized around cognative limits, because cognative efforts induce implicit use costs into the work that constitutes the time to return (TTR). The cognative limit is a real constraint on customer retention, so such a use curve would be a good tool to ensure that a release provides value well under the limits of cognatively induced implicit costs.