Typical Tasks of an MRP system
As you can see some tasks are performed frequently while others are rare but have a long duration However, each of these tasks require resources and are an expense for a company. Minimizing the time to accomplish these tasks will create value for a user and free a user up to focus on more strategic tasks.
It is important to make the distinction between user tasks and product functionality. This model is focused on where users spend their time without your software. Once the software is adopted, many tasks should decrease in duration and frequency. At that point, new tasks will emerge as users focus on new challenges.
Once you have identified where your target users spend their time, the next step is to plot the tasks on the chart similar to the graph above. Next, create a 45 degree line in the upper corner and then move the line to the lower corner based on the version of the software. Tasks above the line should be included in a particular version. Tasks below the line are reserved for future versions. Each task should then have an associated feature that will help the user minimize the time it takes to perform the task.
This method ensures that you can provided the maximum productivity gains to users with the minimal engineering resources. There is no sense in adding a feature if it does not solve a problem that the user encounters infrequently or can be done very quickly.
Product Roadmap that is based on where users currently spend their time.
One thing that becomes obvious in this model is the law of diminishing returns for software functionality. After several versions, you have simplified the majority of the users tasks and it is harder to show value. Microsoft Word is a good example of this. The majority of tasks such as cut and paste, spell check, grammar correction and bullets/numbers were released in earlier versions. All the future improvements are related to tasks that are done infrequently and have a short duration.
By using this model, you can focus your engineering resources on the biggest problems your customers are facing. Additionally, this model provides a framework for discussing the activities of the users that is much better than creating a list of what you want the software to do. If someone tries to add some functionality that is ahead of the version curve, you can give justification on why to hold off on the feature since it is ahead of the version curve. Similarly, if any tasks is being performed by the customer is behind a particular version curve, then you need to make sure that the task is included in the next version.
