Regular sessions with Product Management and Customers

One of the most common experiences I had while interacting with people on product development teams, especially those who have been on 2-3 development cycles, from start to end is, that they seem to get a feeling for what the features in the product should be, how the workflow should happen and so on. It can get tricky when they have a strong feeling in this regard since they might incorporate their feelings in the workflow that they are implement and it would take some effort by the workflow designer or the product manager to get the design as they want (may not happen very often, but it is something to be watched out for).

But when you get the team members on the beta release program, or to monitor the user forums, or to attend sessions where actual product users meet the product development team, it can get interesting. Even when team members get to review the prerelease program (the beta program), they can seem surprised at the type of defects or feature requirements that come through these programs. I have seen cases where the team members almost dismiss these as defects that are worthy of deferring or not part of the general workflow and they have to be reminded that these are actual users, the ones who actually pay and use the software program.

The more perceptive of the team members welcome such interactions, since it gives them a great idea of how their customers are actually using the product (or atleast a section of the users) and the more they take part in their interactions, the more they are connected with how the users actually use the software and this in turn benefits the product since they are more attuned to the requirements of the user, and in fact, would actively hunt to figure out the requirements of the user.

At the same time, it is necessary that all members of the team are exposed to such interactions. Such interactions help team members understand what the users feel, that sometimes their perception of what users feel and what they themselves feel about how a feature should be like, or the severity of a defect can vary drastically, and such interactions help reduce these differences and give them a better understanding of the customer perception of what is important for features. The next when a new feature is being designed, it makes the process much smoother, and actually helps the product manager - for the case of teams that implement the Scrum development methodology, such a customer centric perception from the team members is absolutely essential and helps to drive the process of feature delivery. 

One example of this was where the feature requirement was detailed by a customer to the product management team who wrote feature specifications for the development team. However, the developer was a senior developer who had his own ideas of what the ideal feature should be like and proceeded to tweak the feature specification. It required some amount of rework to ensure that the feature was finally done as per the product management / customer requirement. 

Supporting previous versions of the software (Part 4)

This is a series of posts on the subject of when an organization decides to drop the support for a previous version of a software. Say, you are working on version 8 of a software and version 4 was released 4 years back, and the management team is trying to make a decision on retaining support for the software version. In a previous post (Supporting previous versions of the software (Part 3)), we had talked about a situation where there is no choice but to drop support, because of a dependency issue. The previous version used a software component that is not working properly and there is no way to fix this; in many such cases, the organization has to take action. It cannot pretend that the previous version is working fine except for a few glitches, and instead would need to declare that the version is no longer supported. When it says that a version is no longer supported, it actually means that there will be no support, no updates, no bug fixes and it is recommended that users upgrade to a newer version of the software.
What happens in the case where the organization has no data metrics about the number of users who are using the previous version of the software. Well, it does get kind of tricky, but these situations have happened in the past. The emphasis on being able to trap user interaction and mine this data for doing all sorts of analysis (including determining usage habits) is something that is of relatively recent vintage, not being emphasized even 4-5 years back. Now, every product tries to capture user interactions, which workflows use more often, and so on; but consider the case when this data was not being tracked and now the organization wants to drop support for a previous version of the software for which they do not have this kind of data.
Just because they do not have this data does not mean that the organization will continue to support previous versions for a long time. There is an increasing heavy cost associated with supporting long back previously released versions of software and at some point, the organization will decide to drop support. If there is no user data, the organization could check with support teams and with user support forums about the amount of queries that come in for these previous versions of the software, and if it seems that there are a large number of users that are active for those versions, then it makes sense to not drop support for some more time. On the other hand, if it turns out that there is hardly any interaction related to that specific version, then it might make sense to take the decision to drop support. Of course, there is some amount of subjectivity involved in this, since forums might not be a totally accurate mechanism to determine whether there are a lot of people using that version, but it is a hard choice. You have no other mechanism to determine the usage levels and you have to use some kind of proxy to help you make that decision.
One way is to make announcement about dropping support in another few months, and then see the reaction. If there are a large number of people who voice complaints and so on, then it might make sense to interact with some of them and determine whether they are really discomfited if support is dropped, how often do they really need some kind of support and so on. Even in such cases, after due discussions and interactions, it may still be possible to drop support (even if there some amount of opposition, as long as it is containable).

Preparing a plan for ensuring customer feedback reaches the software team

This post is not really going to lay out a plan for how to get customer feedback to the software development team. There are a large number of expert posts and articles that talk about different models of how to get customer feedback to the team, as well as different levels of interaction; this could be a high level of interaction or a summary level kind of detached level of information. The post is more about the imperative of ensuring that the software development team does get some kind of customer feedback, and in a structured way that continues even with changes in the team.
It is necessary for team members to be exposed to some amount of customer feedback, with the level of exposure being decided by the managers of the team; as well as the number of members of the team who are exposed to such feedback.
An important question is about why the team members need to be exposed to customer feedback; after all, in the classical definition of the processes of the team, the product manager is the one who is exposed to customer feedback, massages it to the appropriate functional change or addition and then puts this to the team in terms of the prioritization of this feature vs. other features; or classifies this as a defect which needs to be fixed, again as per prioritization.
However, the classical model needs to be changed. I have seen how exposure to customer feedback changes the way that the team works, their responses to defects, and the eagerness in some of the team members to get more involved with some amount of customer interaction. The biggest advantage comes in terms of getting more acquainted with the customer mind. In some cases, the shock when the team members realize that a defect that they had ignored as minor got some customers really hassled. In one case, the defect was raised to the company management through outside means and came down to the development team as a must fix; when the product manager saw the defect, there was some amount of discussion because this was a defect that had been raised earlier but had been dismissed since it was deemed as too minor and even more surprising, not really impacting customer workflows.
Even senior engineers on the development team have seen jarring signals, whereby the features they worked hard on and pushed a lot, were not really seen as important by the customer while the changes in some of the workflows that was prioritized as higher by the product management was appreciated in customer feedback mechanisms. What this did was ensured that the senior members of the team understood that they need to setup a regular structure of how to get customer workflow, as well as listen more to the product managers. This is even more important when you have development team members who have been there for a long time while there have been changes in the product management team.
Another advantage of getting customer feedback through some kind of mechanism is that the team will also get more acquainted with the people who actually interact with the customers, whether this be the customer support team or some similar kind of support mechanism, and this kind of interaction helps the team do question and answer where they learn even more of the kind of common problems that customers have in terms of workflows, and makes them more receptive to requests for changes in workflow rather than introducing new features.

Checking for updates on social networking sites, and deciding whether to go ahead with them or not ..

Around 15 years back, the ease of getting user feedback on a software product was not easy, even for the large ones such as MS Office, Adobe Acrobat, or Photoshop. The principle way of getting this feedback was through the tech support route where users would call up tech support or deal with the support through email, primarily to provide some sort of complaint in a feature or look for some sort of health. Through this process, the support team could also get some sort of feedback on the product and the performance of the product with respect to the needs of the users. As for forums such as social networking, there was hardly anything that was available.
However, if you look at the current day situation, the forums where users can report problems (or more rarely, come out in praise of a product) are widespread. There are user forums, there are Facebook pages, there are email discussion groups, there are Twitter accounts that are used by users for reporting their feedback. When you consider a large product such as the ones in the first paragraph, the number of such forums and comments within them can be awfully large. Even for a team that puts in dedicated attention to looking, consolidating such feedback and respond to feedback that may not be so positive, it can be hard to catch up and respond to such feedback.
And therein lies the danger. When there is feedback and yet no reaction from somebody from the product team, it can seem odd, and lead to complaints that the organization and the product team do not care about user feedback, and so on, leading to something that is negative in terms of perception. Does this mean that you should put in a lot of effort on monitoring and responding to such kind of feedback ? Well, it sounds good, but monitoring and responding to feedback across different social networking forum can be pretty difficult and time consuming, and you might not have enough resources dedicated for this work (and resources with some amount of expertise in such new generation forums can be expensive, since it is not just monitoring, but actually feeding them into a system that lets the team figure out responses and strategies).
The idea situation would be where you have a broad user base that takes on most of the work of responding to such feedback. If you take Photoshop, complaints and criticism from users are many times responded to by other users, which also has a high ring of authenticity to the responses, and shows the commitment of members of the user base. In that sense, a committed user base is worth a large amount of effort and money.
However, there does need to be effort put in for building up such a committed user base. The team needs to be prompt in responding to issues that are gathering track (it would be very difficult, if not impossible, to respond to each and every issue) and show some quick responses. The team also needs to make the users feel that the product and support teams are responsible and geared towards the needs and concerns of the users (this may seem subjective, but it is necessary for this kind of feeling to be generated, as projecting such a feeling through actions inspires confidence in the team from the user community and every satisfied user can then become another committed member of the user community).
Other actions would be for the product to have its own specific Facebook page and Twitter account, maintained by somebody who has an appetite for the kind of enthusiasm and social skills that are required for social networking (if there are no tweets for many days or no Facebook updates, it tends to put off users and also seems to show the product and organization in a poor light). Further, members of the product team who are more well know can also have their own social profiles and send out updates of their own, and these also help.

Customer interaction - Ensuring that solutions to problems are put out frequently on the product page

Just selling a product is not enough. Unless a company is in a very niche area where there are very competitors, customers should be seen from the long term. There have been some good products that have failed because of inadequate attention being paid to ensuring that the customers are happy and satisfied. Every product will have defects (if somebody is claiming that there product does not have any defects, you can be confident that they are lying), the way forward is to ensure that you have the right strategy in dealing with such defects.
There are many defects that have a workaround. So, for example, a customer may be running into a problem with a specific workflow using a set of steps, and there is a certain defect in either the process of the workflow, or in the information generated at the end of the workflow. Now, there are certain customers for whom this workflow is not important enough, or was something that they tried only a few times, and did not try again, or that they feel that they will not try. There could be other customers for whom the workflow is very important, and they do not feel right about this workflow not working.
Along with the different impact of such a defect to customers, there are also differences with the way that the customers raise such issues. There are customers who will actually raise such complaints to the customer service team of the product, who will search for this issue and look for any solutions posted by the company or by other users, and will visit user forums seeing whether other users are also getting such solutions and whether the company has posted anything with regard to such solutions.
In earlier posts, I have mentioned how the company should be monitoring the user forums, looking at customer complaints and the like, so that they know whether their customers are facing issues, and so on. And it is not just looking for such complaints or issues, but reaching out to people who have reported such issues. This reach out gives customers a great feeling that the product is supported by people who are responsive to customer issues, and this increases their attachment to the product.
There is another higher level in terms of responding to customers. If the team reaches a point where they feel that the case is critical, or where a number of customers are reporting the same issue, the team should consider investigating the issue such that some kind of solution is available. This might mean interacting with customers to get more information about the problem, and then putting in the best possible effort to solve the problem and figure out a solution. This solution could be in the form of a small patch that is posted on the product site along with an article that details how to use the patch; it could be in the form of some steps that prevents the product from getting into a state where the defect occurs (for example, we once had a case where we could edit a specific registry entry and an application crash was prevented), or it could be in any other form.
The point to all this was to figure out that there was a problem that needed the attention of the product team (often this would be flagged by the customer support team, since they kept a track of what issues were becoming critical; but this could be seen by looking at items / complaints getting posted by users on other online forums), investigate the issue and figure out a solution. Once the solution was available, then the next step would be post an article that detailed the issue, and then list the steps needed to solve the issue. The advantage of posting these on a site was that the post would also bet picked up by search engines and when a user ran across the issue and did a search, they would quickly find the solution.

Support forums - encouraging users to add their feedback and increase communication levels

In today's world (actually even in times gone by), it was always important for makers of software to engage with their customers. If you build something, you may be secure in the knowledge that you did your best and built your software to meet the customer needs and expectations, but if you are not engaged with your customers, then you might not be on the path to success. What works with customers can be enumerated through marketing and surveys to the highest degree, but customers have a horrible way of surprising even the best laid plans. You may turn out with a very successful software product, or you may turn out with a product that may fail to click with customers. How do you prevent this from happening ? Well, you need to be engaged with your customers, get their opinions, and do so in a way that you are getting it in their natural setting (and not depend entirely on a controlled setting where people representing customers are presented questions and information taken from these answers); and so this before, during and after your product is released.
Why would you want to get information from customers after your product is released ? Well, unless you are there for a one-off product, you need to ensure that your customers are engaged with you, feel that their opinions are taken into account, and if they have any queries, those are answered. And a critical part of that is about ensuring that their opinions and complaints are responded back. However, one major problem that I have seen is that formal customer support is more and more treated as a way to also generate revenue (or also to atleast cover costs). If done well and if you have skilled customer support, then you end up with customers who are satisfied. However, I have also seen customers who are very dis-satisfied with the level of customer support that they are getting and this forms the basis of a bad opinion of the product and of the organization. I was recently searching for some help on a topic related to MS Word, and found a page where users had suggested some solutions, and this worked for me as well. But, when you read about the opinions expressed by many of the users, the common complaint used to be that the customer support was unable to help them, and then they found a solution on a web page, and continued customer interaction on that web page brought such pages to the top of web searches for that particular problem.
And this is where teams and organizations need to be focusing. Formal customer support in the form or chat and telephone may have a certain resolution capability and experience, but it is important to combine this with web pages where users can report problems and get solutions. I have seen teams where team members are encouraged to respond to user problems and suggest solutions (especially in cases where customers are looking for simple items such as looking for a certain feature or a plugin, or some other issue that is not machine or user specific). In the cases I have seen where teams did this kind of interaction, we also saw that other users also started jumping in where they could suggest solutions or where there was a case where they had been given a solution in the past and they could post the same solution for another user. In addition, we had started tagging users with badges which identified them as experts at proposing solutions, and this started to build (pride and the prestige associated with getting recognized in front of other users would make sure that people got into this mode of reporting solutions). Eventually, this got into a self-sustaining mode, but the team ensured that it it did not let up about their interactions with users).
These pages also started getting reported higher and higher on search engines, and as a result, more and more users started landing on such pages when they were running into problems and for most of the users, there was not a need to go to formal customer support mechanisms.

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)

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

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

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

These are a series of posts on the process of generating a list of features for the software product; such a list of features can be aggregated, built upon and prioritized for the current and future versions of the product. These are important to ensure that you have the best of features for the future of the product, features that will make the product successful. However, before you can do that, you need to ensure that you have reviewed all the ways that you can generate a list of features, including from customers, from reviewers, and from other stakeholders. In the previous post (Developing a list of features for current and feature versions of the product - Part 4), I talked about the help pages for the product on the site of the company, and how data analysis of customer visits to such pages can help determining which features are popular and also which features cause the maximum problems to customer. In this post, I will add more details on the capturing of feature requirements from different sources.
A person who views different software products that do the same kind of work typically has a very good idea of which features are the most exciting, the ones that are the most sought after, and the ones that get good reviews. For example, if there is a new version of a software that helps users do printing, then the organization would go to technical experts from different media organizations such as Cnet, New York Times Technical Section, and many others, and look for a good review from them. Now, this process is not so easy as picking up the phone and requesting a review. For many of these media people who write the technical columns which review new products, they are experts and also fairly busy people, and they need to be approached in all seriousness, providing them with the product, time to play with the product, a list of the top features currently features in the product.
When such a discussion finally takes place, the reviewer will typically spend time with the person from the organization (typically this would be the Product Manager of the specific product), and it is during this conversation and the show and tell that the product manager will be able to generate a fair number of comments. These comments would be able to provide the Product Manager with a list of items that the reviewer feels are done well, which are sellable and which excite users. At the same time, the reviewer will also provide a list of features which are missing something, features that the reviewer feels are incomplete or with workflows not optimized for the intended users of the application; and most important, the reviewer will also have a list of features that are important for the customer, but for whatever reason, are not present in the customer. It could be that such a feature got discussed but was dropped from being included in the product for some reason.
With such a list, some study will reveal a list of big features, big feature modification and small improvements that can be done in the feature level, these would need to be balanced against features resourced from other stakeholders, and eventually a list of prioritized features can be generated, which can then be set against the current version of the product, or the next version.

Read more about this in the next post (Developing a list of features for current and future version - Part 6).

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

This is a series of posts on the way that teams try to derive a list of features that they need for basing their features sets for the current and future versions of the product. The better a list of features that you have available with you, the better will be the options available with you for generating a list of great selling features. However, even before you can get started with the process of defining which feature to use in the current release vs. features that should be done in future releases, you still need to generate such a list of features; and your attempt should be that such a list is as comprehensive as possible. In the previous post (Developing a list of features for the application - Part 3), I talked about getting features from the posts that users make in online forums. There is an increased tendency for people to use forums to present their problems and a lower percentage of people point out features that they would like. However, since these represent features suggested by actual users, such features should be considered seriously. This also ensures that users appreciate that their suggestions are also being incorporated and increases their involvement in the product.
Another way for you to determine which features are being used the most as well as which features are causing users problems is through the statistics on help items. If you are into providing more information to your customers, one easy way is to have all your application help online along with other areas that would be helpful to users such as How to help videos, Tutorials, Solutions for major bugs, and so on. Now, such items on your company's servers are typically indexed easily enough and will show up when users search for such items. Along with such help pages, it would be easy enough to provide a small section where users can put in their suggestions.
Once these pages are up, monitoring the suggestions provided by users along with the statistics on which of these pages are accessed by users can provide invaluable help to a team that is trying to make sense of this data. So, for example, if you have provided a video on how to use a particular feature, and this is being accessed the most by your users, and they also provide feedback, then a team tasked with trying to evaluating this data will be able to determine which part of the feature works well, which part does not, and also about suggestions for improvement. There are many teams and organizations that try to make sense out of such data, and they have managed to determine which features are the ones where users are reporting problems, and once they even managed to determine that a feature that was a technical masterpiece did not seem to have much user attention (atleast not to the level that was required by the team).
Continuing on this line will enable a team to make improvements to their existing features or even do major modifications, which can actually almost seem like new features if the change is big enough.

Read more about this feature collection and analysis in the next post (Developing a list of features for the application - Part 5)

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

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.

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

This is a series of posts on the process of developing a list of features for the current and next version of your product. Without such a list of features, without having done the best effort to ensure that the list of features is perfect and suitable, the product will not be a success. It is the rare product that can be successful despite not having the best of research for the list of features; in fact, in most cases, a product may not be successful despite having made the best effort to ensure that the list of features has been well researched and prioritized. In the previous post (Developing the list of features for a product - Part 1), we covered how to generate a list of features, some of the sources of such a list of features, and the stakeholders for the same.
In the current post, I will focus on getting features ideas and refinements from one of the key stakeholders of the project, namely the customers. The customers of your product are one of the principal stakeholders, and it is their comfort with the product that determines whether a product is successful or a failure (actually even when a product is liked by customers, it can be a failure, but that is a different story (the success factor may not be enough to cover the costs of the product, or the desired success factors for the product)).
How do you get feedback from the customers ? Getting feedback from the customers is one of the first steps in deriving a list of features that are required by your customers. Here are a few of the methods:
- Incorporate a feature in the product that allows your customers to provide their inputs. This can be like a sort of survey mechanism, cloaked in some appealing language that appeals to the vanity of the customers (so that they do not get irritated by such queries - putting in language like 'we build this product based on inputs from our customers, and your inputs are essential for developing a great product'). If you are able to showcase later that some of the features were built on the advise of customers or even more so, if some features were built while having customers as consultants, it overall gets you a list of features that are desired by customers (I know a team that did this on a regular basis, and got a number of customers who would be part of this effort and would also upgrade their product versions due to their commitment to the product). However, for an effort like this to work, it is essential that you do this in a serious way. When the survey is being prepared, to get a list of concerns that people have or to get the features that they need in the product, you need to ensure that the queries are made with all seriousness. Preparing such queries is not an easy matter. Questions that seem obvious to people involved with the project can seem very apparent, but you need to get outside people involved. For people who are not so intimately involved with the product, such questions can turn out to be confusing or not well constructed. Hence, if you want such queries with customers to be useful, and also to have a connection with your customers, make sure that an expert team is chosen to prepare the list of questions, and only after due consideration are such surveys floated to customers. A further note of caution - floating such surveys to customers should not be done in rapid succession, there should be an adequate time gap between such surveys.

Read more about the feature gathering and refinement process in the next series - Part 3.