This is a series of posts that talk about developing a list of features for the software product. One of the major factors that determine whether a product is successful is having the right set of features, and getting the right set of features is not an easy task. It takes a lot of effort for ensuring that you have the right set of features, and the team and product manager should ensure that they do their best effort for preparing the list of features, and then prioritize them according to the features that should be incorporated in the current version, and those that should be kept for the next versions of the product. Once you have a list of features, you can spend time on prioritizing it for the current and future versions of the product. In the previous post (Developing a list of features for the product - part 5), I talked about how to get feature ideas from the reviewers of the product, from their experience of seeing multiple products trying to attract the same set of customers. This post will continue in the same and talk about more areas where feature requests can be generated, and added to the overall list.
One of the biggest sources of information about features (and yet one that should be considered with a lot of thought) is the development team. Day in and day out, the team is working on the product and they get a very detailed idea of what the product is like, what are some of the shortcomings of the product, and what are some of the features that are built solidly. In our teams, it invariably turned out that atleast 15% of the features that were done in a release were built based on the feedback from the team, collected from them at regular intervals of time. Doing so also increases the morale of the team, ensures that they are fully committed to the feature set of the product and to the features (the managers of the team may feel that it is not necessary to do so, since the team would anyhow be committed to the product, but you would be surprised at how such steps increases the level of involvement of the team in the future of the product).
How do you collect these features from the team ? On a regular basis, the product manager of the product should do brain-storming sessions with the team, and should also have a repository where the team members can add features, add more details to these features and even build upon these by adding use cases and examples. Such avenues can lead to some incredible feature ideas, that the product manager would not even have thought about; even though many of them would be like feature improvements rather than new features (but as we have discussed before, feature improvements, if they are big enough changes, can be almost like new features). The team, while working on the product, would have noticed many areas where the workflow could be improved; competitor analysis shows them where a feature could be modified to seem like a feature that the competitor has; their interactions with customers would show them where there can be improvements to the features and what the paint points are.
At the same time, the product manager should ensure that these feature requests from the team are seen as requests from somebody who is very deeply involved with the product (a lot of people would argue that the team is too involved and too biased in certain ways), and hence there needs to be a lot of filtering and some amount of modifications before those features can be added to the feature list. This is something that the product manager should ensure that the team has understood.
Read more about processes of collecting feature requests in the next post (Developing a list of features for current and future versions of the product - Part 7).
One of the biggest sources of information about features (and yet one that should be considered with a lot of thought) is the development team. Day in and day out, the team is working on the product and they get a very detailed idea of what the product is like, what are some of the shortcomings of the product, and what are some of the features that are built solidly. In our teams, it invariably turned out that atleast 15% of the features that were done in a release were built based on the feedback from the team, collected from them at regular intervals of time. Doing so also increases the morale of the team, ensures that they are fully committed to the feature set of the product and to the features (the managers of the team may feel that it is not necessary to do so, since the team would anyhow be committed to the product, but you would be surprised at how such steps increases the level of involvement of the team in the future of the product).
How do you collect these features from the team ? On a regular basis, the product manager of the product should do brain-storming sessions with the team, and should also have a repository where the team members can add features, add more details to these features and even build upon these by adding use cases and examples. Such avenues can lead to some incredible feature ideas, that the product manager would not even have thought about; even though many of them would be like feature improvements rather than new features (but as we have discussed before, feature improvements, if they are big enough changes, can be almost like new features). The team, while working on the product, would have noticed many areas where the workflow could be improved; competitor analysis shows them where a feature could be modified to seem like a feature that the competitor has; their interactions with customers would show them where there can be improvements to the features and what the paint points are.
At the same time, the product manager should ensure that these feature requests from the team are seen as requests from somebody who is very deeply involved with the product (a lot of people would argue that the team is too involved and too biased in certain ways), and hence there needs to be a lot of filtering and some amount of modifications before those features can be added to the feature list. This is something that the product manager should ensure that the team has understood.
Read more about processes of collecting feature requests in the next post (Developing a list of features for current and future versions of the product - Part 7).
No comments:
Post a Comment