Question: How should I handle requests that my requirements documents include all features, not just new ones?
I recently joined an organization that develops software for life sciences, a highly regulated industry. As a vendor in this vertical, we are constantly audited by clients for our quality practices in software development. We are about to launch a new product line and the question of Product Requirement Documents have come into play. Our Quality Management team has asked my team to continue carrying requirements from older product releases into the PRD for the next product release version. My software product management career has typically involved writing “delta” PRDs – the net-new features that are going into the product, rather than one large document that covers 100% of the new product’s functionality. This is the case where the PRD serves as an internal communication tool with Engineering and Marketing but also an outward facing document that may get audited by multiple clients. Has anyone worked with writing requirements that carry 100% of the functionality forward with each new software release PRD?
Answer from Tom Leung of Always Be Shipping: Yikes, that’s not the most sexy assignment I’ve ever heard so accept my condolences. That said, it’s clearly an important requirement given your industry and low tolerance for product error. Here are some suggestions as you embark on this old-school, document heavy approach.
- If you’re new to the life science software world, make sure you grock why they need so much detail. Ask “why?” a few times to really nail the underlying need. Talk directly to some of those outside clients who might audit this doc. This may result in you doing a delta PRD and just referencing the previous PRD or you may learn that the PRD is used in a way that really does require a new tome on the product as if the audience knows nothing. Alternatively, maybe you can come up with a more clever approach based on the real needs of the PRD’s audience. In a lot of ways, the PRD is a product in and of itself and not immune from the need for customer empathy.
- At the risk of stating the obvious, you’ll probably want to look at previous PRDs to see how others at your company have approached it. Often times, new PMs to a company are fearful of asking basic questions and appearing incompetent, but that’s just pride messing with them. If the current format meets the needs from tip #1, then you may not need to re-invent the wheel.
- One thing that people often overlook when launching highly complex projects is the power of pictures, especially if you need to educate external audiences. While you’ll need to satisfy whatever expectations there are, make sure you go heavy on visuals, mock-ups, diagrams, etc. It’s much easier to “click through” a series of wired mock-ups or screen shots than reading a bunch of words, lists, or tables describing those images.
- Since you mentioned quality a few times, make sure you have a thoughtful description of QA practices, minimum quality requirements, etc. You will at least want to get input from your QA team or ask them to write it themselves. It may very well be that this is the section everyone really wants covered versus the complete feature audit. I’d probably also include some discussion of top quality risks and mitigation methods and owners.
- If you have to document every feature anyway, take this as an opportunity to do some pruning. Chances are, some features are rarely used, don’t work, or no longer relevant. If you are carrying over ever single feature in your new release (unless backwards compatibility is a requirement), lifetime feature support is probably a recipe for some serious bloatware after a few versions. Given the sensitivities of your audience, probably worth calling out killed features very clearly and up front in the doc.
Hope this helps and best of luck!