The Product Requirements Document (PRD): How to decide what features your app needs

App features (PRD)

Developing an app? Whether it's mobile or browser-based, iOS or Android, you're going to need a PRD. What's that? Why does it matter? And how to write one? Read on to find out what you need to know to get your project moving with a high quality PRD.


    What is a Product Requirements Document (PRD)?

    A PRD (Product Requirements Document) is used by developers, startups, and other organizations to define the essential features of a proposed digital product.

    The PRD is a key project management tool because it provides clarity to all stakeholders about the precise objectives of the development process.

    During the development project, project managers and developers alike will refer back to the PRD, using it to decide the features to work on based on what the product needs to do.

    For clarity, let’s return to an example we’ve used earlier in this series; Fromage2U, the cheese sharing app for budget-conscious dairy lovers.

    PRD example

    This hypothetical app is intended to help users get their hands on expensive cheeses by giving them a way to team up and buy pricier products at scale, reducing the hit to their wallet.

    To prepare a useful PRD to help guide the development of this product, our starting point is asking what the app is required to do.

    Some core requirements include:

    • Allow users to set up their account, including items such as name, location, profile picture, and payment information.
    • Make sure users can find fellow cheese lovers in their area, necessitating some way for the app to map user locations.
    • Let users message one another as a pair or in a group.
    • A market functionality, for cheese buyers to be able to find and purchase cheese once they’ve formed a group.
    • A way for cheese vendors to present their shop and products.

    This list is non-exhaustive, and a real project planning meeting would doubtless bring other product requirements to our attention. However, this is enough for any quality digital product agency to get started by thinking about technological solutions to these requirements.

    For example, because Fromage2U requires a mapping solution so that users can find each other and cheese vendors, the developers may decide to embrace the Google Maps Platform, which is available Android, iOS or Web apps, and even via HTTP web services.

    After deciding this, the developers might go on to decide which API (Application Programming Interface) they need to use for their app to integrate properly with Google Maps.

    For Google services like this, there are some helpful resources available to help developers choose the right solution - such as the API Picker for the Google Maps Platform.

    It’s worth remembering that a PRD doesn’t need to specify the exact implementation or technical solutions a development team will use. It’s simply a matter of offering the requirements for those solutions to be matched to.

    You can think of it as a shopping list.

    A whiteboard being used to manage a development project.

    Project management isn't easy. Make the process of developing your app or other digital product easier with the help of a PRD.

    Why is a Product Requirements Document important?

    “There is no favorable wind for the sailor who doesn’t know where to go” - Seneca.

    Without a clear objective and a focus on what needs to be achieved in terms of functionality, development projects very quickly become open-ended and lengthy processes without a clear criteria for success.

    In our experience, the best projects consistently refer back to the originally stated objectives of the development work.

    If they don’t, or these concrete outcomes are never openly stated or go unrecorded, crucial choices are likely to be driven by the preferences of the developers for particular solutions or technologies, rather than the optimal solution for the product.

    The importance of having a document that clearly states what you want your product to do is clear.

    However, by including the three following types of information too, a PRD can prevent lack of clarity from undermining the success of the project in other ways:

    Key assumptions: By acknowledging your underlying assumptions you can prevent later problems for you and your users. For example, if you’re assuming users may not have internet access and connectivity while using your app it’s best to be clear about that with your development team who will need to allow for offline access.

    Significant constraints: Are you on a budget? Make it clear that your implementation costs can’t exceed a certain amount. Is there some technology you need to avoid for strategic reasons? By making that clear in the PRD, your team will know your constraints and try to work within them.

    Software dependencies: We used the example of Google Maps earlier as an example of an outside piece of technology you might use to meet the functionality requirements of your product. It’s important to list out all of these, if only for risk management purposes. What would you do if a third-party technology became unavailable or was no longer being maintained? PRDs help you plan.

    Now you know exactly why it’s worth your team’s time to put together a product requirements document, it’s time to look into what makes them distinctive as well as their key characteristics in more detail.

    A photograph of teamwork while developing a digital product.

    Without a clear sense of purpose and clear objectives , coordination between team members is likely to result in a fractured and open-ended project. With a PRD to refer to, your team will know what they're aiming for and when they've accomplished their mission.

    Why is a PRD different from a Market Requirements Document (MRD)?

    A product requirements document functions as a list of key criteria that the first release of the digital product must fulfill at launch. It is therefore a narrowly focussed document that builds on but does not contain previous work around market fit.

    What does this mean?

    The PRD lists what the digital product must be able to do but not necessarily why. The reasons the product has to have certain functionalities are determined in the research phase of the development cycle when it’s being established what features users will value.

    By contrast, the MRD (Marketing Requirements Document) makes the business case for the digital product with its various features. It’s not a document that every development project includes, as many subsume this kind of information into the broader business plan.

    What’s in an MRD?

    The marketing requirements document (MRD) usually includes:

    • The reasons for and scale of user demand
    • The market environment and opportunity the product meets
    • The business case for the product within this context

    As this implies, the MRD focuses on the business context of the product to be launched, while the PRD is aimed solely at facilitating product development.

    Photograph of a document containing market research, part of an MRD.

    The MRD provides content useful to anyone writing a PRD, but they're not the same thing.

    What should a PRD contain?

    A product requirements document (PRD) should include:

    • Every capability required for the initial release.
    • A specific, well-defined use case for each capability identifying how the user would make use of each function. This will prove essential for user testing.
    • For complex functions, sub-items that the developers can use to gain a greater understanding of how these are intended to work. Where possible, each should have their own use case.
    • A concise statement of what the team is trying to achieve with this particular release.

    Beyond the required functions of the app, the writers should include broader systemic or environmental requirements.

    For example:

    • If this is a browser-based app, which browsers should it be compatible with? Your initial reactions to questions like this may simply be to say, “all browsers”, but that might not be possible based on your budgetary or time constraints, so you might want to focus on the big ones (Safari, Chrome, - Firefox, Microsoft Edge, etc.)
    • Usability and accessibility requirements. If Fromage2U is a mobile app, will people be using it one-handed? This might not seem important now, but by failing to reason this through you may cause UX issues further down the road.

    To recap on PRD requirements, be sure to include:

    • Your key assumptions
    • Constraints on your project
    • Any dependencies, particularly external ones
    • Every necessary capability
    • A use case for each capability, including sub-items for complex functionalities
    • A statement of your aim for the product to be released
    • Any system or usage requirements, such as your UX flow or information you need for your UI

    Now you know what a PRD is, why it’s important to have one, how it differs from an MRD, and what to include, it’s time to get down to business with how to write your product requirements document.

    People in a meeting discussing a PRD.

    A PRD doesn't have to be hundreds of pages long, but it does have to contain certain key pieces of information.

    How to write a Product Requirements Document

    Step one: understand the business context of your product

    Your first step is to make sure you understand the context for the digital product to be developed. Unless you’re working in a hyper-small team or are the person responsible for preparing the information in the MRD, you will need to consult with the people who did.

    You may simply refer to the MRD itself. In fact, we recommend you do this first to learn what you can before discussing it with your team - this will save them time because they won’t have to cover basic information and you can focus on important nuances best explained face-to-face.

    By arriving at a thorough understanding of the business case and market context for the product, you’ll make sure that the developers deliver a product that meets the necessary requirements.

    If you skip this step, you may find that your development team produces a product that fails to serve the needs of your users which may ultimately have severe consequences for your business. It’s best to get things right the first time, if you can.

    Step two: prepare an initial draft of your PRD

    Now you know the aims of the product release, it’s time for the exciting part where you start to see your PRD taking shape.

    Your MRD or discussions with your team should have produced notes on each of the areas we listed out in the section What should a PRD contain?

    As with any large writing project, getting started can be the hardest part. Rather than sweating over the enormity of what you’re trying to do, begin with any boilerplate or proforma information required at your company. Even just creating the document itself without any content can be enough to give you the motivational boost you need to move forward.

    With that done, make sure you clearly label your document and state its purpose. Store it in an easy-to-find location available to everyone who will need to refer to it later or will be involved in the review process. Make sure to notify them directly of its location and send them the link. Don’t forget to tell them why it matters.

    Make each of the required elements of a PRD a heading (or H2) within your document, rather than trying to write it from start to finish. By listing each point you need to cover as section headings, you break up your task into smaller more manageable chunks.

    Make sure to include a table of contents, listing each heading and the page number where the relevant information can be found. Not everyone is going to need the entire document, so make it easy for people to find what they need for their specific role.

    Schedule a time to complete each section in your calendar and what was a large unwieldy task becomes a series of small steps with a clear plan for completion.

    Step three: revisions

    Once you have your first draft prepared - be sure to proofread to avoid silly or unprofessional mistakes - have the document reviewed by all relevant stakeholders:

    Make sure any developers who will have to refer back to it understand what’s contained, especially if it’s written in a non-native language. Confirm with the executive suite, management, marketing, or those responsible for the business-side of the company that the requirements described in your PRD match their expectations for the product.

    Getting the PRD right may take several rounds of review. That doesn’t mean you’ve done a bad job the first time round. It’s an inevitable consequence of preparing a highly important document with multiple stakeholders involved upon which may rest the success of the business. Accept feedback in the spirit in which it is meant.

    A person writing notes on a printed PRD.

    Producing a well-written PRD can be a time consuming process, which is worth taking into account during project planning. However, even with multiple rounds of revisions, it's a valuable step towards developing your app or other digital product.

    Time to get started

    You now have all the know-how you need to get started preparing a product requirements document (or PRD). You know what it is, why it’s important, what it contains, how it’s different from an MRD, and even how to write one.

    It’s time to get started.

    2021-07-2315 mins

    Alexander Smithers

    Hello! I'm the head of content at Develocraft. I'm also a startup guy (no joke)! I've worked with a lot of them and learned so much. I'm here to help you by sharing that knowledge. I'm always open to collaborations. Find me on LinkedIn.

    Share article