PRD: what kind of document is this, what does it look like, and can we do without it?
In this article, we will elaborate on the stage of defining IT product requirement and give a client a piece of advice on the way to prepare for the stage of collecting and documenting information and to take an active part prior the developers team starts with the development activities.
Starting any project, we are all sure that our idea is perfect and the new product or service is simply destined to take its rightful place in the market.
But our faith and perfect idea are not enough. Any serious success rests upon rigorous work. And the success of a new product is based on the efforts contributed by every project member.
Looking for a reliable IT project partner? Contact Umbrella IT – we’ll bring your product to success!
One of the steps on the way to the success of a new project is to define requirements for your future product: description of your idea and vision.
The task is not to define the requirements for the sake of requirements. First of all, they should be clear to you and the team of developers.
No less important: your team should understand them the same way you do.
Otherwise, the risk is high that the result will not match your expectations.
In our article, we are going to discuss how to put together and describe in some documents the product requirements in such a manner that this description would serve as a reliable basis for the team of developers to work on.
PRD is a description, which includes all requirements for a specific product and presents what the product shall look like and how it shall function. The requirements can be summarized both in one document or in a set of documents or artifacts (mockups, charts, diagrams, documents).
Product requirements in such a document present the customer’s vision and expectations related to the product. If the client has any specialists experienced in defining the requirements in an optimal way, this is done by the customer’s party. But in case no such experienced person is available, the team of developers can undertake this and complete the requirements (this may be a project manager, tester or any team member).
Based on our experience, we can confirm that the product requirements help to map out your time and efforts wisely and to exclude the majority of risks if they are:
Content and scope of the requirements directly depend on the project’s degree of complexity.
We recommend starting with an estimation of your project complexity. Define its type (for example, will your future app be mobile or desktop?) and its approximate duration, and if possible, discuss the form to present the product requirements with your developers. An experienced team will undoubtedly offer you some tips.
For every project, regardless of their complexity and duration, the product requirements should include the following information:
Other data should be added, based on a specific situation and project terms (for example, advantages against competition, description of functions to be excluded from the product, etc.)
It takes definite time to collect the requirements, and this process is unlikely to be limited to one meeting or e-mail. Hence, be ready that at this stage, both the customer and the developers’ team will have to take an active part in working on the project.
Please, be aware: none but you can explain what you want to get in the end. However, have no doubts that the result and saved time will be worth the efforts.
NB: the objective should be clearly and concisely defined.
A good way to test yourself: check whether you can word the objective in such a manner that its description takes no more than 30 seconds.
For example: a new project objective is to create an app to help to get a certified high-quality translation of an education document by e-mail within X days (depending on the geographical location).
In our example, these are people going abroad to continue their education or look for a new job, or people who were educated abroad and now need the education document in their native language.
– admin panel used by the managers;
– user part utilized by the user to register, place an order, check the order status, and so on.
The user opens the app to have a look at the services offered. If he is satisfied with the price and completion terms, he signs in.
Then, the user selects the source and the target languages, format of the finished translated document he wants to receive, completion dates and payment terms.
Afterwards, he chooses the format to load the original education document, and the original is loaded; the manager processes the order and assigns it to some definite translator.
You are going to extend your new app with a new service in the future, and namely sending a notarized translation by mail or courier.
This shall be specified in your product requirements. Thus you will help the developers timely to take into account any thing that can be required to implement this new service, and they will not have to change the finished app in the future.
As the product requirements are not for the sake of the requirements themselves, they should be:
– describe every requirement separately, or group them logically: you should not put all the requirements together into one item. If they are interconnected, divide them into groups, for example, depending on their function. Such division will contribute to better perception and help to sort out the priorities in the right way.
– be consistent: each document should have a simple structure to be easy to read. If the product is divided into modules, such modules should be arranged in a logical sequence: for example, if the product is created by the user, then first, you need a user module and then, a product module.
– give clear instructions: try to avoid such phrases as “if required”, “wherever possible”.
– exclude any ambiguities: try to avoid the words “approximately”, “and so on”. Any attribute used should be unambiguous: for example, the word “convenient” may mean different things to different people.
– you should consider not HOW to do, but WHAT to do.
– store all the requirements in one place (for example, we use Trello): there should be one input point for the requirements, and all project members should know where to find them.
– if there are several people working on the requirements, assign one person in charge for coordination, otherwise, integrity will fail.
We may endlessly speculate on things like what shall be done and in what way. Undoubtedly, it would be perfect to find one universal template to use, regardless of the nature and terms of the project. But as you might see there is no point in this, considering a variety of products and ideas faced by the developers today.
The product requirements document template will differ in various projects and will depend, among other things, on the approach to project implementation.
Simply put, they differ since the Waterfall model implies that all the project stages should be implemented successively, one by one: definition of requirements, planning, implementation, integration, testing, release, support, and each stage starts only after the previous one is complete.
Within this model, the product requirements are fully defined at the very start of the project, and the development is not commenced unless they are ready. Most likely, you will get a rather large document or a set of documents (artifacts).
We would like to expand on the second model in more details, which we have chosen to work with our customers. The Agile development technique suggests that the project should be divided into several short cycles of two or three weeks (iterations), and every cycle covers a mini-project with all required implementation stages.
In this case, the requirements are initially defined at a higher level, which enables first to sort out priorities and then to handle them in more detail at the beginning of each new cycle.
No matter which method you choose, be REASONABLE.
We are pleased to tell you how the product requirements definition process is organized in our company.
Things start with communication: it can be either oral (phone, Skype, personal meeting), or written. Anyway, results of such communication are recorded in writing.
We communicate with you on regular basis to find out your vision of the product. We do not force you to keep to some template, but rather find the way you feel comfortable. On our part, based on the information you provide we simultaneously draft a mind map.
Mind map presents a project’s general concept with the level of detail appropriate to assess the scope of works and sort out the priorities. In a conventional format, such a map is similar to a website map.
But we put a different logic into this notion: our mind map does not present pages, but functions grouped by modules pursuant to the logic of the work.
Mind Map Example:
As a result, such a map becomes a starting point for any further work (thus, being an integral part of the PRD). We approve a mind map with a customer and work on the project using it as a basis.
The mind map is only one of the examples of the product requirements execution. Nowadays, there are quite a number of various tools and practices.
Keep in mind, that you may learn BABOK inside out (a professional standard in the business analysis) and select all the best practices and tools related to product requirements, but they may turn out to be excessive for your specific case.
Based on our own experience, we have chosen the approach, which utilizes a required minimum of necessary tools. We use the tools, which are most effective in terms of a specific project. With the complete mind map in hand, as a rule, we continue our work using the following tools:
Example of Wireframe:
Example of Use Case:
What are the actions of the user who has found the required app to have his education document translated:
Example of ER Diagram:
This way, we collect and regularly update all information on the product requirements and the product itself. All the above diagrams and descriptions form some kind of PRD, as a guide for the developers and the designers in the process of the actual product development.
This is up to you to decide, which product requirements document example suits you. Just adhere to the following key principles when defining the product requirements:
and then, you may say that you have made the first move to a successful implementation of your project.
Still have any questions – contact Umbrella IT right now! We’ll be glad to share our expertise and knowledge!
Create long-term relationship built on result & experience.
Tell us about your business ideas and goals and we will contact you.