This is a series of posts that talk about the features that make up an application, and more importantly, the series of steps through which the list of features for the application are collected. There are a number of sources from which these list of sources are collected (in fact, it is important not to miss as many possible feasible sources as required). Once the list is collected, they need to be added to any sort of tool where the list can be consolidated, details added where required, and then the Product Manager can start ordering the list of features based on some specific criteria. In the last post (Developing a list of features for current and future versions of the product - Part 10), I talked about one way in which the features can be selected for the next version of the product, based on the product going in for a specific area of focus. So, there was a product that had social networking as the theme for the next version of the product, and as a result, those features were ordered higher in the list that had social networking as the theme.
This post will cover more such basis on which features can be prioritized and ordered for the next and future versions of the application. Another way in which features are ordered is by trying to group them into major and minor features. Typically, one of the major necessities of new feature development is to decide on a set of features that look cool, specifically those that look good at reviews. Now, these can be features that add on a major new set of functionality, or do something that can excite users. For example, if you have an application that provides remote control capability on a tablet, a cool new use could be to also to act as a controller for game devices such as the PS3 or the Xbox (now, this is just an example).
In the whole list of features that are available in the database, there will be many such features that are worthy of review and can excite user attention. A wise product manager would not like to add too many features in one go, but add a couple of such features for the next release, then save some for the next version, and so on. Adding too many in one release diminishes the focus on each of them, and also sets expectations for future releases that may be difficult to fulfill. Another important part of such a planning is about the resources for each such feature, and combined, the total resources required for developing and testing such features. Unless the resourcing for the application changes significantly from release to release, the amount of resources available per release will be around the same, and this also limits the amount of work that can be done for each release. In our experience, we always had time only for some new features, and some smaller features / modifications.
Doing some smaller features is important, since many of these are actually refinements of existing features and allows you to pass the message to your customers that existing features are also tweaked based on their inputs (and in fact, in many cases, you should be able to trace a direct path between customer feedback and the changes made in those features based on these feedback). Prioritizing some of these modifications should be done based on the critical nature of the feedback and the urgency of them. In many cases, these modifications are important for customer workflows, and this helps the Product Manager in doing the required prioritization.
Read more about how to do this prioritization in the next post (Developing a list of features for current and future versions of the product - Part 12 - TBD).
This post will cover more such basis on which features can be prioritized and ordered for the next and future versions of the application. Another way in which features are ordered is by trying to group them into major and minor features. Typically, one of the major necessities of new feature development is to decide on a set of features that look cool, specifically those that look good at reviews. Now, these can be features that add on a major new set of functionality, or do something that can excite users. For example, if you have an application that provides remote control capability on a tablet, a cool new use could be to also to act as a controller for game devices such as the PS3 or the Xbox (now, this is just an example).
In the whole list of features that are available in the database, there will be many such features that are worthy of review and can excite user attention. A wise product manager would not like to add too many features in one go, but add a couple of such features for the next release, then save some for the next version, and so on. Adding too many in one release diminishes the focus on each of them, and also sets expectations for future releases that may be difficult to fulfill. Another important part of such a planning is about the resources for each such feature, and combined, the total resources required for developing and testing such features. Unless the resourcing for the application changes significantly from release to release, the amount of resources available per release will be around the same, and this also limits the amount of work that can be done for each release. In our experience, we always had time only for some new features, and some smaller features / modifications.
Doing some smaller features is important, since many of these are actually refinements of existing features and allows you to pass the message to your customers that existing features are also tweaked based on their inputs (and in fact, in many cases, you should be able to trace a direct path between customer feedback and the changes made in those features based on these feedback). Prioritizing some of these modifications should be done based on the critical nature of the feedback and the urgency of them. In many cases, these modifications are important for customer workflows, and this helps the Product Manager in doing the required prioritization.
Read more about how to do this prioritization in the next post (Developing a list of features for current and future versions of the product - Part 12 - TBD).
No comments:
Post a Comment