Different professions have their own different ways of thinking and habits, and these combined, the so-called "experience", will determine the level of a person's level. In this article, let's take a look at the 6 thinking patterns of B-end products shared by the author for your reference.
Thinking and logic is one of the important criteria to measure the level of a product manager, and the commonly used indicators to evaluate the ability of a product manager are product thinking, user thinking, logical thinking, and data thinking......
So how to understand "thinking"?
Personally, "thinking" refers to the process of analysis, synthesis, judgment, reasoning and other cognitive activities on the basis of appearances and concepts.
A very important job that product managers do most of the time is: product design, especially in B-end systems, often do not know where to start in the face of extremely complex business logic and peripheral systems and multi-layer architecture, and novice product managers are easy to ignore the early thinking and directly draw prototype drawings, the consequence is that the prototype drawings are extremely slow, and even easy to modify repeatedly, easy to ignore logic and details, causing project delays, and I was the same at the beginning. Later, after having a certain amount of experience in making products, I established my own set of design thinking, learned to sort out the business, architecture, and process, and had the ability to undertake the changing and adjusted needs.
This article summarizes some design thinking, which are contextual thinking, minimalist thinking, abstract thinking, closed-loop thinking, building block thinking, and pipeline thinking.
1. Contextual thinking
Contextual thinking is to be able to analyze, disassemble, and refine a complex and chaotic business, and know clear functions. Here's how:
1) Demand concretization
When the business side puts forward a demand that is difficult to implement for a while, there is no need to panic, you can trace the background of the demand with the business side, understand the demand thoroughly, and it is best to summarize the demand in one or two sentences until you understand the ultimate goal of the need.
2) Logical stratification
If the business involves multiple systems, do not mix them up, first identify and clarify the core logic of the business, which is the central nervous system of the entire system. We should start from the core logic, gradually sort out the interaction relationship of each system, and divide the boundaries and levels of different systems.
3) Scene decoupling
When the business is complex and involves multiple roles and scenarios, it should not be confused, but should be decoupled and divided into different scenarios corresponding to different function points.
After the system is decoupled, the logic is clearer, the system complexity is lower, and it will not involve the whole body, for example, the inventory counting function in the warehouse management system often makes mistakes, because the inventory clerk, the inventory supervisor and the warehouse manager are all operating in one page, the inventory clerk makes the inventory plan, the inventory supervisor is responsible for the processing and submission of inventory differences, and the warehouse manager is responsible for the inventory review. Due to the sharing of pages and the lack of authority control, the relevant personnel often misoperate, and the inventory clerk accidentally misoperated the inventory discrepancy processing and inventory review.
Later, the product manager divided the inventory function into three parts, and disassembled it into three pages: inventory plan, inventory discrepancy processing and inventory review, as shown in the figure, through the menu to manage the rights of the inventory manager, inventory supervisor and warehouse manager, and there has been no misoperation since then.
2. Minimalist thinking
The road to simplicity, beautiful things are often simple, in the product design as much as possible to pursue minimalism, minimalist process, minimalist interaction, minimalist design can reduce development and maintenance costs, higher fault tolerance, improve user satisfaction.
1) Pursue process simplicity
The design should focus on the core logic, and simplify the process as much as possible to ensure the realization of each logic and business function.
2) Pursue architectural simplicity
In the B-end system, if there is more interaction between upstream and downstream systems, the interaction between systems should be minimized, the complexity of the system should be reduced, and it can also be easier to maintain and expand.
3) Pursue minimalist operation
In the function operation, the operation steps are minimized, the system can automatically never be manual, and each function can be reduced by 10 seconds per operation, which can help users save great time and cost over time.
4) Pursue page minimalism
The page should be clear in priority and priority, follow the visual and design principles, the core part should be placed in the core page area, reduce and shorten the text description, the text is not as good as the picture, the picture is not as good as the table.
3. Abstract thinking
Abstract thinking is a kind of thinking that can refine the commonality and relevance of things, which tests the probabilistic ability, reasoning and judgment of the product manager.
If most of the functions of the two business scenarios are similar, but only a few are different, we can abstract them into a common underlying function (root) and expand different business logic (branches) on this basis, instead of designing a separate set of functions for each scenario and quickly connecting to other services under the premise that the core logic remains the same.
Inventory is the core logic of the supply chain, and almost all supply chain business development will lead to changes in inventory, procurement warehousing, sales warehousing, user returns, supplier returns, inventory, ...... If we need to adjust the underlying logic of inventory in the warehouse management system and central inventory system for each additional business, it is simply unimaginable, once it is not handled well, not only can it not provide support for new business, but also affect the business that is already running because of the core inventory logic, which is very risky.
Through analysis, we found that the essence of all businesses is nothing more than adding inventory and reducing inventory, and the difference is only the form of business development. Therefore, we abstract the processing of inventory into the core logic of adding and subtracting the underlying layer, provide standard services externally, and extend a layer of business access layer on top of this for business docking, as shown in the figure. In this way, the underlying inventory service only needs to process the addition and subtraction of the quantity, and will not be easily changed, no matter how the upstream business changes, it only needs to be adjusted in the business access layer, and will not affect other businesses.
Fourth, closed-loop thinking
Closed-loop thinking is not as lofty as it sounds, but it is very common in the work, in the early stages of project and business implementation, decision-makers often think about how the current project can push back and force the development of other businesses, and product managers should also have closed-loop thinking when designing systems.
1) There is a beginning and an end
Carry something through to the end. When a process node starts, there must be a corresponding end node, and adhering to the principle of who initiates and who ends, the initiator of the process should also be the final end party. For example, if the procurement process is initiated in the procurement management system, and after the final goods are put into storage, the procurement management system needs to be notified to inform that the order has been put into storage, and the procurement management system will complete the procurement process.
2) There are back and forth
We must not only consider the positive process, but also design the corresponding reverse process and abnormal process, both operation and state, and we must not go back and become a dead end. For example, the forward process of a consumer placing an order from a mobile phone should also correspond to the reverse process of return.
Fifth, building block thinking
Building block thinking is the mainstream middle-platform design idea, which is in line with the concept of Service Oriented Architecture (SOA), which requires us to fragment system functions and reassemble them to empower new businesses.
The design of the B-end system should be the same as building blocks, simplifying the huge and complex process, first fragmenting into services that can be used independently, and forming our building block box through continuous precipitation, when there is a new business access, we will extract the corresponding building block from the building block box, reassemble it into a module needed by the business like building blocks, and quickly adapt to the new business.
Example—Customer ExchangeWhen the customer exchange business is connected, we have analyzed and learned that the timing of pre-sales exchange is before the order is shipped, and the time of after-sales exchange is after the order is shipped. However, through module assembly, we only need to splice the cancellation order service and the order service to achieve the pre-sale replacement business, and the return order service and the order service can be spliced to achieve the after-sales replacement business.
Sixth, pipeline thinking
Pipeline thinking is an open and connected thinking, connectivity generates value, and the system we design should be based on the present, look to the future, and have the ability to connect with the outside world. The supply chain is all about collaboration, and the design of the system naturally needs to be open enough to facilitate the connection with the outside world like a pipeline.
How to open it? There are several ideas:
1) Open functions. When designing with a certain requirement as the starting point, consider whether this function can support the development of other services, and if there is a possibility that other similar services will occur, then you can reserve the interface in advance.
2) The interface is open. When designing a new system, we should think about collaboration and connectivity with other systems, and open up our own data, services, software and hardware interfaces for external systems to access, so that data can flow freely and generate value that cannot be achieved by a single system.
3) Business opening. When realizing the functions of the company's internal business, we should consider whether it can empower external business in the future. For example, the opening of fulfillment, procurement, inventory, warehousing, and distribution capabilities to the outside world, and the opening of systems.
Pipeline thinking can make the system more flexible and scalable, laying the foundation for future business expansion.
Considering the future development of business, warehousing may have two business transformations: one is to access automation equipment to improve the efficiency and accuracy of warehouse operations; The second is the opening of warehousing to the outside world, and the introduction of third-party warehousing business warehousing operation. When product manager A designed the new warehouse management system, he reserved two "pipes" in advance:
(1) The interface of equipment access is reserved in the warehousing process to cope with the access of automation equipment;
(2) The "consignor" mark has been added to the system to deal with the situation of multiple consignors after the tripartite business is warehoused.
Sure enough, 8 months later, the warehousing department used a set of DPS electronic label shelves to assist the goods out of the warehouse, and a year later, the warehousing capacity was surplus, and the introduction of third-party logistics business began. The warehouse management system was quickly adjusted without changing the overall structure, and supported the development of new business in a timely manner.
This article was originally published by @产品Leon on Everyone is a Product Manager. Reproduction without permission is prohibited
The title image is from Unsplash and is licensed under CC0
The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.