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

What is autonomic networking?

- The concept of autonomic networking follows directly from the automatic computing.

- The initiation of the autonomic computing was done by the IBM Corporation in the year of 2001.

- This concept has been brought in to the present world networking scenario in order to make the creation of self - managing networks possible. 

- Self managing networks are required for overcoming the complexity of the various networks (including internet) that is increasing at a very rapid pace. 

- This is also necessary for the further growth of the networks i.e., beyond the network size that we have today. 

- Autonomic networking is a means for the management of the network complexity. 

- In future, it is quite a possibility that routers could not be configured directly. - A point will come when it won’t be manageable by humans. 

- Autonomic networking will also minimize the manual intervention to a large extent plus it will also cut down the dependencies on the operator. 

- NMS intervention will also be reduced. 

- A fully – fledged autonomic network is expected to be capable of the following:

Ø  Self – configuration

Ø  Self – protection

Ø  Self – optimization

Ø  Self – healing

- In traditional networking systems, the amount of configuration, monitoring and reporting to be done is very large and amount of routing is very less. 

- In the autonomic networking systems, things are just the opposite i.e., there is less amount of intent, feedback and reporting and routing is more along with the other operations such as discovery and autonomic interactions. 

In autonomic networking, there are 3 characteristics of the administrator interface:

1. It is abstract
2. Light weight
3. Wide scope

- The increasing complexity of the network is viewed as a problem by most of the experts and that it might prove to be hindrance in its usability in the near future. 

- Number of PDAs, game consoles and smart phones is increasing day by day and these need an interconnection.

- Though such kind of pervasive computing adds features but it also increases the burden on the networking infrastructure that already exists since the number of tasks is so large that it is very difficult for humans to manage alone. - Another thing that adds to the problem is the cost of keeping a manual control on a number of devices in the infrastructure.

- Another important aspect is the price of manually controlling huge numbers

of vitally important devices of current network infrastructures.

- An analogy to autonomic nervous systems is the autonomic nervous system

or ANS. 

- This system regulates all the functions of the body and its various organs.

- Autonomic network systems bear a close resemblance to the ANS.

- Autonomic networking is all about adding more intelligence to the network.

- A number of complex operations are required to be carried out such as admission control, authentication, billing, shaping, routing, policing, QoS prioritizing and video encoding for providing simple services to the customer. 

There are a number of problems in the way of network as mentioned below:

1. The ever increasing size of the network.
2. The heterogeneous nature of the applications and devices.
3. Increase in the requirement of service quality.
4. Increase in the user expectations.
5. Ever changing requirements.
6. Changing context

- Pre – defined context is kept in while designing networks with the traditional approaches. 

- Whenever there is a change in the context, it leads to more time consuming manual tasks. 

- Algorithms used today do not have the ability of detecting context changes and interpreting the policies. 

- Such manual management causes more loss and outages in the revenue of the organization. 

- In autonomic networking, the system itself optimizes the goals. 

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)

What are characteristics of autonomic system?

Autonomic systems bring both challenges as well as opportunities for the future networking. The increasing numbers of users have had a negative impact on the complexity of the networks; it has also increased by multiple folds. Autonomic systems provide a solution for this problem. 

Characteristics of Autonomic System

1. High intelligence: These systems have more intelligence incorporated in to them which lets them tackle this increasing complexity easily.
2. Business Goal: They are driven by the business goal that the quality of experience of the user must be high. Even with the changing environment, there goals remain the same. But there are changes that take place in the low – level configurations. For example, when a user switches over to a low bandwidth network, the bit rate of the video has to be reduced in order to satisfy the goals of the business.
3. Complex operations: All the operations carried out in an autonomic system are complex in nature even for the simplest of the services. For example, authentication, video encoding, billing, routing, shaping, QoS prioritizing, admission control.
4. High level objectives: The human operator just has to specify the high – level objectives and it is left to the system whether it chooses to optimize one or more of the goals. In order to achieve this, the system has to translate these objectives in to low – level configurations.
5. Adaptability: The system has the ability to adapt itself to the current environment.
6. Policy continuum: There are a number of perspectives to this as mentioned below:

Ø  Business view: Includes guidelines, processes and goals.

Ø  System view: The service should be independent of the technology as well as the device that is being used.

Ø  Network view: It should be specific to technology but independent of the device.

Ø  Device view: Both technology and device specific.

Ø  Instance view: Operation should be specific to an instance.

7. Elements: The elements of the network are assumed to be heterogeneous by the autonomic communication systems whereas in plain autonomic computing the elements are taken to be as the homogeneous.
8. Distributed: These systems work up on a distributed environment.
9. Complexity: The complexity in autonomic systems is more because of the complex autonomic loop that includes the following operations:

Ø  Interaction between the context  and the business goals

Ø  The MAPE (monitor, analyze, plan and execute) loop.

10. Reliability: In autonomic systems, the network has the authority to decide for itself focusing on high level objectives. Autonomic systems rely heavily up on artificial intelligence. However, there are issues associated with artificial intelligence like it becomes difficult to intervene in between when the things go wrong.It is quite difficult to know whether the system is doing the things it is supposed to do or not.

11. Scalability: This is another major characteristic of autonomic systems. It is required to keep track of the large amounts of knowledge and information. Autonomic systems have three tools to take care of this:

Ø Distributed ontologies

Ø Distributed large – scale reasoning

Ø Exchanging only the useful information

ØDistributing information among the different components of the autonomic network.

But in these cases, detection of the conflicts is a difficult task. For handling the various interactions taking place the various autonomic components efficient protocols are required. 

Currently two approaches have been suggested for developing the autonomic networking systems namely:

1. Evolutionary Approach: Incorporating the autonomic behavior in to the pre – existing infrastructure. This approach will consist of updates in increments till a fully autonomic system is developed. This approach is more likely to be adopted even though it requires a lot of patchwork.

2.  Clean slate approach: This approach is focused up on re – designing of the internet.