{"id":6029,"date":"2014-12-15T10:17:47","date_gmt":"2014-12-15T17:17:47","guid":{"rendered":"http:\/\/proxystudio.uxpin.com\/?p=6029"},"modified":"2024-05-20T21:54:02","modified_gmt":"2024-05-21T04:54:02","slug":"write-good-product-requirements-document","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/write-good-product-requirements-document\/","title":{"rendered":"How to Write a Painless Product Requirements Document"},"content":{"rendered":"

\"How<\/p>\n

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.<\/p>\n

While you do a lot of concepting during the research, analysis, and design phases, it\u2019s 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.<\/p>\n

In this piece, we\u2019ll look at Product Hunt<\/a>‘s product requirements document as a best practice and explain how to make it work for you. Follow along, then use our free PRD template<\/a>.<\/p>\n

<\/p>\n

The Anatomy of the Product Requirements Document<\/h2>\n

Once you get to the \u201cBuild It\u201d phase, the previous research and prototyping should give your team a high-level understanding of your product. All companies are different, so some stages of product development can happen simultaneously (instead of sequential).<\/p>\n

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\u2019s 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.<\/p>\n

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.<\/p>\n

\"Product<\/p>\n

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

The product curation company Product Hunt shows that a PRD doesn\u2019t need to be 100 pages long<\/a> \u2014 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.<\/p>\n

\"ProductHunt<\/a><\/p>\n

Source: Product Hunt Product Requirements Document<\/a><\/em><\/p>\n

According to Ben Horowitz and David Weiden, both notable venture capitalists, <\/b>the PRD is the most important document a product manager maintains<\/a> 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 \u2014 the document is never truly complete, it simply evolves as the team iterates.<\/p>\n

Marty Cagan, Partner at the Silicon Valley Product Group<\/b>, explains the four core sections of a PRD<\/a> \u2014 defining purpose, describing features, setting release criteria, sketching rough timing \u2014 which we\u2019ve adapted for our purposes below. According to Cagan, the PRD\u2019s goal is to explain the \u201cWhat\u201d, not the \u201cHow\u201d. 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 \u2014 don\u2019t piss them off by making the PRD a recipe rather than a guideline.<\/p>\n

I. Define the Product Purpose<\/b><\/h4>\n

Make sure you discuss the user problems (not solutions) that must be addressed, the target demographic (companies, customers, users) and various use cases for each demographic.<\/p>\n

While this has probably been discussed to death before, it\u2019s 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<\/a>, so forget the marketing jargon and only talk about \u201cWhy?\u201d, \u201cWho cares?\u201d, and \u201cSo What?\u201d.<\/p>\n

\"ProductHunt<\/a><\/p>\n

Source: Product Hunt Product Requirements Document<\/a><\/em><\/p>\n

Join the world's best designers who use UXPin.<\/h2>Sign up for a free trial.<\/span>Try it for free!<\/a><\/section><\/h3>\n

II. Describe the Product Features <\/b><\/h3>\n

The features section is the body of the PRD.<\/p>\n

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 features<\/a> will also help you prioritize in case there are scheduling shifts or you discover some features should be replaced as you progress in development. To learn more about how some of today\u2019s most successful companies prioritize features, check out the Guide to UX Design Process & Documentation<\/a>.<\/p>\n

\"ProductHunt
\nSource:<\/a>Product Hunt Product Requirements Document<\/a><\/em><\/p>\n

III. Outline the Release Criteria<\/b><\/h3>\n

How will you know the product is ready to release for beta testing? While this section can be the most technical of the PRD, we still are just describing goals \u2014 not a means to achieve them. You\u2019ll want to outline criteria in these five areas:<\/p>\n