Process This: Product Requirements Planning


A colleague recently lamented the challenge of a security-related development effort that presumably met the product requirements spec, yet failed upon audit. Product Engineering would maintain they’re just driven by the PRD, and the development will be fast and complete – just as soon as all requirements are solidified and they can pull the trigger. But it’s not uncommon for requirements for any sophisticated system (security related or not) to be incomplete, at least until the later stages of a development program. Things are overlooked, new issues arise, and even the existing requirements are sometimes found to be ambiguous or fuzzy. The fix is to be found in the dev process, not with the management or a specific department or function. The higher levels see the world with a broader brush, whereas the missed requirements are usually in the details – the specific design choices, uncommon use cases, etc.

I’m not a fan of heavyweight process management, but the following structure can provide gentle discipline to product development and lends itself to continuous improvement.

1. Product requirements document joint review

Sending a written document is insufficient; each product requirement should be jointly reviewed by the product/ business owner, the dev manager(s) and product architect to weed out ambiguous language, surface any questions or issues and technically validate the request.

2. Architecture review and design reviews

Although these reviews play mostly to the engineering audience, it helps to have the implementation discussed interactively. In hearing the design explained, the product owners and the developers will be prompted to ask questions, further crystallizing the product requirements and ironing out design choices. In particular, having each developer describe her or his design ensures nothing got lost since the requirement was first scoped and accepted. Furthermore, the discussion might reflect trends or future requirements that should be anticipated in current design decisions.

3. Preservation and extension of requirements documents

As nuances are identified during these reviews and during the development process itself, the product or program manager must have the discipline to capture these important details and keep the product requirements document and other program artifacts current so the organization learns and future programs benefit. Ideally, a program manager fills these gaps between organizational functions and orchestrates the process; but the focus should be less on the schedule and more on the quality of the release.

4.  Collaborative ownership

The product team, consisting of business owner, product manager and engineering, must acknowledge and embrace the dynamic nature of the beast and assume shared responsibility for meeting the business requirements. Each player has an equal chance to mess things up by focusing too narrowly. Each player also has a chance to think broadly about the problem, and anticipate issues that nobody thought to write into the spec. While it may seem reasonable that engineering simply needs to meet a given set of requirements, in reality the requirements are complex and evolving, and a collaborative approach is essential. Frequent informal communication across the team helps minimize surprises.

In a fast-growth organization with new engineers and new managers constantly entering the picture, these disciplines help normalize the planning and prevent previous ‘learnings’ from being lost to attrition or organizational change. The process is never perfect, but process improvement can always be expected.



Share This: