0-year-old product manager: How to write a requirements document

[[156712]]

As a new product person, after joining the company, the first thing you have to do is to write various documents. In my opinion, the most important one is the product requirement document. The English name of the product requirement document is: product requirement document, referred to as PRD. This document is one of the most important steps to transform a product from abstract to concrete, and it is also one of the "three steps" for technical personnel to understand a product in detail. The other two steps are product prototype and language communication, which will be discussed in detail in the next two articles. PRD is also a headache for many new product people, so how should PRD be written?

Understand the direct purpose of writing documents!

Generally, PRD is shown to the following three types of people: technical personnel, company bosses and customers. The target users of this article and the next two articles are technical personnel.

Now that the target audience is clear, what is the most direct purpose of handing the PRD to the technical staff? That is, after the technical staff reads the PRD, they will know what your product looks like. What effect will a good PRD have? That is, the technical staff only has your PRD, no prototype, and no language communication, and what he makes is still the ideal in your mind.

What should I write?

The above picture is a PRD I wrote for this article. It is a PRD for rapid prototyping software, similar to the mobile version of Axure. I personally prefer to use Axure to write documents, so that the product prototype can be directly embedded in it, which is more convenient and intuitive. I personally recommend using Axure to write PRD. Of course, the tool is only auxiliary. The quality of the document depends on the content. The masters can also write vivid documents using Word.

Let's get to the point: First, look at the content on the right. You only need to look at one point, which is [Document Version]: After a document is created, it must go through a process of continuous modification. After the modification, in order to let others clearly know the content you modified, you need to update your version number and write the date and the modified content.

Then look at the list on the left, which is the catalog. There are only three items, because I like the number three, which is simple but not simplistic, and makes it clear at a glance. Each item has four characters, because I have a slight obsessive-compulsive disorder, and I will feel uncomfortable if it is not aligned. And those who have used Wubi know that whether it is a two-character phrase or a four-character idiom, you only need to tap the keyboard four times to enter it.

The three items on the list are: [Project Overview], [Requirements Assessment], and [Phase Planning]. Some people may ask: Why are there so few? For those who can ask this question, first of all, you need to clarify the purpose of writing documents: as long as the technical staff can fully understand the appearance of a product, no one will say anything bad about you even if you only write one item. Let's give a counterexample.

The picture above is a requirement document found on Baidu. I looked at this document from a technician's perspective. After reading the first six items, I didn't even know what I was going to do. So what was wrong with it?

1. Can't get to the point quickly.
2. There is too much content that is not related to development.

So what is "non-development" content? I have seen: market research, competitive product analysis, user research, product values, and the development risk analysis in the above picture. The above content can basically be taken out and written as an independent document. Don't wishfully think that technical personnel will read these contents. I just want to say: I! Don't! Read!

How should I write it?

Now that we know what to write, let’s talk about how to write it:

Since I used to be an Android developer, I have a special liking for tablehost and viewpager, so I imitated them and made a Tab paging, as shown above.

Project overview, as the name implies, is to make people have a preliminary understanding of the product after reading it, and have a rough idea of ​​the product in their mind. Now that the purpose is clear, how to achieve it: first explain the user group. After the user group is clear, it is better to design and develop functions according to their needs, that is, user needs. User needs are often numerous and complex, and they need to be classified and then described in detail, as shown in the following figure:

User needs can be roughly divided into the following three categories: basic needs, expected needs and exciting needs.

• Basic needs are what we need to meet in the initial stage of product development, and are also necessary but not sufficient conditions for users to use your product.
• Expected requirements are the functions that users want you to add on the basis that the basic functions can be realized. They are also the functions we need to realize in the late stage of development and the early stage of operation.
• Exciting needs are things that users have not thought of, but you have not only achieved them, but also users really need them. After using them, users will feel excited and even recommend them to others. This is also something that needs to be done in the middle and late stages of operations.

However, in my past development experience, I have not seen any eye-catching features, which has to be regarded as a pity. Sometimes, PRD has guessed the ending after only looking at the beginning. This has to be regarded as the sadness of mutual imitation in the industry.

After writing the project overview, the general functions are clear in mind, so we need to make it specific, and the best way to achieve this goal is demand assessment, as shown below:

I only listed four examples in the figure. Of course, there are far more functions to be implemented in actual development. This table has three columns: requirement level, function name and function description.

I will just talk about the level of requirements: no matter what you do in life, the order is divided according to importance, and the same is true for development, so you need to add the level of requirements to the product functions so that the technical staff can clearly know the priority of development. After completing this step, you need to describe each function in detail, such as the drawing function and jump event on the left side of the picture. I will not put the picture for this, you can just write it according to the specific situation.

Basically, after writing the above content, your requirements document has been formed; if the technical staff still don't know what to do after reading it, it can only mean that your PRD is unqualified. But what should you do if it is really unqualified? What you need to do is not to change it. After all, if you can't even write it well, what can you change it to? What you need now is to remedy it! So how to remedy it? You need to write a stage plan, as shown below:

The so-called stage planning is to break down the development process of a product step by step, and explain in detail what the technical staff will do in the next period of time. If it is not clear with words, then use tools: for example, the most commonly used flowchart, you need to draw the logical order of your product clearly in the diagram, which should be concise and comprehensive. This is not contradictory. In addition to flowcharts, you can also use NS diagrams, PAD diagrams, and ER diagrams. You must remember that using tools is not the purpose, but the purpose is to use tools to solve problems. Basically, after the stage plan is written, the PRD can be finalized, and the next thing to do is to constantly modify the content as the requirements change.

This article is about to end here. If after reading this article, you still cannot write a document that satisfies the technical staff and the technical staff cannot understand your intention, then don’t worry, please wait for the publication of my next article. In the next article, I will teach you: how to use the simplest function in Axure to create a satisfactory product prototype.