How do Product Managers iterate products based on requirements (Part 1) : High Cohesion and Low Coupling in Product Design
The purpose of high polymerization and low coupling mentioned above is to be used in product design. The product design mentioned here includes not only interface design, but also product architecture, system architecture, functional modules, entity structure, roles, logic and so on.
This article is divided into two parts: overall design and local design. Overall design refers to the whole process of developing or reconstructing a product from zero to one, which involves four levels: business layer, system layer, logic layer and interaction layer. Local design refers to the normal iteration of the product or the process and core under the design of a small piece of the product. The process of local design is a subset of the overall design process, so the core of local design is mainly discussed.
As you watch, always keep in mind the purpose of “high cohesion and low coupling shape product perception”.
The overall design
The overall design of the product includes four levels: business layer, system layer, logic layer and interaction layer. Propose business solutions based on requirements and design feasible and practical business solutions.
In practice, it’s not strictly sequential, because the method is hierarchical and the inspiration jumps. I typically begin by abstracting entities, roles, and logic from the business solution,
Business layer: Business solution
The business layer refers to the business solution. The business plan is the plan at the business level, which requires that the business plan is feasible and practical. The business plan for a new product/module is usually proposed by the product manager, leader, or business side and represents how the problem is solved in the thinking of the product manager, leader, or business side.
Only feasible and implementable business solutions are meaningful, because the product manager is to put feasible and implementable business solutions online and make them standardized to solve a class of problems. If the business solution is not feasible, then subsequent product design is out of the question.
If the business solution is already in place and feasible, for example, it has been manually implemented for a period of time at the operational level according to certain rules, the results are good. The product manager needs to put the plan online, design functions based on the business plan, make standardized functions to solve such problems, and combine the overall and future development.
If there is no feasible business solution, the product manager not only needs to communicate one or more solutions with all parties, but also needs to test the expected effect and feasibility of the solution by implementing the solution or designing MVP. If there are more than one, choose the best one. The best one here can be the effect or cost performance, etc., depending on the situation, please judge.
When the company develops to a certain stage, there must be one vertical business and one horizontal system. After the vertical spread of multiple businesses, the horizontal system needs to be opened, mainly for four aspects: professional depth, human resources, user experience, and global integration. For example, In a short period of time, Didi Chuxing has formed a vertical structure of multiple businesses, including express cars, taxis, private cars, hitch rides, and agency driving. Didi has launched a strategic integrated business system for China And Taiwan. For details, please see “How to Build a Big China and Taiwan Architecture from The Practice of China and Taiwan of Didi Chuxing Business”.
System layer: system positioning, system architecture, module abstraction, planning blueprint
The system layer refers to some things at the system level, including system positioning, system architecture, module abstraction, and planning blueprints. The products that people see and experience are the ones that are exposed, and there are actually a lot of systems below sea level, and there are several systems behind the products, large and small. For example, ViPSHOP is divided into SAAS, PAAS and IAAS, each of which has multiple platforms and systems to support the development of ViPSHOP. The IM and push in a small APP may be independent systems provided by a third party.
Positioning system
System positioning is to determine what requirements the system needs to solve, first there should be split out of the system requirements, and then there is the system. System positioning is of course the first step, not everything has to be pulled out of a separate system. Observing the evolution of large systems, we can find that most of the systems are from the initial small function to module and finally to system (function < module < system).
Systematic itself is low in order to solve the resource sharing, utilization rate is low, can’t focus on issues such as, the system can also reduce the overall coupling, at this time should be and architects were discussed, because most of them are technical things, to think clearly, which is the system which is not a system to solve the matter whether urgent demand, And positioning is proposed for each system as the direction of iteration, of course positioning is not immutable.
System architecture
After determining which systems are available and the corresponding system positioning, the system architecture can be started. System architecture emphasizes the connection between systems. If there are multiple systems, they can be platformized like VipSHOP, which is easy to understand and facilitate the division of organizational structure.
If it is found that all system or modules are not included after the completion of the system architecture, it is necessary to go back to the system positioning to comb and think again, to include all. Because system architecture is about explaining the relationships between systems, you can never shoehorn a module into it. It’s like packing a bag, a suitcase, and a woven bag before going out, and then finding a pair of shoes left, you have to find a way to cram them into the woven bag for shoes, but the woven bag is already full and there is no space to empty, so you have to cram them into the suitcase.
There should be coordination and coordination between systems, which are interconnected and mutually restricted. Just like the eight major systems such as the motor system and the nervous system, all kinds of complex life activities in the human body can be carried out normally.
Module abstraction
The relationship between platform, system, module, and function should be: platform contains system, system contains module, and module contains function. What is said here can not only be seen as a certain interface of the front desk, all contain the corresponding logic of the background, etc., is a three-dimensional structure rather than the plane structure of the front desk. Platforms, systems, modules, and functions are all three-dimensional structures, but with different granularity. Characters, entities, and processes are planar structures, systems under different perspectives.
Module abstraction is to pull out different modules, modules and modules are independent and interdependent, similar to system positioning, after dividing the module to determine which system contains which modules.
Functions are abstracted from scenarios and processes, and modules are abstracted from functions and entities. Vipshop and other e-commerce systems can be divided into product modules, category modules, order modules, shopping cart modules, payment modules and so on. A module consists of a foreground display page/component + background logic. Module abstraction is very natural, because the establishment of its own system has its internal ecology or logic, just like the human respiratory system contains respiratory tract (nasal cavity, pharynx, larynx, trachea, bronchus) and lung a series of organs and internal logic.
Planning blueprint
Great products are iterative and planned, not born. Many products are very simple and basic modules in the early stage, and the 1.0 version is used for quick trial and error. If the module has a lot of volume, it will waste resources, and if it fails, it will lose more than it gains.
A blueprint is not a blueprint. The difference between a plan and a plan is that a plan is long-term (more than six months), not detailed, and with imprecise goals, while a plan is short-term, detailed, and with precise goals. For example, a new version in the first half of 2018 is a plan, while a natural 100% increase in users by June 2018 via coupons, made-out, etc is a plan.
After the system architecture and modules are abstracted, I plan the blueprints. The blueprint is divided into two parts, requirements tree and product Roadmap. The requirements tree puts all requirements (system, module, function, or some problem to be solved) on the tree, and the product Roadmap places the requirements on the requirements tree according to the product stage after being filtered down.
Requirement tree is used to sort and classify requirements, analyze priorities and contextual conditions. The root is the necessary infrastructure to realize the whole system, the trunk is the core functional module, the branch is the field or direction that can be entered, and there are functional modules on the branch. Start by identifying core functions, infrastructure, and direction areas, then paste sticky notes on functional modules or requirements, and finally adjust the position of sticky notes according to the strategy of priority as the closer to the trunk. The whole team is working together, sharing ideas, negotiating with each other about how specific features or ideas should be developed, and prioritizing them.
The requirements tree can be replenished at any time, and requirements added to the tree should be regularly trimmed and adjusted to fit into the roadmap.
Product roadmap is a product roadmap for defining when and what the product should do. It is a product route from 6 months to 2 years at most, depending on the size of the company and the characteristics of the industry. The product roadmap can be adjusted according to the actual situation, but it can not be changed at will. The product roadmap is serious, and if it is not serious, it is meaningless.
The roadmap includes product phases, milestones, and requirements.
Product stage refers to the stage in which the product is located. There are four stages: initial stage, growth stage, maturity stage and decline stage. Each big stage has a small stage according to different situations, which is determined according to the product situation. Products in different stages have different product strategies, which should be summed up to provide ideological support for the choice of demand and implementation direction.
Milestones are mainly used to divide stages, such as finding the first user G spot and forming a replicable scheme to make users grow on a large scale and enter the growth stage from the initial stage; When the number of new and lost users equalize, the ROI of new activities will continue to decline, from growth to maturity and so on.
Based on the product stage, the product strategy in the stage and the requirement tree, the requirements are put into the product roadmap, and the product roadmap is finally formed. The closer to the current time, the more detailed, the farther away the general direction should be clear.
These are my own self-summary, and also my cognition and summary of the world. Everyone’s cognition is more or less different, and I hope to help you better understand the world.
Vency, two years experience as product manager, pursue the unity of user, technology, business and social value
Search the public account Vency or vencybu2 to share my systematic or extensive deep thinking
How do Product Managers Iterate products based on Requirements (Part 3) : The Logical and Interactive Layers of a Product’s overall design