The road to creating a good product: starting with demand to capture the hearts of bosses and users

Product Positioning

This is the direction of product design and the criterion for determining requirements documents and design outputs. In addition, product positioning also enables team members to form a unified goal and understanding of the product, improving team cohesion and work efficiency. It can be said that product positioning is a demand among demands.

So what is product positioning?

When some product managers communicate with designers, they often sort out the functions and business logic very clearly, but forget to clearly explain the main target audience of the product, their usage scenarios, and the functions and features of the product. This makes it difficult for designers to make decisions.

It can be seen here that product positioning is actually about the product's goals, scope, characteristics and other constraints, and mainly includes two aspects: product definition and user needs.

The product definition is derived by the PM, and user requirements are derived by the UED, but this generally only occurs in large projects or situations with sufficient team configuration. Actual cases are more often handled by the PM alone. Orz, what a great P (P) Zha (M)!

Among them, the main functions in product definition, product features and target users in user needs form the core content of product positioning, and are the most important basis and direction for product design.

Product Definition

A product definition is a sentence that summarizes a product. Generally speaking, it can be said that:

This product mainly provides XX functions for XX users and has XX characteristics.

There may be a question here, how to accurately describe some full-user products such as WeChat and Taobao? This is actually a small misunderstanding. For these products with a long history of development and major changes in business iterations and upgrades, the current ideology is no longer what it was at the beginning. Didn’t WeChat originally want to replace the function of mobile phone text messages? Therefore, the product definition will also be upgraded and iterated.

If your product is hard to describe in one sentence, it means that your positioning and direction are not clear, or you are creating a super product like WeChat that attempts to connect everything. For entrepreneurs, if you can’t even describe your product fluently and concisely, then your friends who follow you will seem to have more doubts about this leader.

For example: Momo

User group: Single people born in the 80s and 90s

Main function: Develop stranger relationships based on geographic location

Product Features: LBS search for users and groups

With a product definition, product managers can be forced to think hard about the product’s direction and opportunities, find differentiation in the competition, and limit the approximate scope so that the team will not be confused.

User needs

User needs are the target events of target users in specific scenarios. According to certain methods (brainstorming, research interviews, etc.), a schematic list of user needs can be obtained.

It is worth noting that user types are not absolutely mutually exclusive and independent, but are more differentiated by their main orientation, which does not affect subsequent screening and matching.

Among them, the target users are the most critical. Clarifying the target population can allow you to focus more on serving a certain group of people, which makes it easier to improve the satisfaction of this group of people and make it easier to differentiate and succeed in your products.

Products are for users and the money is paid by users.

Choosing which type of user to use as the target user requires a comprehensive consideration of the user's value to the company and the number of potential users.

Usually, priority is given to users in the upper right corner (with large potential and high value).

After determining the target user type, you can filter and match the corresponding scenarios and needs. The whole process involves a lot of thinking and decision-making, so product managers need to do enough preparation, including: understanding the results of market research (trends, related industries or product status), understanding the situation of similar products on the market (competitive product analysis), understanding the basic situation of potential users, understanding the strengths and weaknesses of the company and team, etc.

Demand Source

After determining the product positioning, we collect a large number of requirements through different methods, and then screen and match them according to the validity and authenticity of these requirements, product positioning and project resources, refine product requirements and define the excellent level. From product positioning to demand priority, the whole process not only involves the analysis and understanding of users, but also includes the consideration of product positioning and project resources.

The sources of demand can be roughly divided into the following types, among which competitive product analysis, product data, and user research are proposed from the product side, while the boss's keen vision is the result of "human" thinking.

After collecting a bunch of demands through various channels, it is impossible to meet all of them. It is necessary to screen out the most valuable demands according to certain rules and processes to maximize the limited input-output.

There is a more important link, which is also a test of PM's ability, to see the essence through the phenomenon and to explore the real needs of users (there is a classic story: Henry Ford, the father of automobiles, once had a classic sentence: "If I ask customers what they want, they always say they want faster horses.)

Here are two things to keep in mind:

1. Listening to users does not mean obeying them
2. What users want is not equal to actual demand

Requirements Document

After the requirements screening and priority definition, a list of requirements can usually be obtained, and the product managers responsible for each function can be tasked with writing PRDs (for general update and iterative requirements, there may be only one or two requirements after screening, and there is no need to define priorities, so you can start writing directly).

The following is an example of the content of a standard requirements document:

1. Document filing: includes information such as document date, version number, modifier, modification content and reviewer, usually in table form at the beginning of the document.
2. Table of contents: Easy to read
3. Background description: why to develop this product/module, market situation, business goals, product positioning, etc.
4. User type: briefly describe the target user
5. Project schedule: start, end, etc.
6. Information structure: simply understood as the hierarchy of content and pages
7. Business process description: Describe the switching logic between various business states in the form of a flowchart (for example, when the game server is full, it needs to switch to the queue login state) Detailed requirements description: Detailed description of each requirement (including: usage scenario, UI description, function description, priority, input/output conditions, processing flow, supplementary instructions, etc.)
8. Special memorandum is also required when it comes to support from related business departments.

Just like design drafts and codes, requirement documents are difficult to complete in one go and need to be constantly modified. It is normal to find problems during the review.

Demand analysis generally includes two aspects: demand acquisition and analysis and screening. Product positioning is the fundamental basis for determining product demand, and target users are the yardstick for product positioning. In order to obtain the correct demand, PM needs to participate in the whole process, be fully prepared, go deep into each link, and fully listen to the opinions of different members.

The above methodology is a standardized process. Different companies and projects will have more down-to-earth processes. This article is intended to share and inspire newcomers. The same is true for the writing of requirement documents. When I was interning at JD.com, I had some discussions with my mentor about the PRD template. The advice given by my mentor was: be flexible according to the needs and progress, and don't be obsessed with the so-called template. Especially in the era of mobile Internet. I just want to share this with you.