The goal of the product requirement document is to describe the product you are building. It helps the product team as well as the sales and marketing department to piece together the puzzle. Customer support also heavily relies on the specs to explain to the clients the features and updates of your product. This piece of work is a vital part of any company in technology business as its main purpose is to state the purpose, functionality and product features clearly. For example, on its basis, the product team will build and run tests. Therefore the end result of the writing process should be precise to allow them to do their job without second-guessing.
Product requirement document doesn’t guarantee that your product will sell. But we are certain that if the specs are poorly done, it would be much harder to see good sales results.
Product requirement document vs. Product Strategy and Roadmap
According to Martin Cagan of Silicon Valley Product Group, and his “How To Write a Good PRD” you need to clearly understand the terms before proceeding as they are too often mixed up. Products specifications describe particular product features and usability. Product strategy, in turn, takes care of the long-term vision describing it. And product roadmap lays out the steps to achieve your goals. You can read more about the product strategy and roadmap creation at http://www.svpg.com/assets/Files/goodprd.pdf
When we talk about “product requirement document writing guide” the majority of people start to groan when they hear it. People believe it’s all about writing complex docs that no one ever bothers to have a look at. Most companies place agility first and don’t overburden their staff with documentation. After working in eCommerce business for over a decade, it seems that this view is misguided.
Let’s have a look at an example of product requirement document
Supposedly you work at a company similar to Booking.com, but smaller. You need to boost your checkout conversion which is extremely low, and after a brainstorm session you want to try to use live-chat feature during the checkout process.
Your hypothesis says that by adding live-chat you will increase conversion.
The industry standard CR is 30%, and with a checkout conversion below 10%, you have no choice but to try. So you plan to test it on a limited number of customers to see if it works.
So you decide to jump start the process without any written specifications, because the action is of paramount importance and wasting time on specs is costly. You start by holding a talk about this issue with the team, and you decide to kick off the work by choosing a chat vendor that can do things quickly. In the next step, you ask your developer team to write some extra code to account for this new function and meet with the support team to ensure that they understand the task.
Everything is set and ready to go. So why do I assure you that specs are a must anyways? The thing is that when you’re just starting to grow and your team is small, you don’t have to worry that much about specs. There are fewer people and parts in the puzzle. But if you have a larger company, things can start to go wrong quickly, as more and more details appear in the process. And, of course, trying to address them on the go will cost you more. For example:
Developers finalized all the processes for live-chat checkout, but then you realize that it works only on desktop and more than 50% of your customers come from mobile. So you forgot to emphasize that the mobile version is key and now the process to implement in will exceed the deadline.
The next issue is that customer relations specialist that works on live-chat want to review all live-chat vendors to suit their needs. So you have to hold one more meeting and explain that this is only a temporary test to prove the hypothesis.
You senior designer spends valuable time perfecting the live-chat animation. So you forgot to set proper expectations, and the company has a backlog on hands of more important issues.
Just after the launch, your support specialist sends you an urgent message saying that are getting customers in live-chat speaking foreign languages. Now you have to run to your developers and request an immediate update to limit chat to English only.
And finally, after testing the hypothesis for two weeks, you come to realize that you can’t create the report as nobody took the time to log metrics. So you have to do it all over again.
As seen from the example above, without well-written specs you will have a disaster in a relatively simple project. You are very likely to waste time and resources.
To stay on top of the game, you need to consider some key elements for a good functional spec. Below are the bullets to get the general idea of the issues you will be faced with when writing product specs.
Top Highlights
- Product vision
- Proposed solution
- User needs
- Product value
- Use cases
First of all, you need to ask yourself some basic questions. By answering them, you will come to realize that without writing a product requirement document you won’t be able to set up a fruitful work in your office:
- What is the product vision?– This question incorporates the aim of your product or service, the overall objective from a business point of views and the ways your product is going to be different from similar ones.
- What does the user need?– In this question, you have to answer whether your product serves the needs and solves user problems. You should also elaborate on the ways you expect to engage users with your product.
- What is the product value?– Try to identify the value of the product to your business and its value to the customers.
When you think about these issues, it becomes apparent that a simple oral description without well-written product specs will do your business no good. You need to write them out point by point with utter precision and high readability for people to comprehend them easily.
Writing the product requirement document
If we go into detail, there should be a clear guide to help you deal with major issues in your specs.
- Record a problem statement on paper. In this part of the product specs, you should explain the issue you have dealt with in simple terms. There is no need to offer a solution to this problem right now. Your team has to get a clear grasp of the issue first.
- Propose a solution. In a few paragraphs briefly describe the solution to solve the issue at hand.
- Justification from a marketing standpoint. You need to know the size of the customer base that can be faced with this problem. Explaining why fixing this issue would make a difference.
- Describe the target audience. In the next paragraph or two, you need to define the typical users. They can either be internal or external, experienced or new users.
- List minimum requirements to succeed. Devise the requirements in cooperation with your Product Manager, Engineers/Developers and Customer Support Department. You have to make sure that all issues are accounted for as the problem will otherwise remain unsolved. Remember that the primary intention is to solve customer problems and meet expectations. Number the points so that they are easy to refer to.
- List non-obligatory requirements. These requirements would be implemented only upon successful testing. Nevertheless, you should note them so that all the departments are ready to implement them in due time. Of course, if time and resources permit, you should try to implement these points in the testing of the current release. The most important part is that all departments should agree that these changes can be implemented and supported in the future.
- Set goals on redesigning user interface. In this part of the specs, you need to decide with the help of the designers’ team as to how the user interface will look like, and what kind of interaction have to be present to boost customer experience and usability. The best thing is to leave this part for the engineering and design so that they can write up all the UI process accordingly.
- List common use cases. In this last part, you need to focus on common use cases. They should be accounted for by the new version of your service pack. Here you should ask QAs to offer test plans for these use cases.
In conclusion
Thank you for reading about the best ways to write a great product requirement document! Feel free to share this blog-post with others in your community. Keep up the good job of improving your product and don’t forget to write down all the details. As you’ve come to know, this really helps!
