When it comes to product architecture, some people may find it unfamiliar, but when it comes to "technical architecture", they will be more familiar. Product architecture, which is similar to technical architecture in essence, is to complete the interpretation of business needs from the perspective of users. This article summarizes how to draw a product architecture diagram, let's take a look.
Have you ever encountered such a scenario:
Boss: We are planning to launch a new product recently, so you plan first, and we will discuss it later?
So, plan what? What are you talking about?
This is the topic we are going to discuss together today: product architecture diagram.
Speaking of product architecture, some people may find it unfamiliar, but when it comes to another word "technical architecture", most people will feel familiar. The technical architecture of
andhas completed the interpretation of online business from a technical point of view, and transformed the business needs of enterprises into achievable technical solutions, which requires both overall control and partial consideration. The product architecture of
andis essentially similar to the technical architecture, which is to complete the interpretation of business requirements from the perspective of users. With the help of a popular saying in technical architecture: all architectures that are out of business are hooligans, and so are product architectures.
1. What is a product architecture diagram?
1. Definition of product architecture diagram
product architecture diagram is the product manager's interpretation of business needs from the perspective of use, and it is a visual graphic for product managers to express their overall product design and planning. According to the strategic positioning of the product, the product manager presents the product function informatization, modularization and hierarchy, and shows the interaction relationship of different levels, the combination relationship of functional modules and the flow relationship of data and information, so as to convey the strategy of the product Positioning, business model, business process, and even development planning.
2. The role of product architecture diagram
From the definition of product architecture diagram, it is not difficult to see that the main functions of product architecture diagram are as follows:
a, determine the user role and demand of the product according to the strategic positioning of the product;
b, deduce product functions according to user needs;
c, coordinate and plan product functions;
d, support the output of technical operations and other links, and provide a basis for the output rhythm of others.
2. How to draw a good product architecture diagram?
To draw a good product architecture diagram, you need both overall thinking and consideration of details. This process will not happen overnight, and if you try to accumulate more, there will always be progress. Here is a summary of the six steps to draw a good product architecture diagram:
1. Determine product strategic positioning
Before drawing a product architecture diagram, you must first determine the product's strategic positioning. This strategic positioning may be given to you directly by the boss, or it may be confirmed by you based on the company's product portfolio, or it may be obtained by you through competitive product analysis.
Either way, you must first confirm the strategic positioning of the product, which helps us:
a, to ensure that the product is consistent with the corporate strategy;
b, to confirm the target group of the product;
c, to confirm that the product is consistent with other products or platforms
d, confirm the market positioning target of the product;
2. According to the strategic positioning of the product, determine the user role and demand of the product
With the strategic strategic positioning, you can determine who the target user of the product is, Are these users subdivided, and what are their needs? Give an example to explain:
For example: To C products, shopping websites, users are roughly divided into 3 categories: consumers who shop for items, merchants who publish products, and platform operators who maintain the operation of the website. These 3 types of users , Their roles are different, and their demands on the website are also different. Consumers need to search for products, view product details, complete product purchases, and manage orders (purchases); merchants need to publish products, decorate stores online, demand consultation and answer questions, and manage orders (sales) etc.; the needs of platform operators are different.
Another example: To B products, a bank's retail marketing platform, divided into: marketing planners, marketing supervisors, channel managers, system managers, etc., and their roles and needs are also different.Marketing planners need to complete customer analysis, customer group exploration, activity creation, activity evaluation, etc.; marketing supervisors need to approve activities and check activity execution status, etc.
(example: marketing platform function and role comparison table, part)
3. According to user roles and needs, business processes are sorted out.
determines user roles and needs, and the corresponding business processes are also presented. For each role, what work to accomplish and what functions are involved are easy to sort out.
For example, in the case of the ToB marketing platform, its activity process involves two roles: marketing planners and marketing supervisors.
(overall activity process)
under the overall process, sometimes may be subdivided according to the scene, the same function, in different roles, the requirements are different, such as the approval function:
(marketing planner)
(marketing supervisor)
The sorting out of these business processes connects the structure of the entire business line in series. The derivation of
business process is commonly used in the following ways:
A, deriving according to the business boundary, that is, a certain business is relatively independent, such as item search business and item order business in shopping websites;
B, Derivation is based on business scenarios. As shown above, this derivation method has high requirements for business precipitation and cannot easily cover all scenarios, but it is helpful to sort out the logical relationship between multi-roles and multi-functions;
C, according to roles The responsibility boundary is derived, that is, when one role completes one thing, another role begins to perform its duties, such as the common leave process and reimbursement process within the company.
4. According to the business process, deduce relevant functions
When the business process involved in each role is sorted out, we need to deduce what work the user needs to complete on each business point involved in each business process, What is the input and output, what kind of problems will we encounter, what kind of functions, pages or processing mechanisms do we need to support the achievement of user goals?
andare like this, and all the functions required by the business process are deduced in turn.
5. Aggregate functions to distinguish modules and levels
After completing function deduction according to business processes, it is not enough, and functions need to be aggregated. This aggregation can be divided into two aspects:
A, module for functions Aggregation
is aggregated by module, which can be a combination of different aspects of the same function, such as: approval function (the approval function of the approver and the withdrawal approval function of the submitter); it can also be different functions, according to business scenarios or business definitions The combination of functions combined with understanding, such as: the generation of "customer groups" in marketing, can be completed by various functions (list upload, tag circle selection, prediction model generation, external system access, etc.), these functions are combined into " Customers" module.
B, divide the modules into layers
After the functions are modularized, we need to divide the modules according to certain rules. There is no fixed standard for this division rule, and the common ones are: data layer, functional layer, application layer, user/terminal, etc.
(example: Yuanqi indicator management platform)
In actual operation, it is recommended to consider the following points:
A, clear structure layering (attention should be paid to both horizontal and vertical);
B, processing different information levels
C, dealing with the boundaries of sub-modules at the same level;
D, clarifying the boundaries between products (when combining products to form a product matrix);
6. Adding information flow mechanism
information flow mechanism is the last part of the product architecture diagram This step is also the most easily overlooked step. In addition to expressing the core functions, the product architecture diagram should also reflect the path of information flow: the current level or module data generates new data, and the new data promotes the generation of the next level or module data. The information flow mechanism of
andis usually represented by arrows, but there are also many hidden arrows for more obvious hierarchical relationships.In general, there must be a directionality of data flow, either from bottom to top, or from left to right, or from bottom to top, which partially includes left to right, etc.
(Example: Yuanqi Digital Construction Platform)
So far, the product architecture diagram has completed the transformation from idea to implementation, from business requirements to function realization, and the impossible becomes possible. At the end of the
article, it is mentioned that it is less and less likely for a single product to meet all business needs. With the deepening of the industry, more often it exists in the form of product portfolio or product matrix to form an overall solution. Provide customers with a full range of services.
Therefore, as product managers, we need to focus on system boundaries, contextual interactions with external systems, and joint efforts to form overall product selling points when designing product architecture diagrams.
This article was originally published by @产品路 on Everyone is a Product Manager. Reprinting without permission is prohibited.
title image from Unsplash, based on CC0 protocol