This is a series of posts, meant for talking about the processes and methods of determining the list of features that is needed for a software application (both for the present and the future of the application). This entire process of generating a list of features is important, since it means that the team has put in the effort and the thought process of evaluating the various inputs that go into preparing a list of features, optimizing them, determining the ones that are feasible vs. the ones that are not, and then finally prioritizing them in terms of determining the ones that will go into the current version of the product vs. the ones that will go into the next version of the product. In the previous post in this series (Determining the features of an application - Part 2), I had gone into some details of the mechanisms used to collect feedback and some ideas of features from customers. I will continue on the same lines in this post as well.
- One of the best ways of determining which features are liked by your customers and which are not can be seen by monitoring user forums where users post their feedback (it is a different matter that most users post only when they have an issue or need some clarification, not when they like something). So, you could have a feature that is often commented upon, and if your team members are monitoring such communication on the user forums, you will soon realize that in a significant percentage of cases where the users have some sort of issues, they also point out the way that the feature does not work as well as the way in which they think it should work.
Once you get to this point, you will realize that defining features is not just about trying to get something new in your product; instead it may be far more useful to figure out some of the features that are already implemented and not working properly or designed in such a way that users are not seeing them as useful or easy to complete. In many of these case, the feedback will be numerous enough and detailed enough that you could drop an existing feature or re-design it in a totally new way. Such a change cannot just be called a modification of an existing feature, because the extent of change determines the amount of effort that would be put in. We have had cases where after evaluating some of the feedback from our users, we essentially were shocked at the extent to which a prized feature was causing problems to customers and we eventually put in a fair amount of effort to completely change the feature. And it was a success, since the new feature proved to be far more successful with customers; in fact some of the customers on the earlier version of the product actually upgraded to the latest version of the product since they found the reviews of the re-designed feature to be very useful in their actual workflows.
Running into such a case can be actually game changing for many teams, since this would give them a mechanism to evaluate the performance of a feature, learn why customers could be rejecting a feature, and how to be a success just by modifying an existing feature.
Read more about the feature gathering and refinement process in the next series - Part 4 - TBD.
- One of the best ways of determining which features are liked by your customers and which are not can be seen by monitoring user forums where users post their feedback (it is a different matter that most users post only when they have an issue or need some clarification, not when they like something). So, you could have a feature that is often commented upon, and if your team members are monitoring such communication on the user forums, you will soon realize that in a significant percentage of cases where the users have some sort of issues, they also point out the way that the feature does not work as well as the way in which they think it should work.
Once you get to this point, you will realize that defining features is not just about trying to get something new in your product; instead it may be far more useful to figure out some of the features that are already implemented and not working properly or designed in such a way that users are not seeing them as useful or easy to complete. In many of these case, the feedback will be numerous enough and detailed enough that you could drop an existing feature or re-design it in a totally new way. Such a change cannot just be called a modification of an existing feature, because the extent of change determines the amount of effort that would be put in. We have had cases where after evaluating some of the feedback from our users, we essentially were shocked at the extent to which a prized feature was causing problems to customers and we eventually put in a fair amount of effort to completely change the feature. And it was a success, since the new feature proved to be far more successful with customers; in fact some of the customers on the earlier version of the product actually upgraded to the latest version of the product since they found the reviews of the re-designed feature to be very useful in their actual workflows.
Running into such a case can be actually game changing for many teams, since this would give them a mechanism to evaluate the performance of a feature, learn why customers could be rejecting a feature, and how to be a success just by modifying an existing feature.
Read more about the feature gathering and refinement process in the next series - Part 4 - TBD.
No comments:
Post a Comment