Product Development - some of the project planning related steps - Requirements gathering

Most people in the software industry have heard of the Software Development Life Cycle (SDLC). In the full form that you read in most literature, it has a number of steps, and may seem a bit long-winded. However, the practical version of the SDLC is to the effect of:
Requirements -> Design -> Development -> Testing & Bug fixing -> Alpha / Beta Release -> Acceptance testing -> Release
There are more complications in this process, with many additional steps such as the resource estimation that happens during requirements and design, development of test cases that happens during the design and development phase, generation of the software documentation, etc.

Now, when you step into the world of product building (whether to build a new product, or to generate a new version of an existing product), there is a slightly modified version of the SDLC (typically called the Product Development Life Cycle, or PDLC). I am not going to be covering the PDLC in a complete form in this post, instead, in the next series of posts, will cover a practical experience of what happens during the Product Development Life Cycle. If you see things happening differently in your company, please share through the comments.
Suppose you are the project / program manager for a product that has been released before, and you are doing new version planning, here are some of the initial activities that you should be considering:
- User feedback collection: Never neglect that among the changes you need to make in the newer version will be modifications of existing features. Sometimes, the focus of the team is on building new features, but if existing features do not work well for customers, then the problems with these features need to be studied, and then the team needs to discuss as to which of the problems should be taken and corresponding features modified
- Once these modifications are identified, there needs to be some detailing of some of these changes along with further concretisation of what would be a new desired workflow (this can be done through usability testing with the desired audience)
- This was it for changes to existing features. In addition (or actually the main work) is to decide which are the main features that need to be taken. Sources for generating this list of features includes customer feedback from sales and marketing teams, bug reports / feature requests filed by customers on user forums, in product reviews and so on.
- Another great source for generating a list of new features is by looking at features that are available with customers, and deciding on the list of features that are must-haves
- Another source is the list of features generated by reviewers when you are showing your product for review. Typically, they will give you feedback for the features, and also ask you about features that are not present in your product. Many of these reviewers have a feel for the pulse of the customer base, and you would be wise to review the features that they are asking for
- Sometimes, the feature list needs to be generated internally. You need to create a new market, or present a feature that will make your competitors feel that they are way behind, and one good way is to get the marketing teams, as well as the product teams together in a brainstorming session and thrash out possible features that need to be incorporated.

Enough for this post, the next post in this series with continue with requirements generation and further analysis..