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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
Discovery Phase is a service that our company provides for the development of PRD (Product Requirement Document). Let's figure it out together. Firstly, you want to develop a project that will provide direct profit or bring you value by becoming an instrument for your company. So the solution should work specifically as you intend it to work.
The work team always consists of at least three people: a developer (frontend, backend or full stack), a Project Manager or a Lead Dev (hereinafter PM) and a QA. It is often the case that if a project is very dynamic there are involved two QAs or even more in order to ensure better performance and flexibility.
