Developing a list of features for current and future versions of the product - Part 11

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).

Developing a list of features for current and future versions of the product - Part 10

This is a series of posts on how to define a list of features that will be used for current and future versions of an application. If an application needs to be successful, it is important that the application have a great list of features that attracts reviews as well as users. For this purpose, it is important to draw upon a significant list of people and users who can generate a list of features based on their usage of the product, and then it is upto the team, primarily the product manager, to organize these features into a list that will be defined by the priority of the features and the way that these features are managed in terms of which feature will make it into the current version of the product, and which feature will be added to future versions of the product. In the previous post (Developing a list of features for current and future versions of the product - Part 9) I talked about how a tool was used to capture these features, and how the Product Manager would be able to use the tool to review the features and decide the level of detail that is required for each of these features.
In this post, I will talk about how the Product Manager will try and group these features together into a logical set based on the overall feature set planned for the product. This is much easier to do when it is decided to have the next version of the application feature a specific area. So, let us consider the case of a software that generates greeting cards, after giving the user a chance to upload specific image clips, or use stock photography that is made available by the application, allows the user to add details in terms of messaging as well as using pre-determined messages and various other features. The software would let users do all this and then enter email id and name of the person to whom they would send out the email to. Now, the makers of the software felt that their competitors as well as the market were getting focused on using social networking for sending these cards as well. So, once the user has made a card, it was not required to send the card only in a 1:1 situation (which is what email would typically do), but the software would allow the user to post the card on the Facebook profile of the person to whom the card was intended for more people to see; similarly, the card could be posted on Pinterest, or sent via Twitter, and so on. All of these are new age social networking features that were missing in the application.
So, now the overall thrust area of the release was there (there would always be some minor areas that were also present, but these were the broad areas that the product would focus on). For this purpose, the Product Manager would review all the features in the tool that are focused on social networking, get an initial list, and then do a quick prioritization of the features that seem the most important. This would be an initial prioritization, and in most cases, this initial list would be presented to senior management of the team for a review as well, and changes made if required after discussion. Thus, the final selected features from the list would be taken up, with a mix of major and minor features being there in the list (with the ones that are not selected having a note added about why these features were not selected, and some of them might get the tag about being rejected as well). Once this final selected list is available, the team can then use this list for further detailing.

Developing a list of features for current and future versions of the product - Part 9

This is a series of posts that detail the need for a product team to generate a list of features that can then be applied to the current and to the future versions of the product. Having a list of features that is comprehensive as possible is necessary to ensure that the product has the best chance to success. An important part of such an effort is to ensure that all possible sources of information regarding possible features that can make it into the product are obtained, for prioritization. This has been the focus of previous posts such as the last one (Developing a list of features for current and future versions of the product - Part 8). Since we had listed down a number of possible sources for features, we should start now trying to figure out some of the ways that this list of features can be prioritized for the current and future versions of the product.
So, how do we decide on how these features can be prioritized ? Well, the most important step is to decide on the kind of process used for documenting these features. Based on several teams and tools that I have been involved with, one of the most important conclusions that we came up with was to use the default tool that is used for feature collection to collect features for future versions, or to get it tweaked if the feature tool is not able to support features that will not be implemented in future versions. So, if you are using Scrum based development, ensure that the tool you are using for scrum is capturing all the features, and then you can start doing prioritizing and ordering of such features. Other teams have been comfortable using even a simple tool such as Microsoft Excel to capture the list of features and then additional columns to capture order, timeline and other such information needed for feature ordering.
Another important part of the overall process was about deciding the level of control over the tool and the process used for the same, which would also include the level of information required. In the process we had implemented, the Product Owner has overall authority and responsibility for the ordered feature list. As a part of that, there was a process (widely publicized to the team and to other stakeholders) where a new feature could be added to the overall list. At this time, it was also mentioned about the categories of information and the level of detail that was asked for, with some of this information being mandatory, and other information being on a good to have basis.
Once the information was added to this database, the process was that such information would be added to a new status called review. It was important to realize that unless any feature was approved by the Product Manager, the feature would not move into the prioritized list (although there was a weekly reminder to the Product Manager about ensuring that pending items were reviewed by the Product Owner). The Product Owner had the power to add additional people who were allowed to review the list along with the Product Owner (this was very useful when the list of such features was large, which was typically the case when the product was moving into a final stage of the schedule, or also when the Product Owner had sent out a request email asking people to enter details into the feature database).

This is turning out to be long, so will add more in the next post (Developing a list of features for current and future versions of the product - Part 10).

Developing a list of features for current and future versions of the product - Part 8

This is a series of posts that detail the need for a product team to generate a list of features that can then be applied to the current and to the future versions of the product. It can be said in a majority of cases that a weak feature set leads to the failure of a product; as a result, it is required that the feature team and product management spend as much time as possible to ensure that all possible sources of feature requests have been looked at to determine a possible list of features for the product (for current and future versions of the product). In the previous post (Developing a list of current and future versions of the product - Part 7), I went into details of how to generate a reward based method of getting feature requests from customers and others. I will add more details of more sources for getting features and adding these to the overall feature list for prioritization and development.
We have already looked at many sources for the product. Some of those sources are people who are pretty familiar with the product and hence may have already run out of ideas (these are typically people such as the product managers, the team and a number of traditional customers). What is required is the provisioning of fresh people to look at the product and generate ideas for features based on somebody looks at things fresh. Well, where do you get such fresh people from ?
Every release there are new customers who are introduced to the product, and some of them will be of the form that they will have an opinion. You need to mine such people for getting information on where they feel some features of the product need improvement, where their work flows are not being met, and equally importantly, which are the features that would be great in the product, and are not present (these may or may not be present in the feature set that competitors have).
There are many ways to get information from customers, and we have talked about some of those ways in previous posts. Another way is to set out a survey which attempts to reach out to new customers, and asks them about which features they need help on, and other questions that will help in generating data related to which features need improvements, and which are the new features that need to be present in the product.
Another set of sources is in terms of vendors. In today's model of software development, there are many teams that will be using external vendors (in addition to the core development and testing teams) for a variety of needs; some companies have totally hived off their testing processes to external vendors, other use them for converting the software to different languages, and preparing help / documentation about the product. A number of these will be people at the vendor's end who have not worked with the product before, and they can provide some fresh ideas about what worked with them, and what did not work. Doing this on a regular basis, when they are getting some training on the product, and also when they are involved with actual work is important. The problem is, if the development team is working with these vendors, they tend to dismiss feature ideas or workflow queries from these vendors, instead of evaluating them to see whether these queries could actually work out to be feature improvements or new features.

In the next series of posts, I will talk about how to organize these features, and put them in a form that they are useful (Developing a list of features for current and future versions of the product - Part 9 - TBD)

Developing a list of features for current and future versions of the product - Part 7

This is a series of posts on how to resource a collection of features for the current and future versions of the product, develop these features, and then prioritize these features such that a list of such features can be laid before the team. Once a list of features has been generated, reviewed, necessary details added and dependencies evaluated, they form the basis for the future development of the product. However, it is critical to ensure that the feature list is formed after an extensive evaluation of all possible sources. This series of posts has been concentrating on how to obtain features from different sources, with the previous post (Developing a list of features for current and future versions - Part 6) focusing on getting a list of features and feature modifications / additions from the team members. Team members are very close to the product and can provide a lot of incremental improvements, and with their study of competitors, can also suggest features that it would be useful for the product to add. This post will look at another source from which features can be suggested (and keep in mind that even though some of them may sound odd, generating even a couple of features based on a new source can be very useful).
In a previous post, I had suggested using surveys and also collecting information based on customers usage of various features in the software. This post takes a more specific instrument to collect features; basically a contest that asks customers and others to suggest the most useful features that a product can have. This is a new avenue that has shot into higher profile in the past couple of years, and I have seen it adding a few more features to the existing list of features for a product, overcoming the skeptical nature of the team and the product manager. It is a bit hard to ensure that the team management and the product manager are exploring new avenues for generating a list of features; normally they would already have a list of features from previous such exercises, and after looking at some competitors, they would feel that they already have a good list of features and don't really see the need for looking at fresh sources of generating features (which would help in refreshing and re-prioritizing the existing list that they already have).
In the recent past, I have seen some organizations and products trying to use crowd-sourcing (god, I hate using buzz-words) as a way to generate a list of features for the product; and when you add a prize at the end, it can turn out well. So, the simple way to go about this would be:
1. Prepare a timeline for how long do you want this exercise to continue, when would start informing people and when you would end the process of collecting the list of features
2. Define whether there are any selected categories in which you want features (this can be helpful when there are certain areas of the product that you feel that you are weak in)
3. Define the level to which you want people to prepare the features that they are submitting - something like a top level definition, or a more detailed description in which they define the entry points into the feature, the processing in the feature, and the exit points from the feature
4. Define the prizes that top contributors will get, and also define whether you need to get more information from these contributors during the time period that the feature development work is happening; also define more aspects about whether there is the need to have agreements such as a Non Disclosure Agreement in the same time period.
There will be many more details during the planning of such an exercise, but these are the top level details that you should be looking at while starting an exercise to obtain features from people.
Once you get such a program running, there is a good chance that you get atleast a couple of features concepts that have not been thought through from other sources and which can be useful for your product. And in the end, if you have decided that you will take one or more such features in your product, be sure to advertise the feature and also get the contributor (if he or she has been happy with the interaction with your team) to be part of your coming out exercise of the product.

Read more about generating a list of features in the next post (Developing a list of features for current and future versions - Part 8)