Why your startup needs Product Requirements Document
Do you want to save money launching your startup? Today I will tell you how to make this venture less risky than it really is.
Have you ever heard about Product Requirements Document?
If no — it’s time to read this article more attentively.
If yes — there is still a bunch of useful tips for you below. Keep scrolling.
What is PRD?
Product Requirements Document describes the product your company is going to build. It drives the efforts of the entire team: design, development, sales, marketing, and customer support. It’s hard to come up with a more important piece of work for a company. Well written PRD will save you time and money in future. Because the more blind spots you have in your product vision, the riskier your startup will be. Facing problem (or even potential problem) points in the very beginning costs you nothing. But facing such points after weeks or months of development can cause a lot of problems or even the crash of your company.
„The more blind spots you have in your product vision, the riskier your startup will be.“
The purpose of the PRD (sometimes called the Product Specification) is to clearly and uniquely identify the product’s objective / features / functionality / behaviour. Product team will use this document to actually build and test the product, so it needs to be complete enough to provide the information they need to do their jobs.
But, don’t confuse PRD with Technical Specification (or Software Requirements Specification). PRD contains the high-level product requirements, whereas TS provides execution-level detail of how the requirements are actually going to be implemented.
If the PRD is done well, it still might not be a successful product, but it is certain that if the PRD is not done well, it is nearly impossible for a good product to result.
How to write a good PRD?
Ok, now you know what the PRD is. The next questions — what's an effective workflow for writing it? In our company, we use SVPG workflow (the link in the end of the article). I have to say it works pretty good. Let’s go point by point, diving into Product Development.
1. Research (preparatory part)
I think it’s not a surprise that everything what you do, you need to start from a research. Make a market research: study your customers, competitors, as well as your team’s capabilities, including available technologies, etc. A significant factor in your ability to convince the team of the product’s eventual success is the degree of confidence you project, and you will be more confident and more convincing if you’ve done this part well.
2. Define the Product’s Purpose
Every good product starts with a need that it is trying to fill. You must have a clear understanding of that need, and how your product addresses that need. It is essential that the product manager establishes a very clear, brief value proposition that lets easily communicate to everyone: from team members to company executives, from customers to sales forces.
3. Define the User Profiles, Goals and Tasks
User Profiles — classify the types of users and customers, and determine who the primary users are. Try to characterize them in considerable detail, so that you can use these profiles to guide you in the design of the product. These profiles are sometimes called “personas” and while they should be fictitious, they should be as representative, realistic and plausible as you can make them.
User Goals — once you have identified and characterized the main types of users, then you need to identify what each user’s main goals or objectives are in using this product. This may sound simple, but it can often be challenging to untangle the underlying problem to be solved. The objectives may be different for each user profile, so it is important to be able to look at the objectives in terms of the profile they relate to.
Tasks — the tasks that help users accomplish their goals. This is the heart of the product specification process, and is the place where creativity and innovation have to be encouraged as much as possible. Many outstanding products simply solve an existing problem in a new and better way. Sometimes this comes from the technologies, but mostly it comes from an insight that leads to a new approach. Also, there are good reasons to eliminate any functionality you can in the name of making the required functionality more accessible. Ironically, the fewer features you have, the more powerful your product is often perceived.
4. Define your Product Principles
In all teams, each member has some ideas in his head in terms of good principles for the product, but rarely do two people have the same ideas, and these differences can lead to unpleasant surprises later. It is very valuable to identify a set of product principles that will guide the entire team throughout the project. These principles will be specific to your domain and your particular project.
E.g. eBay the mantra was: 1) easy to use; 2) safe; 3) fun.
For Apple it could be: 1) design and simplicity; 2) smoothness and gentleness; 3) user’s privacy.
Product objectives like these can provide a constant compass for the entire product team in the many decisions they must face along the way.
5. Identify & Question Your Assumptions
Once you think you understand the problem you want to solve, now is the time to start identifying and questioning your assumptions. It is very easy to make assumptions and not even be aware of them. Make sure you don’t specify a candle in the PRD and prevent yourself from getting a light bulb. Astronomy was originally defined as the study of how the sun and the planets revolve around the earth. Its very definition had an assumption that prevented anyone from getting the right answer.
6. Write It Down
Most PRD’s are simply Google Docs, but some are Wiki sites, some are PowerPoint decks, and some live on whiteboards. The media and format are far less important than the content. Although what is critical is that the PRD is something the entire team can easily access, it won’t get lost, and that the PRD needs to be in a form that can be updated throughout the project. Remember that a conversation is between two people. PRD connects the entire product team.
7. Prioritize
Beyond clear requirements, it is important to prioritize and rank-order every one of your requirements. Most product managers indicate whether a requirement is “must-have”, “high-want” or “nice-to-have”.
a) Must-have. You should have an extremely high bar for anything flagged as “must-have”. This literally means that the product should not ship if even one of the “must-have” features is not ready. So extreme care should be used for any feature marked “must-have” and these features should map directly to the core value proposition of the product.
b) High-want. These features are important, and you want all of these in the product before shipping if at all possible. But you are not willing to delay the product for these features.
c) Nice-to-have. These features are useful for the product team to be aware of, even if most of them do not get built until a future release. At least, the product can be architected to handle these features, where appropriate, in the future.
8. Test Completeness
Now you have a draft of the full PRD. You need to test the PRD for completeness. E.g., can an engineer get enough understanding of the target in order to get the product there? Or can the QA team get enough information to design a test plan and begin writing their test cases?
Once the stakeholders have all reviewed the PRD and identified any areas that need additional details or clarification, and you have addressed these issues, you now have a PRD to build a product from.
9. Managing the Product
During the product implementation, there will be countless questions identified, even with the best of PRD’s. Resolve all questions about requirements by pointing people to the PRD. If it’s not in the PRD, put it in the PRD. Your job is to quickly resolve all the questions and issues, and record these decisions in the PRD. You may find that you need to cover additional topics in the PRD. If you believe something additional is required in order to meet your objectives in the PRD then, by all means, include it.
If you’ve done your job and kept the PRD accurate, any project reviews that come up should be very easy to prepare for by just selecting from the appropriate sections of the PRD.
Remember that the PRD is a living document, and you should track all features in the PRD through product launch.
In the end, I would like to say, that the amount of time this process takes depends greatly on the size and complexity of your product. And, certainly, how prepared you are in terms of knowledge and skills. If you are just a beginner, follow this workflow, it will guide you to good results. Experience has proven.
Also, I’m attaching some links that can help you to write your amazing PRD.
Useful Links
- Silicon Valley Product Group workflow - the doc with detailed workflow how to write PRD
- Product Hunt's PRD - example of good PRD
Hope, this article with a small list of tips will help you to create your perfect Product Requirement Document and save you time and money.
If you have any questions and suggestions - feel free to write us.
Good luck and let the clear PRDs be with you ✌️