Product Managers: Hunters and Gatherers
I've been working on a lot of requirements lately - some have involved a lot of research and validation with stakeholders, others were straightforward enough that I felt confident in taking what I had and putting keyboard to screen. The scope of the requirements aside, the process for building those requirements was always the same - gather the information you need and then execute (or hunt) on it.
The Gatherer
When you are gathering information you are not writing anything, you are looking for information to either support your problem/solution or disprove it (will this really solve the problem? Is there some evidence to support this?). Do not start putting that information into a template of some sort, you're not ready yet. Your job at this point is to get data, amass as much as you need to get the job done. You don't care what format the information is in - it will be a combination of emails, contact lists, website URLs, internal company documentation, notes from customer discussions, blog articles, etc, etc... the list goes on and on and who cares what it looks like, no one is going to see it. Your end goal is gather all the necessary information to start writing. Emphasis on the word "necessary", spend the time you need to figure out what is required, don't fall into the trap of gathering forever and forever. If you do this you'll never be able to execute.
The Hunter
Once the gathering has happened, enter the Hunter. The Hunter's job is to assimilate the gathered information and write the most eloquent document befitting all the work you did gathering that data. This person is looking at the information and determining what is useful and what is garbage (trust me, when you're gathering you WILL get some garbage in their with the roses, that's ok - you weren't trying to build anything). It is now the Hunter's job to separate the good from the bad and put together the requirements doc that is going to drive development and install confidence in your stakeholders that what is before them is rock-solid gold. At this stage, it is also the Hunter's job to ascertain whether enough information is in place to move forward, this is a gut-check - are we ready to go, do I have enough, if not its back to gathering. If you don't have what you need, stop writing.
You, as a Product Manager, need to be both a Hunter and a Gatherer.
There is no OR in this equation, you can't do one really, really well and hope it translates into success in the other role, it won't, it doesn't. Think about it, if you were to take all that gathered information and throw it at your developers they would have no idea where to start in designing a solution, in most cases they would have no idea what APPLIED to the solution - email threads, spreadsheets, websites, all mish-mashed together to look like one document? Who knows what you'd end up with? And what about the hunter that didn't gather? That first hand-off meeting would be a barrage of basic questions (How do our competitors do this? What is the customers history in using this feature? Hasn't someone done this before?, etc, etc) - you DO NOT want to spend your time in the first requirements meeting discussing these basic questions. You want people to start thinking about what they can offer to the problem, how they can help you get to the end goal which at the end of the day is building a really good feature, that is going to solve a really valuable need, that is going to provide you some sort of ROI (in a really great way).