Requirements are never done

If you want to be a bad product manager, finish your requirements and hand them off. Your job is to define the requirements of the system, and other people are responsible for implementing them. You’ve spent days, weeks, even months poring over the requirements and making sure they capture everything that must be in the product. Now you can relax, because your job is done just as everyone else begins theirs. If there’s any confusion about what you’re asking, it’s probably just either that (a) people haven’t read the documents in enough detail, or (b) they are trying to find ways to get out of building the hard parts. Your job is to document what the product should do — how many times or ways do you have to explain it? If other people really don’t seem to get what it is you’re trying to do, you need to write more documents explaining in even more detail.

If you want to be a good product manager, continue to review and provide additional detail around your requirements. Clear requirements are necessary for a successful product, but it’s just a start. Documents are always open to interpretation and often don’t convey the purpose or priorities behind the details.

A product manager’s job doesn’t stop when the requirements are documented. In fact, that’s when a product manager’s job turns from gathering information — from the market, from customers, from competitive analysis — into communicating information — to the other groups internally who will help make the vision a reality.

Documenting a requirement on paper is not an assurance that it will be done, merely the beginning of a conversation. Developers may need to be convinced of the importance of a particular feature that may to them seem unnecessary. Designers may need to understand the priority of different requirements that are competing for the customer’s attention. Marketing may need to clarify the value that each requirement provides to the customer. This can not happen by creating a document and throwing it “over the wall.”

Over on the Seilevel blog, on the post Requirements Review: Team Effort – Early and Often, Dan recommends that requirements should be reviewed “all the time” and notes that this is part of ongoing level-setting and risk reduction:

At all stages in the process, there should be time devoted to validating the requirement with the relevant team members. When a review and approval step is skipped, the requirement and the dependencies for that requirement are placed at risk. The greater the risk that a requirement carries, the more potential it has for being inaccurate from the business perspective and misunderstood from the development and testing perspectives. And a requirement that is either inaccurate or misunderstood or both runs a very high risk for negatively impacting the project and its success.

Requirements are not “done” until they are clearly understood, implemented, functioning properly, tested, and validated. Until that point, an important product management responsibility is to ensure that the vision and strategy are being carried out in the proper implementation of the requirements.