These ten steps to do a good job in the product requirements document are obtained through long-term practical experience and repeated verification. Maybe the description here is not very comprehensive, but it is enough for you to make a successful product requirements document. The time spent doing these steps depends on the size, complexity, individual knowledge, and proficiency of basic skills of the project.
Step 1: Do the prep work
What you want to do is an undisputed product, and in order to do it well, you must do the preparatory work. You need to understand the strengths and skills of your customers, competitors, product team and need. You need to collect problems and possible solutions from customers, users, competitors, analysts, product teams, sales force, marketing, company employees, etc. There is a lot of work to be done here, which is described in detail in the article "Behind a Successful Product".
Establishing good communication is also very important, it affects the product team. If you prepare well enough, you will also become more and more confident and persuasive.
Step 2: Determine the purpose of the product
Any good product starts with a need. You must have a clear understanding of this need and how your product will meet this need.
Product managers need to come up with a clear and concise value proposition, make it easy to accept, and let product teams, managers, users, and marketers clearly understand what the product is intended for. While this sounds simple, only a few products have such a value proposition. Consider the "velevator pitch" (elevator pitch, elevator marketing) test. Suppose you are working on an elevator and you meet the CEO of the company and he asks you what the intent of the product is, can you answer that question before the elevator arrives? If not, you still have work to do. Maybe your description is not targeted, he may show no obvious difference from what other products do; maybe your point of view cannot resonate with your users; maybe you solve an unconventional problem, maybe you want to Apply a technique. This value proposition may need to satisfy the company's product strategy. Note that you don't need to go into too much detail, and in some ways, a valuable point is that the simpler the better.
Product requirements need to specify exactly the goal of the product release, and the same goal has priority. For example, your goals might be: 1) ease of use, 2) retail price under $100, 3) good integration with previous products. Then you need to explain how to measure it. For items like "ease of use", you need to clearly indicate that the product has a certain level of usability. This is usually defined by the target user. Usability engineers can measure the usability of your product to target users and the severity of usability problems, and you can also show that there are no major usability problems.
The key here is to let everyone know what the product looks like when it succeeds, and to give the product team guidance on how to make trade-offs when it encounters problems in design and implementation.
Step 3: Identify User Archetypes, User Goals, and User Tasks
Now that you understand what problem you want to solve, the next step is to get to know your target users and customers. In this step, work closely with your PD (Product Design) Contact is very important.
User Prototype
At this stage, the PM needs to communicate with many users and spend a lot of time directly observing and discussing. Now we need to categorize users and customers and decide which category is our primary user.
For example, if you are doing an Internet auction service like eBay, you have buyers and sellers at the same time, among which there are users who use infrequently and users who use frequently. It is not difficult to imagine that there are individual special users, such as groups corporate buyers.
PM (product manager) and PD (product design) need to first determine the type is the most important, and then try to describe the characteristics of this user group in detail, in order to use this model to guide product design. This model is often referred to as a "persona". Though imagined, it should be typical, feasible and real for you to use. The idea came from a prototype that represented the essence of this type of user.
Case in point:
"Lyon is a super seller, 46 years old, male, living in Fresno, doing scooter accessories. Although he runs a small shop, most of his business comes from Ebay, averaging more than 400 per month Deal. He sells a wide variety of things, but his most popular item is Harley-Davidson load bags. He owns two Harleys himself and drives a 1993 Toyota pickup. Lyon is married and has two kids .Lyon
buys the computer simply because he needs to use eBay and rarely uses anything other than eBay and email.Lyon has been selling products on eBay for three years now and he has learned what he should master on eBay and he is very proud Has more than 5000 credits. If Ebay changes the website, especially the process of selling, it is very difficult for him to change his habits and learn these changes. Lyon has formed his own habit of listing items for sale on Monday, The auction ends on Friday, trying to get it shipped within hours of being paid for."
Hopefully this description will give you a sense of Leon and how he got here. When we think about new features, I have to ask myself how Leon will react and what do we need to do in order for him to use this feature smoothly.
Take care to narrow it down so that he only depicts the essentials. Satisfying everyone is futile, and usually no one will be satisfied in the end, so it is very important to try to come up with a few of the most important and popular character descriptions. Likewise, if you don't pinpoint your target audience, you'll have only vague concepts, and you'll find it very difficult to understand your users' reactions. You want to lean towards assumptions that make you more like your users.
User Goals (User Intentions)
Once we have identified and profiled our main user types, we need to find out what the users are aiming for in using the product (what they want to do). This sounds simple, but unraveling the underlying problem is very powerful Challenging, especially when the people around you tell you that you have solved what they want.
From CEOs, sales reps, engineers to customers, everyone is too excited to help you find a solution to the underlying problem and will tell you to add a shortcut button somewhere, or add a feature just because a competitor has , or change to their preferred color.
The best solution depends on having a clear understanding of what problem needs to be solved. Each user model may have a different purpose and needs to be looked for in the aspects covered by the user archetype. It is possible that in the future the problem that a feature solves is not one of the goals that the main user needs to achieve.
User tasks (tasks, the tasks that users need to do in order to achieve their goals and use the product) have
mastered the user prototype and their goals and aspirations, and we begin to design tasks to meet their goals and aspirations, which is the core part of the product production process. , but also where creativity and innovation are stimulated.
Many excellent products are simply solving an existing problem with a better and newer solution, sometimes just applying a new technology, but most of it comes from deep insights that lead to a new approach. For example, TiVo (the No. 1 digital video recorder in the US) has come up with a whole new approach to the old problem of TV recording, making it easier for customers to achieve their goals and creating a whole new category of electronic equipment.
Note that although we have talked about goals and tasks, we haven't talked about specific functions that are necessary to achieve user goals. You'll find that many features are low-priority or completely redundant.
Many functions can be excluded on the grounds of "must function". Ironically, the fewer features you use, the more powerful your product is found to be. This is because the fewer features your product has, the more features your users will discover and use, and the more features you use successfully, the more powerful your product will be. These reasons are counter-intuitive, and most of us can't be like our users, who in our own industry are willing to spend more time exploring features and tolerating complexity than users.
Step 4: Define Product Principles
Now you need to start defining your needs and user experience into detailed requirements. While you still face many decisions and tradeoffs, it is important to make the best decision for your product standards.
In most product teams, everyone has the principles of making a good product, but rarely two people have the same idea, and these differences can lead to incredible results.
It is very valuable to try and develop a set of product principles that guide the whole team, and these principles need to be specific to the domain name and project.
Using TiVo as an example, at the beginning of the product team work, the following product specifications are established and communicated within the team:
1. It's entertaining
2. A dumb TV
3. A damn video device
4. Smooth and supple
5. No patterns and depths
6. Respect the privacy of the viewer
7. As powerful as TV
These norms greatly influence the definition of products and make it difficult to a large extent, but they are the source of successful products. For example, eBay's slogan is: 1. Easy to use 2. Safe 3. Fun.
It will guide you when making decisions in the face of many problems in the project.
Step 5: Product Prototype and
Inspection The stage of an idea, where creativity and innovation come to fruition.
A common mistake many people make is that they are too confident in product design specifications, and as a result they have to tweak the product once it gets beta tested. But certainly beta testing isn't the time for major changes, so many first-releases are too far off the mark.
For many products, this is a time when you can do a lot of experimentation with a lot of prototypes. First, the following three very important tests you may need to do
Feasibility testing
An immediate question is whether the product can be developed, and your engineers and designers should be involved in technical feasibility studies and exploration of available approaches. Some approaches won't work, but it's very promising that others will work.
Engineers will find it impossible to get past a certain stage of the product, and it is better to know now than later.
Usability Testing A
product designer will work closely with you to come up with product features and make them adaptable to different users. Usability testing often finds missing product requirements and confirms whether the product's original requirements are necessary. It takes a little more testing work before you can come up with a successful user experience. The purpose of usability is to test on real users, and testing to get quality feedback from the target users of a product is very art and science. Of course product managers and product design will imitate usage, but the reality is that no one can replace real target users.
Product Concept Testing
is not enough just to be usable and feasible. The real question is do your users want to buy - how much your users like it - and what's the value in what you're doing. This testing may be tied to usability testing.
For some small products, your ideas on paper are enough, but for most products, complex user interactions or the use of new technologies, some form of prototype are very important in order to predict whether the product will achieve its goals.
A prototype might be a physical device, or it might be a preview version of a software product. The point is that it needs to be realistic enough that you can test the prototype on actual target customers and they can give you quality feedback.
There were two main obstacles to prototyping. The first is the lack of good prototyping tools, and it takes a lot of time to make prototypes; the other is that the management does not know the difference between the prototype and the real product, and in unpredictable circumstances, the prototype is required according to the final product.
There are excellent prototyping tools available today that allow engineers or designers to quickly create prototypes that can effectively simulate future products to the extent necessary for actual users to test. And most managers know the difference between imitation and reality—just like a scaled-down model of a house and a real home.
It is very important to test your product before actually making it. Once the actual engineering begins, it becomes very difficult and expensive to make important changes.
When you think you figured out what you need to solve, it's time to start verifying and questioning assumptions.
It's easy to assume or even to be ignorant, but don't use unknowable conclusions as a guideline, as that can get in the way of your success. Astronomy, originally defined as the study of how the sun and other planets revolve around itself, is an assumption that prevents people from getting the truth.
Step 7: Write
Of course you need to write all this down, most PRDs are word documents, but some are help documents, PowerPoint, or written on white paper. Of course, the format used is not very important. What is important is that the team can easily understand the function and not miss it. Also, the PRD can be updated as the project develops.
Remember that the conversation is between two people, but PRD is about communicating the whole group. You also have to remember that getting sales of the product is what matters, so don't worry about what looks good, how thick the PRD is written, as long as it's readable, understandable, and what's needed.
The PRD document consists of four main parts
Product purpose
Your job is to point out the goals, the team needs to know what their goals are, the goal statement should be as clear as possible, please make sure your content includes:
* Those problems you want to solve, not The solution
*who is the target user
* has a lot of details, but the big picture must be clear
*scenario description
More brainstorming sessions and impromptu oral discussions, so that it can be written better and will give the team a deeper understanding.
Product Features The most important part of the
product requirements document is, of course, the requirements. The exact requirements will depend entirely on your domain, but no matter what industry you are in, your product teams will benefit from clear, unambiguous requirements that state requirements, rather than vague solutions.
Describe the interaction design and use case for each feature. You have to be very clear about each feature and user experience, and you need to leave enough flexibility and autonomy for the engineering team.
It is also important to determine which purpose those requirements serve. Here we need to mention "requirements tracking", which is an important process for key products. Each product specification may benefit from clearly identifying which purpose those requirements serve, and if someone decides to cut requirements, it can be very difficult to gain insight. A clear statement from requirements to purpose would make the documentation clearer.
Release Standards
Release standards are often constantly changing, but a good PRD should allow for a minimum requirement for each standard. Typical examples are: performance, scalability, reliability, availability, controllability.
Time Schedule
One of the hardest problems is describing the time schedule required for the product. It's useless to list a random date, you need to describe the circumstances, motivations, projected goals. You need the entire team to achieve the same goals as you, and ultimately complete a successful product.
Step 8 Prioritization
In addition to clear requirements, it is important to prioritize and prioritize each of your requirements.
Most product managers , if they give priority, generally indicate whether the requirement is a "must have," "important" or "wish to have" (or some other classification system). Classification is important and should not be taken lightly. A label "must have" needs to have a high standard. If the must have function has not been found, it means that the product should not be produced. So be careful to mark the "must have", these marked "must have" functions directly reflect the product. Core Values.
"Important" classification is also important, to fulfill these features whenever there is a chance before the product is sold.
"Want to have" product teams should also note that even if most of them are not implemented, it will be appropriate in future releases Do it slowly.
These are sometimes not enough, and it is important to prioritize each category from 1 to n. There are several reasons:
First, time-to-market is always a concern, and schedules often drop, and you may be forced to cut some features in order to get to market as quickly as possible. You also don’t want the product team to develop simple features first and relax important features, leaving the critical features that customers use in the end unfinished.
Second, during the product design and development phase, the team will find that more problems arise and resolve them, so it is likely that more critical features will emerge. Prioritization can help you balance to accommodate more features.
This is to say that how product managers do not give priority and importance levels, other less relevant factors will follow.
The whole PRD is a process of continuous improvement and thinking. A clear and sharp product is a successful product, and a vague one is a failed product. It also makes it easier to make decisions during the heat of the debate and helps engineers plan.
Step 9 Test for Integrity
Now that you have a draft PRD, you need to test its integrity. Can the engineer fully understand and achieve the goal? Does the OA Team (Quality Management Team) have enough information to make a test plan to start making a case?
When the investor or related person has reviewed the PRD, identified various aspects that need to be explained, and all the problems have been solved, you can now carry out product development according to the PRD.
Step 10: Manage the product
During product implementation, even the best PRDs have countless problems that are solved. Solve all problems in PRD, if not in PRD, write it. Your task is to quickly resolve the issue and document it in the PRD.
If you have done your work and are ready to document it in the PRD, the project review becomes very simple, because every part is visible.
Remember that a PRD is a "living" document that tracks all functional progress during product development. In the end you'll find a lot of extra stuff to write in the PRD if you think it's necessary.