Product Development - Getting requirements and prioritization - Part 2

The previous post talked about how the Product Management team generated requirements for the new version of the product. When this happens, the next most important task is to get an idea about how much effort getting all these requirements into the product will take. This is easier said than done. Doing effort estimation when the requirement is a stated 2 line statement can be really difficult, and requires some amount of refinement.
What would next happen in most cycles that I have seen is that the requirements are next discussed between the Product Management team and the engineering team (typically senior engineers along with the engineering manager); this process also envisages that the requirements are discussed to some extent in terms of what the workflow would be (keep in mind that this is not the right time of the cycle to start designing screens or dialogs or detailing the workflow other than a top level attempt - doing such an effort for most requirements would take too long and is difficult to attempt).
What really helps for this effort is to use some sort of documentation (I know people who use Word or use an internal Twiki implementation, or some other tool to capture such requirements in a medium level of detail (this is somewhat tricky, you need to have enough detail that you can take a rough guess at the effort estimate), and where you can break down the top level requirements into one step lower of requirements (example, if you need to add a new editing capability to a tool, the intermediate level requirements could be about having different file formats supported, or about different levels of editing such as having 3 quick buttons, or a slider to allow the user to have more control)).
Another element of this cycle is to press for prioritizing the requirements. It is incredibly important to make sure that prioritization is done, and there is a possibility that the product management team may have some hesitation in terms of doing the prioritization of these requirements. However, given my earlier statement about resourcing not being infinite for the product development cycle, setting a priority means that the team can focus on those requirements that are most critical, and then on the ones that are deemed less critical. The other advantage of forcing the priority is that this process forces the product management team to take a deep look at the features (including sub-features) in terms of whether this is something that will really benefit the product. This also ensures that resources are spent wisely.