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.

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)

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.

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

A product is only as good as the features it has (and of course, dependent on the quality of the features it has). So, the next big question is about which are the features that you need to put in the product, and where do you source these features. Once these features are sourced, these features are then evaluated on the basis of importance and need, it is determined which of these features will be available in the next release of the product, the requirements for these features are detailed, there is approval of management for these features, the effort estimate for these features are developed, and they are taken through the development and testing stages, and then the product is finally released.
One of the most important aspects of all this is to develop a list of features. Having the right set of features is critical for a product.
- If you have features that a customer wants, then you have every chance of developing a very successful product.
- At the same time, the set of features that you have should be better than those that your competitor has.
- The features you have in your product should be usable, the workflows should ensure that your customers fine them easy to use and not have to struggle through the implementation of these features.
- Providing the right set of features in a product means that when there are reviews of your products published, those reviews will need to have some set of features to showcase in the review. Actually, when these products are being shown to the reviewers, you better have a nice set of features else the review could turn out to be harmful for your product.
- Implementing too many features in a product can be too much of a good thing. It can make the product unwieldy, where users are not able to determine which of the features are useful to them, and the chances of getting lost are increased.
- You should ensure that you leave enough features for the next version of the product; generating useful features for a new version of the product is not an easy task.
- The Product Manager should solicit features from everybody and anybody. The customers, the marketing people, the people in customer support, the development team, the testing team, all of them have expertise with the features of the product, and can suggest some features that may be lacking, or which the implementation may not be as user friendly or comprehensive as you would have liked, and inputs you are getting from all these stakeholders can be such that the Product Manager would not have been able to generate on their own.

Most inputs on this topic in the next post (developing a list of features for the product - Part 2 - TBD)

Explain Telerik TeamPulse?

About Telerik TeamPulse

- Telerik TeamPulse has been developed by Telerik as an agile project management tool in the year of 2010. 

- One of the characteristic features of the TeamPulse is that it can be integrated as well as hosted as local Microsoft team foundation server 2008, 10 and 12 services. 

- However, it cannot be integrated with the Microsoft visual studio.

- This Telerik product is available under commercial license. 

- The features of TeamPulse have been mentioned below:

1. Bug tracking
2. Integration with the telerik’s web UI test studio
3. Time tracking
4. Backlog management
5. E – mail notifications
6. Cross – project dashboard known as xView and developed with html5.
7. Task board
8. Storyboard with WP limits
9. TeamPulse can be integrated with Microsoft TFS (team foundation server) 2008, 2010 and 2012.
10. Requirements manager
11. Best practices analyzer

- The extension provided with the Telerik TeamPulse is the TeamPulse ideas and feedback portal which is based on html and is compatible with html5.

- Since TeamPulse is commercial software, it is not available for a hosted solution but it is to be used only on premise. 

- When you add TeamPulse to TFS the planning, tracking and collaboration improves automatically.

- With the real time project intelligence of Telerik TeamPulse you can improve decision making power. 

- It provides you with up-to-date views of the status of the project. 

- By using TeamPulse, you bridge the boundaries between the team members and their geographical location i.e., the communication is improved. 

- This tool has been exclusively designed for scrum and kanban teams i.e., any of these either kanban or scrum or scrumban can be used.

- It has been designed to reduce the delivery time, eliminate the waste and improve the work flow. 

- It also provides you a convenient way for collecting and managing the customer feedback. 

- It lets you create products that your customer actually needs. 

- TeamPulse lets you manage project well with the following:

1. Work burn down
2. Velocity
3. Cycle time
4. Iteration delta
5. Agile best practices and a number of other reports. 

- Telerik TeamPulse favors most of the agile projects.

- It lets one plan, manage and monitor the results thus improving the overall process. 

- TeamPulse has got a rich interface with in–context guidance making the integration with TFS faster. 

- Its other features include:

1. Automatic notifications
2. Bug tracking
3. Gantt charts
4. Interactive gantt charts
5. Privacy settings
6. Project templates
7. Reporting
8. Scheduling
9. Task feedback
10. Workload
11. Dashboard
12. Email integration
13. Issue tracking
14. Messaging or IM
15. RSS feed
16. Collaborative
17. Issue tracking system
18. Risk management capabilities
19. Web application

- The tool has not got any remote capability features. It comes with the following resource management features:

1. Time sheets
2. Compare project
3. Management software

- Teampulse has been developed with the view that all the clients, scenario and environment differ from each other.

- Large enterprises require a tool that is capable of scaling their workload. 

- Teampulse fits every scenario even though if you require some time to master it. 

- Firstly, you need to set up the project info, template, iterations. 

- Then you need to create your team and lastly take a view of the summary of your project. - It is recommended by the system to start with the stories.

- Being an enterprise tool, it has got many features which might make you feel like it might be quite complex to use. 

- But it is quite user friendly. 

What are two methods provided by TestPartner for functional test development?

TestPartner is quite a successful GUI software testing tool. Micro focus developed this product with the intention of providing means for functional testing and GUI testing to the software developers and testers who have hard deadlines to work up on. This testing tool helps these software developers and testers to achieve more of testing in less time. 

Two primary methods  are provided by the TestPartner for functional test development:

1. Code oriented development

2. Visual storyboard – based development environment

About Code Oriented Development

- Code oriented development uses the Microsft VBA (visual basic for applications). 

- The major benefit of including this in the development environment is that using it, users can access the rich IDE (integrated development environment). 

- Access to IDE is important since it contains all the core visual basic application libraries plus the capabilities that are inheritable in VBA such as error handling, ability to reference public libraries, debugging and so on.

- A library of VBA – based functionality is provided by the Compuware TestPartner and has been specifically built to be used in the functional test automation.

About Visual Storyboard

- Visual storyboard – based development environment interface is also known as the “visual navigator”.

- It is used extensively for developing the functional test automation. 

- The following things are provided to the user through this capability:

Ø  A screen preview i.e., the screen shot of window of application under test.

Ø A list of test automation steps. These are the steps are the steps that were performed while testing against the screen.

Ø  A story board providing a series of test steps that have been performed against a number of screen previews.

- There is another advantage of this approach which is that the users can access the test automation functionality.

- In addition to this they get the ability to add variabalization, different test logics and so on. 

Advantages and Benefits of TestPartner

- Version 6.3.0 is the latest in the series of Testpartner. 

- Testpartner lets you accelerate the testing process at the same time delivering high quality software products on time. 

- The functional test automation through Testpartner is quite easy and cost effective. 

- Testpartner proves to be a powerful tool for functional test automation. 

- The tool is quite easy to understand and use. 

- Users get intuitive insights through the test analysis and visual test creation. 

- Further, there is no requirement of code which it makes usable even for the non – technical business users. 

- Accelerated testing means that the testers and developers can keep pace with the development and quality is no longer seen as a bottleneck. 

- With the visual and storyboard oriented approach of the Testpartner, such business processes can be captured that can empower the experts for creating the sophisticated test cases without being able to write the script code. 

- The analyzation of the test results is simplified by the Testpartner through its visual storyboard. 

- With this story board, it becomes easy to check where the test actually failed and where the modification is required. 

- Testpartner is well equipped with modular structures and powerful extensions. 

- With these, the technical users can access all the debugging and scripting capabilities of VBA for creating advanced test cases that are repeatable.

- Integration of the test cases that have been written in VBA or visually is possible in Testpartner.

- Tests created by the Testpartner are quick in adapting to the changes made to the application. 

- The test results can be used in incorporating the maintenance changes, thus accelerating the maintenance process. 

- The built – in verification capability of the Testpartner lets you add steps for testing the results.

Explain TestPartner - a GUI Software Testing Tool?

- TestPartner was developed by Micro Focus as a software testing tool especially for testing the graphical user interface (GUI) of the software systems and applications. 

- This testing tool was developed with the intention of empowering the software developers to functionally automate the GUIs of the AUTs. 

- The primary goal was to make the team capable of performing more application testing in a given time period as compared to the manual testing that could be performed in same amount of time. 

- TestPartner offers two basic methods for functional testing:

1. Code oriented development and
2. Visual story board based development

- Recently, the TestPartner version 6.3.0 has been released. 

- It is great product for accelerating the testing process and delivering high quality applications well before the deadline.

- IT managers who have the responsibility of ensuring the quality of the application need to deal with several business challenges that are critical such as:

Ø  Verification of the functionality of the functions i.e., whether or not they are working as expected and meet the business requirements.

Ø  Testing of the multiple heterogeneous technologies simultaneously.

Ø  Keeping up with the fast paced release schedules that are ever changing.

Ø  Striking a balance between the application quality and the associated risks.

- TestPartner provides such functional testing capabilities that very well accelerate the testing process and enables the timely successful delivery of the software.

- This it is known to do at a low cost but with no compromise in the quality. 

- TestPartner achieves this through its unique tiered testing approach. 

- The main feature of this approach is that following it can make it possible for the testers and developers to achieve more in the given time through effective collaboration.

- This software product is even beneficial for the non – technical users. 

- The visual and the contextual approach of the TestPartner lets the non – technical users to be a part of the testing process. 

- For the expert software developers and testers it provides the access to microsoft’s visual basic for the AUTs. 

- This gives them power to cope with the most complex testing problems. 

- TestPartner maintains a special flexibility and focus on the usability of the application allowing the developers to produce more positive results with minimal requirement of training.

- It helps leverage the experienced as well as the non – technical testers to test the applications more efficiently. 

- It encourages the collaboration throughout the development cycle thus achieving greater project effectiveness. 

- Using TestPartner one can even automate the regression testing process, thus quickening the acceptance of the regular updates such as services packs and patches. 

- The documentation produced by the TestPartner is quite clear and free of any ambiguity. - This further accelerates the resolution and identification of various issues related to the application under testing. 

- It makes easy for you to understand the test results so that you feel confident in releasing the software. 

- These test results can be can be used for maintaining the tests, providing better ROI. 

- One can improve the quality of the application leading to lower overall development cost. 

Quality efforts can be accelerated for a number of platforms such as:

1. Web
2. .net
3. Java
4. SAP
5. Oracle
6. Other windows – based distributed applications.

How test cases are generated using Testing Anywhere?

Testing anywhere software product helps you create the test cases using any of the 5 methods namely:

- Web recording

- Object recording

- Image recognition

- Smart recording and

- Editor

- While editor can be used for editing the test cases by advanced users, wizard is for those who do not have any programming skills. 

- Another facility is that the creation of the files that are executable. 

- These files are created in such a way that they can be executed on a machine that might be located in a remote location. 

- IT and business processes are created by the work flow designer and is managed by the same.

In this article we explain how the test cases can be generated using the testing anywhere product. 

How test cases are generated using Testing Anywhere?

- The testing anywhere product comes with a SMART recorder that one can use to create new tests. 

- Clicking on the ‘record’ button will drop down a list of options from which you have to select what type you are testing i.e., a web or windows application type. 

- Then you need to perform the activities on the system that you want to be recorded. 

- You can insert a checkpoint wherever you want by clicking on the check point button. 

- When you are done with recording the tests click on the stop button. 

- You can then save these activities in a test by clicking on the save button. 

- You can playback these test scripts whenever you want and any number of times by clicking on the run button. 

- In testing anywhere product, it does not matter if any change occurs between the size and location of the window of the application while the recording or replaying is in progress. 

- Testing anywhere uses a SMART automation technology that helps in automatically adjusting to those changes.

- Another advantage of using testing anywhere is that you can work up on any number of applications.

- You do not have to finish working up on one application before moving on to the next. 

- You can very well switch between the applications. 

- Testing anywhere even works while your computer is locked. 

- It does so because of the auto log-in capability that is unique to this software. 

- With this, you can schedule the tests and they will be executed even when your system is locked. 

- If this capability is enabled and the system is locked, it will be unlocked by the testing anywhere, the test will be executed and the computer will be locked again. 

- Auto log-in capability lets you run the tests in stealth mode when the system is locked. To do this follow:

Properties à security à run this test in stealth mode

- The execution will then be hidden. 

- Further, if you want to lock the keyboard and mouse you can use the ‘disable mouse and keyboard for this test’ option. 

- If you want to stop the execution of a test just keep holding the escape key for some time. 

- Using the pause key on the keyboard you can pause the test while it is executing. 

- Further clicking on the resume button you can continue with the execution. 

- Another thing that makes testing anywhere unique is that it can run the tests in background. 

- A number of advanced technologies lets you run the tests in background such as:

1.    Web recorder

2.    Object recorder

3.    And a number of other powerful actions

- However, there are some tests like those that are recorded through standard recorder. 

- These tests require mouse and keyboard control and therefore cannot be executed in background. 

- There are few other exceptions also such as commands such as screenshots; image comparison etc. that cannot be run in background.