Product Managers 1 — End-to-End System
I’m going to write a product manager blog series, I hope it will be useful for people who want to learn
This product manager series will first talk about the product development system, and then explain how to do each step in this system separately
What is the goal of product development?
To deliver solutions that solve user or business problems and achieve business goals through technical implementation.
What is the purpose of product development?
The purpose of product development is not to develop a product, but to be able to solve the needs of users.
What is a requirement?
The user’s current problem.
Problem Domain and Implementation Domain
Business goals, users or business problems, solutions belong to the problem domain.
Technical implementation belongs to implementation domain
The process of product development is the transformation from the problem domain to the implementation domain through organized activities.
The first step is to decompose the requirements in the problem domain, so that the decomposed requirements can achieve separate flow and continuous delivery, and further decomposition in the implementation phase is normal.
Waterfall
The core idea of waterfall is to build the product first, and then the customer will come.
Waterfall moves the product forward in an orderly fashion, delivering value at the end, i.e.:
Requirements -> Design -> Development -> Testing -> Value delivered to the user
But due to Moore’s law, the earlier the product is delivered, the higher the value of the product.
The time when the team has accumulated the most knowledge about the project is at the late stage of the product, and the time when the project starts is the time when the knowledge is least sufficient, which is the paradox between knowledge accumulation and decision time under waterall.
Agile
The point of agile is to make up for the shortcomings of waterfall with iterative development:
Deliver value faster: Faster does not mean faster in absolute terms, but earlier relative to waterfall, delivering a portion of the value in each iteration, which is more delivery than last, according to the inverse Moore’s Law.
Flexibility to respond to change: start with some initial solutions, then update the strategy each iteration to build new knowledge.
Delivering value faster and being flexible to change is the goal of agile.
Difference between agile and waterfall
The difference between agile and waterfall is like drawing a character, waterfall is to start from the head, and then draw the rest of the body after the head is drawn well enough, while agile is to draw the whole outline of the body as a skeleton first(what is commonly known as MVP), and then embellish the body, with additions and deletions in the process.
Anyone who knows about sketching knows that drawing like waterfall is not a good drawing.
Lean
Iteration in the development phase, the process is from requirements analysis to test acceptance, but in reality there is still business planning and product definition before requirements analysis, and after test acceptance there is still solution implementation and validation, so only the development phase iteration process from a macro point of view is still waterfall, subdivided into water-scrum-fall, the delivery of value is still very late to complete.
So it is not enough to achieve only the iteration of the development model, you need to achieve end-to-end delivery of value, end-to-end refers to the user’s problem to the delivery of user solutions.
To visualize the whole process from end to end, a kanban board is a good choice.
The lean system
The Lean System has three levels:
Objectives, Principles, and Practices (divided into management practices and engineering practices)
Objective: To deliver useful value smoothly and with high quality.
Principles: Explore and discover useful value, focus and improve the efficiency of value flow.
Management practices: Innovation practices (business model design, validation step planning, lean product design, qualitative validation, lean data analysis, impact maps), lean requirements analysis and management (scenario analysis, use case analysis, domain modeling, requirements maps, release planning, instantiated requirements), lean Kanban methods (visualize value flow, show process planning, control WIP, manage work flow, Creating feedback and continuous improvement).
Engineering practices: continuous software delivery, sustainable and efficient development, rapid business development (continuous integration, continuous refactoring, etc.).
Smoothness of purpose means that the value delivery process should be smooth, delivering user value in the shortest possible time, not intermittently and problematically; high quality means meeting requirements and avoiding unnecessary errors, which does not conflict with the necessary trial and error for exploration; useful value means that the delivered value should meet market and user requirements and have business impact, contributing to organizational performance.
The “Think — Make — Check” cycle
The original process of lean is “build — check — learn” cycle, but directly from the build cost a lot, so changed to “think — make — check” cycle, “build — check — learn” cycle that the customer development process omitted, suitable for a large company with a lot of users and the ability to quickly develop the product.
The end-to-end process of lean
1. Identify the user problem from the target (Select a driver that you want to improve, set a completion standard for the driver based on the business model, and first quantitatively identify the user’s problem from the target through data analysis (if there is no data, then you can analyze the competitor’s data)) (problem domain).
2. from user problem to solution (user story map, UX, functional structure map) (problem domain).
3. development and testing (MVP, after each iteration before developing a feature, if the cost of implementing the full version is small, then you can implement the beta version first, if the cost is large, implement the demo version first) (implementation domain).
4. deploy (deploy not immediately release) (implementation domain).
5. release (ABn test) (see if the solution meets the driver metrics and guardrail metrics, if it does, go back to step 3 and implement the full version, if it doesn’t, do customer development and then go back to step 2 and try again or just give up) (implementation domain).
