How to Write a Painless Product Requirements Document

by Jerry Cao

While the bulk of documentation is produced in the earlier stages, the implementation stage is one of the most crucial phases of the UX design process.

While you do a lot of concepting during the research, analysis, and design phases, it’s now time to get to the heavy lifting. We understand that documentation doesn’t always equal a product, so that’s why we’ll just explore the essentials.

In this piece, we’ll look at Product Hunt’s product requirements document as a best practice and explain how to make it work for you.

The Anatomy of the Product Requirements Document

Regardless, you should be able to ask any 5 team members about the overall purpose, features, release criteria, and timeline for the product and they should give you roughly the same answer. In today’s Lean and Agile world, the PRD may be trimmed down (or simply represented by a prototype) so we’ll focus on just the core elements.

The PRD is the heart of your product and serves as a living document for any designer, developer, or stakeholder to understand the status and purpose of the product.

As illustrated above, failure to document requirements can lead to wildly different assumptions. Because there’s been debate around the danger of excessive design thinking as well as its vital role in product leadership, the PRD helps balance the design team’s focus on usability and aesthetics against engineering’s functional concerns.

For a detailed PRD, you can reference this expansive PRD template. For a more lightweight option, check out how to write a simple PRD.

The product curation company Product Hunt shows that a PRD doesn’t need to be 100 pages long — just define the problems the product will solve with a general description of features (and plenty of mockups from previous stages). The technical details should be saved for the FSD.

Source: Product Hunt Product Requirements Document

According to Ben Horowitz and David Weiden, both notable venture capitalists, the PRD is the most important document a product manager maintains and should be the product Bible for marketing, design, and engineering. Good product managers not only keep PRDs up-to-date on a daily or weekly basis, but they view the entire PRD process as ongoing — the document is never truly complete, it simply evolves as the team iterates.

Marty Cagan, Partner at the Silicon Valley Product Group, explains the four core sections of a PRD — defining purpose, describing features, setting release criteria, sketching rough timing — which we’ve adapted for our purposes below. According to Cagan, the PRD’s goal is to explain the “What”, not the “How”. In each section, remember to be clear on the problem being solved versus the solution otherwise you may lead the team to make incorrect assumptions. The engineers, designers, and UX folks are the ones designing solutions for the product — don’t piss them off by making the PRD a recipe rather than a guideline.

I. Define the Product Purpose

While this has probably been discussed to death before, it’s important to reiterate them during as you build the product otherwise it might get lost in the development shuffle. What separates a top 1% product manager from a top 10% product manager is understanding that the team craves purpose and context when feature tradeoffs are inevitably required, so forget the marketing jargon and only talk about “Why?”, “Who cares?”, and “So What?”.

Source: Product Hunt Product Requirements Document

II. Describe the Product Features

Features must be described with regards to the interaction design and user experience to give engineering the most flexibility. More importantly, you must map features to product objectives (known as requirements traceability) so that the business impact can be clearly understood if someone cuts a certain feature during development. Ranking these featureswill also help you prioritize in case there’s scheduling shifts or you discover some features should be replaced as you progress in development. To learn more about some of today’s most successful companies prioritize features, check out the Guide to Minimum Viable Products.

Source: Product Hunt Product Requirements Document

III. Outline the Release Criteria

  • Functionality — Is there a baseline percentage of the original features that must be retained? What are the absolute mandatory functions?
  • Usability — Is the program aesthetically striking and intuitive to users? What is the acceptable time to complete tasks for each use case?
  • Reliability — What’s the maximum acceptable failure rate? Are these failures predictable? Can the system recover from these failures?
  • Performance — How fast must it be? What is the maximum response time, throughput, and memory consumption?
  • Supportability — Is it testable, serviceable, installable, and configurable?

It’s important to start the discussion around release criteria as early as possible, iterate, and formalize them as you approach the build stage. These should be reviewed and agreed by stakeholders during the early stages of development. Otherwise, if you wait, you might just set the bar at wherever the product currently stands.

IV. State the Constraints & Establish a Schedule

Use What Works and Scrap the Rest

Source: Feature Flow

But a certain level of documentation is necessary to keep some order in all the chaos. It doesn’t need to be exhaustively detailed, but it should provide some idea of what exactly everybody is building.

User requirements coming from product management needs to be translated. Dependencies among different technical entities have to be understood. And internal and external testing feedback must be captured to justify changes. In between all this, you’ll need to answer stakeholder questions like “How is everyone staying on the same page?” and “How will we realize our goals in the set time limit?”

The product requirements document is just another helpful reference point as you prepare for the ultimate product test — your launch date.

For more smart ways on incorporating documentation into the design process, download the Guide to UX Design & Process Documentation.



The design tool for teams and professionals. From UI design and prototyping to collaboration and handoff. Speed it up with UXPin. •

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

The design tool for teams and professionals. From UI design and prototyping to collaboration and handoff. Speed it up with UXPin. •