From requirements to final solution, what should product managers do? It has been recognized by many people, here, thank you very much for your support, but also gives the author a lot of confidence, the next article to share, I hope you can enjoy, enjoy ~

Product manager career, must have encountered the following pain points it:

1. You write a requirements document (PRD) and the developer leaves it on the shelf (10,000 horses galloping through the back of your head…) ;

2. Developers repeatedly confirm requirements, detail logic, etc., leaving you in a muddlehead and quietly correcting the document;

3. When the development is completed and entering the testing stage, I think a pot of fragrant rice is about to be served. When I open it, IT turns out to be a steaming pot of porridge.

The main culprit is of course your requirements document:

1. The document is not concise and clear, and it is difficult to read. Giving to development is like giving them sleeping pills.

2. The description of functional requirements in the document is not clear and the logic is not rigorous. The development needs repeated confirmation, which wastes a lot of time. .

3. The project is not closely followed due to the lack of good control over the schedule. Problems may occur in the middle of the project and the product is difficult to meet expectations.

So, how to write a good user experience, development like to read, reliable requirements document? The author will elaborate from the following aspects:

I. Product introduction

1. Briefly explain the use value of the product

  • Who am I (one or two sentences clear product identity)?
  • What use am I (what do I do, what service can I provide, etc.)?
  • Why choose us (compared with competitors, the advantages of our products, what is the core competitiveness)?

2. Target users and application scenarios

  • Who are the key users of the product?
  • What are the main scenarios for users to use our products?

Ii. Industry Overview

  • Brief exposition of industry status
  • Future trends
  • Analysis of competitors

Ps: How to learn about an industry quickly?

1. Check industry analysis reports through iResearch, Analysys and other websites to have a deep understanding of the upstream and downstream structure of the whole industry;

2. Analyze the business models of major players in the industry using the business model canvas tool

Three, version,

Classified by version, click the version link to enter and view the documents of each version.

The first page of the document looks like this:

(I) schedule

For each major release development, it is best to have a schedule (communicate with the developer to confirm the schedule), and adjust the schedule accordingly during the development process.

Developers can enter the scheduling details to view the tasks of the day according to the modules they are responsible for, and the completed modules can be marked, as shown in the figure.

(II) Product design (key points)

1. Entity relationship diagram

When you make the products from 0 to 1, in order to make database developers know your products more quickly, entity relationship diagram (e-r chart) will play a big role, database developers can refer to this diagram for the data table structure design (specific here would say, everyone can learn more about online e-r chart).

Manufacturers, dealers, customers, etc., all belong to entities. The attributes (fields) contained in entities should also be written out, as shown in the following figure for example:

2. User role permission table

For roles and permissions, you need to make a comprehensive role permission table for developers to refer to. liposuctioned

3. Business flow chart

Through the business flow chart, the overall logic of the product can be known in the general direction. The task flow chart can be obtained by disassembling the business flow chart, and the page flow chart can be obtained by disassembling the task flow chart.

4. Global description

Some generic controls, states, etc. do not need to be specified every time, such as empty data, network exception, load failure, refresh state, etc., only need to be specified once.

5. Description of requirements, functions and interactions

Many people always omit some details when writing function description and interaction description, and their logic is not rigorous. The following dimensions will give you a fuller picture:

  • Field, field description, data source
  • Preconditions, sorting mechanism, refresh mechanism
  • State flow (a page may have multiple states, need to be noted)
  • Interactive operation (normal operation, abnormal operation)

Below, the author will take a page as an example:

The structure of the product design module is shown as follows:

(For side view and comparison with visual pages, each page needs to be numbered)

(iii) Non-functional requirements

1. Buried demand

Page open rate, button click rate, etc., should be noted if necessary.

Burying point is the basis of data analysis, it is recommended to use the tool “GrowingIO” for visual burying point, simple operation, convenient, can reduce a lot of work.

2. Performance requirements

Request data response time requirements, concurrency requirements, etc.

3. Compatibility requirements

System version support, multi-terminal support, browser support, etc.

(IV) Modify records

The second page of the document looks like this:

In order to make it easier for developers to browse and enhance the reading experience, it is best to use Markdown language to assist in writing requirements documents, which will greatly improve the browsing experience.

Well, thank you for reading.

 

Author: Dreamer, wechat public number: fist product

Everyone is a product manager. Reprint without permission is prohibited.

Photo from Pexels, based on CC0 protocol