The long in the tooth PRD or Product Requirements Document is a commonly used method of describing a product intended to be built. It’s not used in all organizations. That may be due to some places having very loose or organic methodologies to develop products with sparse documentation, or that a PRD is a waterfall asset and the majority of companies now use some level of agile development. Still many agile companies create PRDs. Whatever the organization’s PRD practices: STOP producing PRDs!

The idea of documenting a new product or feature taking into account factors that influence, describe, and validate it is a great—no… necessary practice. Although there are no particular PRD standards, the point is, the “what” and “how” that’s typically described is a waterfall oriented piece of thinking. It’s time to refine those methods for the agile age and utilize something better, more appropriate, and more valuable to product managers and stakeholders. That new document is a PVR or Product Value Rationale.

First, the title is meaningful. A Product Requirements Document implies that it stipulates what MUST be included to create the product and that those stipulations are final. That makes sense in a waterfall world. In agile, user stories fill that role.

Nevertheless, even agile producers of PRDs author sections like “Jobs to be Done,” which indicate the work that is required to build the product. At the very least, it’s a redundancy because it has to be replicated in user stories. Other similar segments have limited value too.

Then there are usually some sections that provide business justification as to why whatever it is will be built. That make sense.

And this is a good juncture to point out that there are three audiences for product requirements: those that only look at PRDs/business documentation, those that only look at user stories, and those that look at both—the true minority.

Typically, the engineering team only or primarily looks at user stories as their blueprint of what to build and test.

Typically, stakeholders/leadership only look at PRDs/business documentation.

So from that disassociated standpoint, the redundancy makes sense—except that leadership usually doesn’t care too much about the details of “Jobs to be Done” types of descriptions, rather, they care about justifications as to the impact of producing the product or feature and the net value it brings to the company in revenue, branding, competitiveness, etc.

Product Value Rationale [PVR] to the rescue!

Product Value Rationale is a business document. It’s fantastic if people in engineering, sales, or support oriented roles read it too, but it’s a document that a product manager creates to codify their thinking and provide rationalization to leadership as to how they arrived at and justify their feature/product choices.

A PVR is not radically different than a PRD, rather, it’s a logical iteration to serve agile PMs. It becomes the detailed justification document and business guide that results after analysis techniques like RICE, MoSCoW, SWOT, SMART, etc. are utilized. Those frameworks are kind of the shorthand answer that are explained in a detailed, organized manner via PVR.

Each section is authored in business terms for a business audience to give detail into the “why” behind a feature or product and delineate logic, resource, strategic, and financial factors for the decisions made. In fact, explanations for decisions not to pursue certain features, products, or strategies are encouraged too—as supporting evidence as to why the path chosen was made.

To compliment written justifications, each section or most sections of a PVR can be scored as well, assigning points or a value on a scale for each. An example might be a new feature. Using a 1-5 scale, risk might be a 2, cost might be a 4, effort might be a 3, etc. It can also be done with cumulative points and a minimum threshold, where on a total scale of 100 points, the go/no-go decision is determined by having say… at least 75 points.

Lastly, a PVR can be used as a prioritization mechanism as well. When there are a bunch of features in the backlog, each with a completed PVR, prioritization can be determined by PVR scoring, or relating feature-specific business value to other related or symbiotic stories for features slated to be developed within certain sprints. And it works well to inform the Revenue/Utilization Index too.

To get a clearer understanding, check back soon for a downloadable example PVR.