What we're doing The research into a research piece on best practices for requirements documents is underway. As anyone who has ever been responsible for requirements knows, there are two sides to this question:
The requirements process. The overt part of requirements is the process of writing them. The subtler part of the process is figuring out the information needed for the audience. Development (including QA and documentation) might be the primary audience, but they're hardly the only ones.
The work product. In other word, the actual requirements document. Or, in many cases, documents. For example, while there might be a template for feature requirements, it may link to related or supporting documents (personas, customer feedback, etc.)
How you can help As with any type of research, the larger and more representative the sample, the better. Which means that you, Dear Reader, can help make this research project all that it can be. In this case, we need your help with that second aspect of requirements, the work product.
Speaking of social media, one of the two research documents now in the editing queue looks at using social media as a source of product requirements. Using Forrester's POST* methodology as a starting point, how can product managers harness the enormous amount of potentially useful information transmitted in the clear through blogs, forums, Wikis, and similar technologies?
The other document in editing is the "Agile company" piece, covering the results of the survey and interviews we conducted to understand how Agile development changes technology companies. To foreshadow the results, I had to divide Agile adoption into two stages. To date, Agile aficianados have focused on the first, Agile within the development team. Clearly, for the story of Agile adoption, that's only Chapter One.
* In this approach, the steps for analyzing social media involve people, objectives, strategy, and technology (POST).
Obviously, it's important to handle customers deftly when you can't comply with their requests. You'd like to keep the conversation friendly, but sometimes, the situation gets confrontational. Your diplomatic skills will face their toughest challenge.
All politics is local I might have been unusually blessed with reasonable, understanding customers, but I never found the "foreign policy" part of saying no to be that difficult. The real headache, at least where I've worked, was "domestic politics"--what happens within your own company when you have to say no to a customer.
Ever since I did the research on tools for product managers, I've been diddling with an ROI calculator for improved product requirements, which can come from two sources: (1) hiring another product manager; and (2) implementing a specialized requirements tool.
Here's the final product. Really, this is a way of demonstrating the value of product management. Product managers and PM tools are just the tangible manifestations of that business function.
Saeed asks a great question: Why not have Development report to Product Management? PM is supposed to own the business argument for what Development is doing. Why not, therefore, make the development team formally accountable to the people who are supposed to give thumbs up or thumbs down to what the developers are doing?
Saeed is asking about the pros and cons of that arrangement, but undoubtedly he's urging us to question the unquestioned assumptions about technology companies. Provocative language like this has an old vintage. For example, a couple of centuries ago, the Enlightenment thinker Denis Diderot, trying to get shake up his readers' attitudes about the divine right of kings, said, "The arbitrary rule of a just and enlightened prince is always bad." Zing!
I urge you to read the comments section of Saeed's post. Here, I'll add a few thoughts of my own: