Categories
Are PRDs Dead?
With the advent of agile and devops methodologies, the traditional Product Requirements Document (PRD) may have all but disappeared. I’ve written and reviewed more than I can remember, but I am not quite ready to write the PRD’s eulogy.
In the best case scenario, PRDs served the critical function of summarizing the business case and clearly enumerating a prioritized set of requirements for the developers and the cross-functional team. Hopefully everyone would then share the same vision as the PM. It could often be a tedious exercise in getting buy-in, like herding cats. And there would also be the inevitable reviewer who consumed volumes of red ink. However the PRD, properly reviewed and approved, allowed the entire team understand the vision of the PM: the product strategy, priorities, risks/rewards and business impact.
With the advent of devops/agile methodologies and tools, the process of consuming, executing and releasing product requirements has dramatically improved. For example, Google, Facebook, SFDC and Amazon roll-out new features, from multiple agile teams, multiple times a day. Agile tracking applications (e.g., Rally, JIRA, etc.) allow features, epics and user stories (i.e., requirements) to be defined, prioritized, assigned and managed throughout multiple development and release cycles. To a large degree the role of a traditional PRD is diminished.
Requirements prioritization has always been one of the most critical jobs of the PM. However, the business and technical drivers behind prioritization are not always evident, having not been captured completely. The PRD would be an excellent place to capture these drivers, in the form criteria to be used for requirements prioritization. What are the market hypotheses being tested? How do they equate to quantifiable business drivers? How can other business and technical drivers be prioritized? With a well-defined set of prioritization criteria, decisions like the Minimum Viable Product (MVP) can be more easily made and defended. The inevitable, ongoing development trade-offs can also be more easily made, communicated and accepted.
Using the PRD as a repository for prioritization criteria would require answers to the following questions:
- Does the PRD summarize all aspects of the business case in an effective manner?
- What are the specific market hypotheses being tested?
- Can the impact of testing these hypotheses be quantified?
- What are the other quantifiable business case criteria (e.g., market penetration, unit sales, costs, net income, pricing assumptions, etc.)?
- What are other qualitative business case criteria (e.g., competition, customer/analyst perception, portfolio considerations, etc.)?
- What is the overall technology roadmap?
- Can the business and technology roadmap criteria be prioritized (e.g., ranked, weighted)?
- Can they been aggregated into a single ranking and applied to specific agile features, epics, stories?
With the advent of devops/agile methodologies and tools, the role of the PRD must morph also. One option is for it to bridge the gap between the PM’s product vision and the requirements prioritization. With development and release now being an automated process, perhaps there is an option to streamline the requirements prioritization process also. Using the PRD to capture a well-defined set of prioritization criteria may be one way to accomplish this.
This blog post is written by George Viebeck, an experienced principal product manager with tenures at Dell EMC and other technology firms.
