The Problem with Product Requirements Documents

Before we dive into the problem with product requirements documents, also known simply as PRDs or requirements documents, it’s worth reviewing their intended purpose in order to understand why they sometimes fail to deliver. In many cases, requirements documents can ultimately result in the opposite of their intention.

You can avoid these problems by reimagining the purpose and process behind your product requirements documents, which will support your efforts to deliver the best possible product to your client.

Pinpointing the Purpose of PRDs

Just like any tool, a requirements document is meant to streamline and support a process; in this case, product development.

By way of definition, “A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.”

When it comes to managing the product requirements definition process, according to the Project Management Institute:

The PRD effort is in many respects the most important phase of a product. It sets the foundation for all subsequent phases of the product’s life cycle. The presented approach minimizes the probability of investing additional development time to redevelop or later modify by delivering a clear, identifiable set of specifications for a product effort.

The trouble is, if you’ve ever been tasked with putting together a PRD, you know how impossible and time-consuming it can be. In our experience we’ve found that the document doesn’t end with a completed set of requirements, or in many cases, nothing close to it.

Why?

Fear the Unknowns

Think about this. The Project Management Institute claims the PRD is a critical component of product development because “it sets the foundation.” But, how can this be? If you start a product requirements document at the beginning of a product when you haven’t developed anything yet, you’re working in a wasteland of unknowns. This would be like laying the foundation for a house without first determining how many floors it will have.

By its definition, you can expect a requirements document to be very incomplete. No wonder then that it’s never really followed as written. This is partly the result of authorship. It is usually just one person drafting the PRD and then seeking input from other disciplines. Invariably, they do so from that point of the author’s initial perspective.

A PRD is perfectly acceptable as a starting point to a project, but it’s misleading with respect to the entirety of the project.

In development, good ideas may get dismissed without cause because they’re considered disruptive and don’t follow what’s in the PRD. The end product could suffer or be less of a quality because of a blind commitment to the product specifications guide, rather than the creativity that occurs throughout the product development process.

Between missing information and a narrow view of the product, eventually, the PRD often gathers dust and becomes irrelevant to the end result. This is a drain on your team, your resources, and does nothing to move the needle for your end product.

Why Words Matter

The word requirement is the culprit behind the wasted time and effort inherent to the production of requirements documents. Kent Beck writes in Extreme Programming Explained:

Software development has been steered wrong by the word ‘requirement,’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence – inhibitors to embracing change. The word ‘requirement’ is just plain wrong.

If you ask Martin Eriksson, Co-Founder and Chairman at Mind the Product, ultimately, Product Requirements Documents Must Die.

The Death Knell for PRDs

Eriksson gives seven compelling reasons in support of the demise of requirements documents. Summed up, they amount to the following:

1. Echoing Beck, Eriksson asserts: “Very little in a product is actually required, and by setting everything up as a requirement we conflate priorities and set the stage for feature bloat instead of what the customer really needs to solve their problem.”
2. PRDs sidestep the problem and go straight to supposed solutions. Clients need you to keep your eye on the prize (read: the problem) in order to strategize an effective solution.
3. They are fixed in time, or “By the time we’ve written a PRD it is almost always out of date, leading to an endless cycle of updating requirements instead of building product.”
4. Information is key and critical to the end result. Eriksson makes this clear with his reminder: “Garbage in does not beget gospel out.”
5. Beware the beholder. In other words, “The cumulative errors in interpretation of the requirements, from the writer to the implementer to the tester, is a recipe for a disaster.
6. The problem with pinning down product particulars, in which “….engineering teams ask for specs, product teams write requirements, and everyone thinks they’ve done their job except the customer never ends up using the product.”
7. Product requirements documents kill creativity, undermining what could be a game-changing product for your client in need of a sound solution.

Rather than dismiss requirements documents entirely, we think it’s possible to breathe new energy into them for greater results.

A Living Document

By a “living document,” we mean you need to level the limitations your PRDs are placing on your products and, ultimately, your consumers. In order to lessen these limitations, scrapping the confines of the “requirement” connotation is necessary.

Rather than a finished document reflective of a fixed time, recast your PRD as a living document, one that is updated as often as needed. You might do this per project phase or at other predetermined points in order to capture the continuing evolution of the product. This way, as new developments occur within the process, these can be captured in the document.

Taking the time to map the journey as you go will likely help guide the development of future products.

You Don’t Know What You Don’t Know

Much of the critical information needed during product development can’t possibly be known in advance of an effort and requires digging into a project. As you work through the process, you discover new things or uncover key details that you couldn’t have known or planned for at the outset. Given this reality, why would anyone ever require the end product to meet the initial product requirements document?

What Is vs. What Could Be

When it comes to a product requirements document, we’re so used to focusing on what the product is, as imagined from a single author prior to any development, instead of what it could be. If we switch our approach to take the starting information and just see where that takes us, we could update the document as we learn more, better guiding the development process.

At the end of the day, the final document probably won’t look at all like the initial document, but it will mirror the end product, showing how it was developed from concept to production. The product’s development will still be documented, only in a more authentic, clearly followed pathway. If this process proves successful for one product, it can be replicated easily for others.

Erikkson points to prototyping as such a proven pathway:

Whether it’s a user flow in post-it notes, a page sketched up on paper, or a functioning interactive prototype, put something together that showcases the actual experience and can generate discussion internally as you hone the hundreds of minute decisions that make up a product experience, from the back-end infrastructure needed to support it, through to the precise user flow.

Precision in product development? Shouldn’t be a tough sell.

Why Would a PRD Process Change Matter?

Changing the PRD process to one that evolves organically, based on product knowledge, will result in a better solution. With the current PRD process, you could come up with an idea that’s disruptive to the starting document. You might learn something that makes you want to go in a different direction, but you can’t because it’s not outlined in the requirements.

The end users miss out on getting the best possible product to the market because you’re following the document that was written in the beginning and not after the information has been uncovered and learned.

Product configuration is a great example. Let’s say a client approaches you about a product that they require to be 18 inches wide, 12 inches deep, and eight inches tall. If you follow those specifications as outlined in the requirements document to the letter, you’ll presumably deliver the right product to your client.

However, what if during the course of development you discover a critical need for space that you can accommodate simply by making the product narrower, deeper, and taller, meaning a better fit (literally) for the end user’s environment?

The inflexibility of the requirements document is a roadblock to producing better products that will do more for your client’s bottom line. Ditching these initial absolutes, which are really just assumptions in disguise, is key to creating better products for your clients.

Assumptions vs. Absolutes

We all know the tired expression about making assumptions, but cliches do offer kernels of truth and in this case assumptions should be understood as potential pitfalls to product development. Assumptions are great starting points but do not necessarily equate to the end game.

In our last example, the measurements were presented as absolutes but should have been assumptions from the get-go. Changing them resulted in a better product; therefore, a stronger solution for the consumer.

Granted, there will be absolutes — information that cannot or will not change throughout the product development process. Absolutes are better thought of as constraints. These are the parameters of the project that are truly fixed. A great example might be branding factors, such as company colors. As much as constraint sounds negative for its limiting connotation, especially as we push for more freedom and flexibility in thinking about PRDs and product development, parameters can be a positive. Designers need constraints.

How can you better differentiate between assumptions and absolutes?

The Truth Will Set You Free

Or, at least, clear communication will.

Eriksson asserts:

There is no replacement for high bandwidth communication. Instead of relying on writing specs and throwing them over the wall to engineering, this should be an iterative process done collaboratively to leverage the insight and creativity of everyone on the team. Whether you’re doing user story mapping, design sprints, or any other technique, collaboration will yield faster, clearer results because they were achieved in conversation with each other.

Yes, we want all members of the team in collaborative dialogue, but we also think there should be an honest exchange about the environment they are working within…or against.

Eriksson is blunt with his plea:

Get out of the building! Talk to your customers, understand what their problems really are and bring them back to the team. Then once you have some prototypes in place, test them – over and over again – to refine not just the user flow and usability, but also the desirability of the product, and thus its feasibility in the market.

This requires candid conversations about the end user’s problem and potential solution in order to deliver a product that was designed keeping both in mind.

Of course, this isn’t always easy. You might run into resistance. This could be a reticence about divulging too much information (which they actually may not even have) about the end-user. Or, it could be good old-fashioned resistance to change.

Watch Out for, “We’ve Always Done it That Way”

Rear Admiral Grace Hopper, who also happened to be a computer programming pioneer, was absolutely right when she cautioned, “The most dangerous phrase in our language is ‘We’ve always done it that way.’”

IBM executive, Catherine DeVrye, gave Hopper’s words a more pointed spin with respect to business, “Remember that the six most expensive words in business are: ‘We’ve always done it that way.’”

This mentality, though toxic, is common to many businesses. Between this limiting philosophy and the current model of PRDs, consumers are missing out on better designs that could enhance their lives and companies are missing out on profits.

Even clients who embrace change and approach your firm for a fresh look for their product are overlooking the opportunity to determine what else that product could actually be. Facilitating conversations with the customer to help uncover what a product might be missing or what they wish it could do that it doesn’t (yet!), will prove invaluable to product design.

Here at Helix Design, we don’t believe in presenting a problem without offering a path to a solution. Keep an eye out for our next blog post where we offer you some strategies to solve the problem with product requirements documents.

In the meantime, if you have a new product idea you are looking for some design guidance on start a conversation with us on chat, or contact us today.