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.
5 thoughts on “Requirements are never done”
As soon as requirements are “done”, start writing test scripts – you’ll soon be able to update your document with more precisions!
And you didn’t even _mention_ all the requirements you discover _after_ development has started….
Great points, both of you!
To your point, Richard, we’ve actually started writing test cases while creating requirements. This gives engineers very specific details about what the acceptance criteria to say that a given requirement is “done.”
And Dana is absolutely correct, which is why a lot of companies are focusing more on Agile development methodologies that acknowledge that no matter how smart you are and how much you try up front, you will always miss some requirements, or the market will change, or some outside events will impact the requirements. Rather than trying to insulate your product from those issues, Agile seeks to embrace them and figure out how to deal with them.
I think the Seilevel post points out that requirements need to be treated as more than words in a document but as a living and changing entity, and in order to implement them successfully you need to give them food and water and care for them.
At my organization, it is not accepted to discover additional requirements after the development has started. All the requirements must be considered and closed before issuing the final version of the RD and getting commitment from Project Manager and Technologies. Closed RD is must in order to get HLD/SLD written. Itâ€™s always a problem to change requirements at any stage later on. Any change is immediately escalated and used to add more dev time.
Julia, The issue at hand is Waterfall vs. Agile. It is also a matter of large vs. small companies. Requirements do change in both the waterfall and agile methods. Agile was a response to requirements volatility and a few other things. Requirements volatility is not real, but rather an artifact of poor requirements elicitation processes. Agile will not in itself fix the problems inherent in requirements elicitation.
Comments are closed.