Product Development - Getting requirements and prioritization - Part 1

I have in mind a series of posts that explains how the product development process works inside one of the teams for a product development company (based on previous experiences). However, this story has been interrupted in the past, and I believe I last posted on this topic many months back. I will try to be more regular on this topic in the future. Previous topics that I had written about were pre-release planning and metrics.
This topic will be about the meat of actually starting work on new feature development; the need is to actually define what the team needs to deliver in this new cycle. At this stage in the cycle, the only known facts are:
- It is decided that a new version will be required
- Dates are typically known for the release. Dates can be decided based on having to schedule for a certain condition of the market (in the US, to meet the enhanced marked season starting from Black Friday to Christmas, product development needs to conclude by a certain time so that the product can make its way through the retail chain and into the hands of retailers, large and small); dates can also be scheduled to meet projected customer needs (so if a software / hardware producer faces rivalry from Apple, it used to be that they would schedule release near MacWorld to prevent Apple from running away with the market)
- The number of resources are typically known. For most product development situations (unless there is the need to scale up to meet a competitor), the resources are not changed based on the number of features available. What would happen is that the features that can be implemented are decided based on the number of resources available.

So what happens next ? Well, what needs to happen next is that the product management team needs to decide on the features that are sought to be included in this release. If the product is something large such as the next version of Visual Studio C#, then the product management team would normally comprise of multiple product managers, each of whom would be tasked with a different area of the product. It is part of the responsibility of the product management team to decide on the features that are part of the consideration set for the release (and sources for new features include competitor analysis, user requests through forums, changes suggested through usability studies and through group sessions; there are also features that may correspond to changes in the market but not suggested by users - as an example, consider the case when a new technology related to online technologies hits the market and the product needs to have features to integrate with these new technologies or features - as an example, with the emergence of social networks such as Twitter, Facebook, MySpace, it may be needed for products to see how they would integrate with those).
So ends Part 1 of this post, I will carry it ahead with the next post.