How to minimize product risk in a sufficiently streamlined design process? The article will be resolved for you.
In start-up companies, there is often not enough time and manpower to do business value analysis and market analysis before developing a product. Small entrepreneurial teams need to develop quickly, let users use the product and verify whether the product is what the user wants. But this does not mean that the “brilliant ideas” that flash in your head should be immediately put into development. How to minimize product risk in a sufficiently streamlined design process?
Let’s briefly look at the process of lean product design. The figure below is a diagram in the article “How Spotify builds products” by Henrik Kniberg.
Figure 1
In the figure above, the blue curve represents operating costs; the red curve represents product risk.
The abscissa divides the product design process into 4 stages. Borrowing the ideas in “Lean Product Design” in NetEase Cloud Classroom, we can translate it into conception, creation, testing, and iteration.
I will mention this chart several times below. Since the author did not name it specifically in the literature, we will simply name it “product risk and cost chart” for easy reference. Next, we will look at stage by stage how to reduce product risks.
1. conception
Through the product risk and cost map, we can see that the operating cost in the conception stage is relatively low. At this stage, it is generally only necessary to use the product and design. During this period, preliminary assumptions and deliberation can reduce product risks. However, if the design and development are invested immediately at this stage, it is equivalent to pushing the product into a state of high risk and high cost.
Silicon Valley entrepreneur Eric Rise proposed the concepts of “Lean Startup” and Minimum Viable Product (MVP) in “Lean Startup”. Many product managers’ understanding of these concepts tends to be immersed in “Lean”. And “Minimal”. In the foreword of this book, the author gives a general introduction to the content of this book, “You will understand starting from a bold hypothesis that requires rigorous testing, to how to develop a minimum viable product to verify these hypotheses”, this book also has a special section It’s called “concepts based on assumptions.” We should focus more on hypotheses and tests.
What should we do about assumptions?
- Define the product and think about what problem the product solves;
- propose assumption. What result did your target group achieve by using your product features;
- Verify the hypothesis. Fully communicate with users; establish a user profile (Persona), describe a specific scenario (Scenario), find out the pain point (Pain), and substitute the above three points into your solution (Solution), whether it can meet the needs of users. That is, the PSPS model (from the NetEase classroom contact, the author did not find other exact sources of this model).
We can put forward hypotheses like this. For example, we develop a homework schedule with reward and punishment mechanism for students who are inattentive and always unable to complete homework on time. This allows students to complete homework on time every day, by observing the goal. To verify whether the crowd has increased the amount of work done each day.
And to verify the hypothesis, we need YY to be the inattentive student, turn on a small lamp to do homework at night while watching TV series, and use an application with some kind of reward and punishment mechanism to turn off the TV series and concentrate on doing homework. Finished the day’s homework.
2. build
In the build phase, we need to build an MVP, so what is an MVP?
MVP is a concept put forward by Eric Rise in “Lean Entrepreneurship”. The core idea of ”Lean Entrepreneurship” is “Build-Measure-Learn”. First, make a minimum viable product MVP (Minimum Viable Product). , MVP), issue to users for testing and collect user feedback, and then iterate quickly, continuously improve the product, and finally adapt to market needs.
It should be noted here that many product managers pay too much attention to “Minimum” and neglect “Viable”, which is terrible. First, the minimum viable product needs to have its core value for the user, and second, the most basic function is also the user can use it smoothly.
In the product and risk map, we see that in the construction phase, the operating cost is very high, and the product risk is stable at this stage, and there is no possibility of reduction. Of course, we have to find ways to shorten the time required for the build phase. Since there is preparation for “product definition-hypothesis-verification hypothesis” in the conception stage, it is enough to build the MVP as soon as possible at this stage.
We see that many product managers like to change requirements at will. They didn’t think clearly in the conception stage and continued to think about it in the construction stage. They always asked designers and developers to make changes and said that “requiring changes is the norm.” But doing so will lengthen the build phase, take up design and development resources, and increase a lot of communication costs. It often leads to repeated design revisions, and development can not complete tasks on time. The product manager himself will also affect the “usability” of the smallest available product in the process of repeated revisions. When can it be changed? How to communicate with design and development on a basis? I will mention it during the testing phase.
Regarding “usability”, I believe that all MVP product managers have heard of “wheels, bicycles, motorcycles” examples. In the picture below, the MVP is a bicycle, and the motorcycle is an upgraded version of the bicycle, complete but at a higher cost, and the wheels are simplified to be unusable at all. And some product managers built the bicycle into a wheel in the middle of overcoming the motorcycle, cheating themselves “this is a bicycle” and using this wheel for the next stage of testing, and then telling the whole team that bicycles are not acceptable.
Figure 2
3. test
The question I left during the build phase is explained here, “When can I change it?” The changes that can convince the design and development should at least have a basis, rather than just thinking about design changes. More than a dozen versions. Product managers should communicate elegantly with design and development through user feedback and data.
Figure 3
In the testing phase, we already have a minimum viable product. we should:
- Release this product to a small number of users, observe user feedback, and view user data;
- Analyze and improve through feedback and data, and then determine whether the product can meet market demand and whether it can expand the scale of test users;
- If possible, expand the test user scale, repeat the above steps, observe user feedback and data and continuously improve, and then expand the user scale; if not, continue to optimize the product;
- Through the above steps, the scale of testing users is continuously expanded and the product is improved.
If there are problems in the process that are difficult to solve or hesitant in design, perform A/B tests on users for these functions.
Note: In the early stage, after verifying that the function meets the market demand, it is necessary to continue to optimize the core function. This is often easily overlooked. As the scale of user testing is expanded, the core functions will encounter various challenges. For example, to make an IM software, your software cannot send short videos in this era, or the add friend function is available, but fuzzy search is very bad. It is very irrational to make a custom profile skin function at this time. It is necessary for the product manager to judge the development timing of various requirements.
4. iterative
Based on the previous conception, the three stages of building and testing, we have confirmed that this product meets market needs. Then you can once again optimize the product and develop new features through the method of conception, build, and testing.
