You probably know them well: PRDs (Product Requirements Documents) or perhaps the more old-school “specs” or “specifications.” Regardless of what they’re called, you’ve probably heard the following:
- There are too few of them
- They are never detailed or accurate enough
- “We need to add a section on X to the default PRD/spec template to make sure we don’t forget about X.”
Make no mistake, it’s always important to have detailed, accurate, documented, requirements…just as it’s important to write robust, bug-free, performant, maintainable code. (Ironically, it’s often the engineers who, quite understandably, are the ones asking for more and better requirements. But I don’t advise asking a developer for more robust, performant, maintainable code with fewer bugs. The conversation won’t go well.)
Just as with code, the trick with requirements documents is striking the right balance between excellence and perfection. Aiming for excellence is always a good idea, but you won’t get anything done if you take the time to make everything perfect.
Everyone presumably already knows this, so what should be done differently? Here are some things to keep in mind:
- Don’t confuse the ends with the means. Requirements documents are a means to an end: customers will never see them. The only thing that matters is the product. This point is often lost.
- A conversation is worth a thousand words. A requirements document has one purpose: to get the engineering team from Point A (where they are now) to Point B (enough to implement and test the product/feature). How can you possibly know where Point A is, where Point B is, or whether B is even the right place to aim for, without talking to anyone? Others may know more or less about needs to be done than you assume. You may know more or less about what’s already there than you think. Talk to your developers, QA folks, fellow product managers, and stakeholders first. Of course, use their time wisely, but better to use it beforehand instead of later when it’s probably too late.
- Requirements have bugs too. Software code isn’t the only thing with defects; requirements documents do too. The main differences are that the bugs are usually more expensive to fix, and they manifest themselves differently. Watch out for a flurry of email, bug tickets, or impromptu meetings on a feature; often that can be a sign of defective requirements. A series of requirements defects in an area, or from a particular person, indicates something to address in more depth.
- Boilerplate requirements are useless; too many are evil. If there’s a section of a requirements document that remains as default boilerplate text, you’re wasting everyone’s time and probably just feeling guilty about it. Fill it out. Or if there really is nothing to say, say so. Sometimes, people go a little crazy adding default sections to the default template, often after one or more disasters where someone forgot something important (localization! fraud! product support!). These efforts are well-intentioned, and usually make the victim of the disaster feel a little better, but they rarely solve the problem. If there are frequent disasters in some area, consider making it an area of uncertainty instead.
The takeaway? Many teams have a lot of angst about product requirements documents. Like the code your developers write, it will never be perfect. But there are some ways to reduce the angst.
Tweet this: @bill_bliss New post: The Perfect Requirements Myth http://wp.me/p1pkik-5z #prodmgmt #agile