Support the Ukrainians by working with us

Product Requirement Document

What is included in PRD?

PRD (Product Requirement Document) is an engineering document (referred to as GD below), which includes a complete technical description of the project and High-Fidelity Wireframes (referred to as WF below). In Discovery Phase we work closely with the client to develop the project and technical documentation (PRD). Let’s pick apart PRD and discuss what blocks it includes

Link block

This block is designed to store all links to project resources: SRC (a Google Drive folder which keeps all project materials in one place), links to prod and dev servers, admin panel, link to wireframes and mockups (logo, style guide, brand Identity and UX / UI itself), a link to the REST API documentation (OpenAPI standard), links to other resources necessary for daily work on the project. This allows all project participants to quickly find what they need.

In Discovery Phase we work closely
with the client to develop the project
and technical documentation (PRD)

Table of contents

The size of the PRD, depending on the project, ranges from 60 to 500 pages (9 kegel). Therefore, the table of contents here is necessary for navigating through the PRD.


Initially, this is a brief or a task statement with which a client approached us. However, as the Discovery Phase progresses, we update it with relevant information. On large projects, the brief can take 20-50 pages and have its own subsections. This is necessary so that the client and the development team can see the real direction of the project all the time.


This is one of the most important sections. The Discovery Phase starts immediately with 20-30 general questions. Then, as more and more details are clarified, our team completes the brief and builds the Project Structure.

  • Again, questions are an essential part of the PRD. The reason is that the main task of the Discovery Phase is to find as many pitfalls of the project as possible before the estimation stage. Asking the right questions allows the team to become familiar with the specifics of the project. The client, at this time, gets acquainted with the technical features of web development and terminology
  • The questioning phase only stops when the PRD is complete. A project can have from 50 to 400 questions
  • As we say: The worst question is the one that was not asked


This section contains a complete list of all the core terms of the client's project (medical, legal, technical, industrial). This section allows all project participants to quickly understand a term, technical slang or just an abbreviation that is used in the context of a project description.

attended the conference
glasses with company logo

Server infrastructure

This section contains a detailed description of the complete infrastructure of the server part of the project (Devops). This is especially true for high-load projects (1-3+ minutes of users per month) and projects with high peak loads (30-50k users per minute).

Technical features

This section describes the common UI / UX features to the system as a whole, the principles of page behavior, blocking data when saving, saving rules, sorting, filtering and other features which will apply to the entire project. What allows us to describe each individual functional block below and to simplify the information while avoiding repetition. Which allows us to only describe differences from the standard behavior of the system in some cases.


If the project involves the use or connection of physical equipment, this section will describe it.

  • For example, fiscal printers, fiscal registrars, cameras, document scanners, scanners for barcodes and QR codes, and other additional equipment
  • This section can also describe the technical features of the work environment of company guys if we are developing a management system (ERP, ERM, CRM). For example, screen size and resolution, touchscreen or normal, Windows or MacOS
  • Additionally, the requirements for the work environment of guys or customers can be described. For example, the cashier work environment: there is from 30 seconds to 2 minutes to serve one client so that there is no queue at the medical center (capacity is up to 500 people per day)

Tech stack

This section often takes 1-4 pages and contains a complete list of all technologies, APIs, libraries, and best practices that will be used in the project.

As more and more details are clarified,
our team completes the brief and
builds the Project Structure

Timing diagrams, use case diagrams, other UML diagrams

If the project uses complex algorithms, a lot of entities with complex interactions, background processes (actions are not visible to the eye, only the result) we create appropriate charts so that everyone is on the same page. Our task is to do what the client requires, no more and no less.

Project structure

This is the main part of the PRD. This block describes detailed information about each button, page and user interaction. Historically, this section has been called the project structure, because this section describes all the project details. Let's see what is included here.

Seeders and data generation for DB

This section describes all the seeders that will be needed during the development of the project. Including with test data (as close as possible to real and satisfying our QA regulations).

  • In the case of reference information, listings or other data, the sources are clearly indicated or content files are uploaded to the SRC.
  • If we need to migrate data from tables or an old database, this section describes in detail the rules for migrating and transferring data to a new database.
  • For the project to work, it is necessary to fill the database with some information in advance. For the project to be viable. Both at the development stage and at the launch stage. Therefore, seeders can be marked for a dev server, a stage server, or a prod server.

This section contains a description of all system notifications. It is important not to lose sight of the fact that a project can send 20-50 different notifications according to events in the system (purchase, like, subscribe, unsubscribe, complaint, feedback, product received, order processed etc.).

Here we describe not just a list, but also the conditions for the occurrence of an event for sending a particular notification.

Conditions for remarketing and reminders, as well as educational notifications.

  • Email notifications
    • Bulk email service is selected (described in technologies)
    • Wireframes are created for each letter with the specific text of each notification along with the sending conditions
  • SMS notifications
    • Bulk SMS service is selected (described in technologies)
    • The text of each SMS is described along with the conditions for sending
  • Push notifications
    • The text of each push notification is described along with the conditions for sending it
  • Browser push notifications
    • The text of each browser notification is described along with the conditions for sending it
  • Project notifications
    • The text of each project notification is described along with the conditions for sending it
guys in the office
keyboard macbook
Public part

This section is available to all users in the public domain. In this case, we need to consider the behavior of each block from the point of view of the behavior of an unauthorized user. Then, depending on the goals and sales funnels, build a CTA so that it passes registration or purchases a product and fulfills the goal of the sales funnel.

Below is a list of items that may be included in the public part of the project excluding specific elements of each particular project.

  • Header and footer
  • Landing page
  • Search
  • Products/site sections
  • Contacts
  • Product List
  • List of other pages
User part

This section describes all the features for authorized users, for the private part of the project. Every action, every button, every background process must be described. The more accurate the PRD is, the more accurate the deadline will be. We always work as transparently as possible. We don't need too much. Therefore, we strive to give the most realistic and honest estimate.

Below is a list of items that may be included in the private part of the project excluding specific elements of each particular project.

  • Authorization
    • Can be split into roles
  • List of CRUD directories
  • List of Documents
  • Reports
  • Data exchange (import/export)
  • Function block list
Admin part

This section describes the back office of the project, the admin part, CRUD, directories, documents, reports, printables and much more. Admin panels can be complex systems with multiple roles, permissions, locking data on save, complex business logic and background processes. Everything should be described in detail up to every button and every action of the user and the system.

Below is a list of items that may be included in the private part of the project excluding specific elements of each particular project.

  • Authorization
  • Registration
  • Settings
  • List of other pages

Our job is to research and
find out what the best possible
solution would be


In this section, during the Discovery Phase, we, together with the client, put forward requests for the future features. Or, in order to reduce the scope for v1 or subsequent versions, we transfer parts of the current functionality to the backlog.

The backlog is a very handy block. When the first version is released, we can further develop the project not by versions, but move on from task to task from the backlog, choosing our priorities which allows you to push updates almost every few days.

Answered questions

This section stores a complete history of all answered questions, so that if necessary, the client can always return to them to refer to the answers. Each word in the Discovery phase is captured and saved. This way, open, transparent and trusting working relationships are built. Work relationships like that can last for years, we have clients with whom we have been working since 2007.