4. Let’s talk about MVP again, minimum usability products
The basic concept of MVP has been mentioned in the previous blog, and this course study just mentioned about MVP, so let’s summarize how to use MVP thinking in work.
A few principles for quickly using MVP:
- Deduce the logic in advance, do not blindly verify
- Verify the long board, not the short board
- Creative low-cost solutions
The other side of MVP
1. Some principles of quick use of MVP
1.1 Deduce logic in advance, do not blindly verify
Before designing a minimum usable product, you must think clearly about the problems you want to verify, which data items to collect, the possible results of these data items, and the conclusions represented by different results.
Similar to TDD (Test Driven Development) in software engineering , first list the results you want, and then reverse the design, so as not to make the design logic unclear, or miss data management , and waste resources instead.
1.2 Verify the long board, not the short board
Cut short boards as much as possible and put resources on long boards
Try to focus on the core, differentiated experience.
For example, the first version of 12306 was an MVP, and the entire product experience was so bad, but the longboard still fully reflected: it has votes.
In this era, various product forms have basically been thought of or implemented. To gain a foothold in the market, we do not rely on a higher average score, but to achieve ten times the existing plan in a single dimension. good. Therefore, it is more important to be an MVP to verify this longboard, rather than to make a mediocre attempt without making mistakes.
1.3 Creative low-cost solutions
When designing a minimum usable product, we need to creatively come up with low-cost solutions to verify the most critical propositions.
1.3.1 Replacing the system with humans
In fact, there is no need to be so well prepared before going on the road. In many cases, you can use human power to withstand the test first. If the service is really reliable, it will be too late to quickly iterate and use systematic capabilities to solve problems.
1.3.2 Using third-party systems
Today's Internet infrastructure is much higher than that at that time, from SaaS to PaaS, from cloud services to website building, e-commerce, payment, and small programs. Therefore, for us, the threshold for building an MVP is getting lower and lower. You should use third-party services as much as possible to quickly verify your ideas.
1.3.3 Use rules to narrow the scene
Suppose we plan to invest resources in making intelligent customer service robots, and now we want to verify whether users can accept dialogue with machines to solve problems. Before there are any natural language understanding algorithms and data, we can simplify the implementation difficulty of providing dialogue by narrowing down the scene. For example, we can set conditions. When the user opens the order details page within three days after confirming receipt, it is very likely that the product will be returned. At this time, an entry for return consultation will appear. After clicking in, it will enter the process of machine customer service. This process can only have the ability to solve the return problem, and can even be completed with a simple QA pair, and the requirements for implementation difficulty will be greatly reduced.
2. The other side of MVP
MVP is not the only correct methodology, and many people have disagreed with MVP and Lean thinking.
There are many product models that require a certain volume and complexity to complete the verification. MVP can only verify whether the assumptions in some links are true at most. Don't bet all your treasures on one MVP. Especially for products with relatively mature fields, the superposition of product experience details can constitute the core competitiveness, and it may be difficult to build it in MVP.
3. Summary
Combined with a product I have been working on recently, it is a product for B-end users. The good point is that the third-party system is reasonably used to quickly develop our products. The bad point is that the business is too complicated, and the MVP built is difficult Verification, the product development cycle is too long, seriously out of touch with the development of the industry.
Recommended books:
1. Lean Startup
2. Toyota Production System