Lean development-the misunderstanding circle of MVP

MVP is a very exciting word. For sports fans, MVP refers to this:

For game fans, MVP refers to this:

But for every partner engaged in agile lean development, MVP refers to this: Minimizing feasible products. In lean development, the development team provides feasible products with minimal efforts, and iterates according to user feedback, and finally makes a mature product.

As a online celebrity word in Lean Enterprise, more and more product managers began to talk about the word MVP. However, most of these products, as well as most programmers' fathers, actually don't know what MVP refers to. So, there is a dialogue like this:

Product manager: "Let's make the MVP of this product first, just do it like Taobao, and don't add the membership system first."

programmer: "Do you know how complicated the UI of Taobao is? Why don't we not do the purchase function first, the MVP principle. ”?

what? You didn't find anything wrong with the above conversation. Congratulations, this article is for you, because you have fallen into a "misunderstanding circle" about MVP.

Misunderstanding Circle 1: MVP is to do high-priority functions first

For those friends who have not systematically understood lean development, the above circle is almost an unavoidable mine. In the projects that Mark experienced, many team members with long-term agile development experience even believed in this concept. Why is there such a misunderstanding? Because they ignore the first principle of lean development: rapid verification of business ideas. MVP emphasizes the complete process of the product, and it strives to realize this process with minimum effort. Often in the context of Internet products, a complete product process usually contains the functions of several different modules. For example, our Taobao Like e-commerce website, if you are from the user's point of view, if a user wants to achieve his purchase purpose on this website, it must at least include browsing, ordering, payment and delivery. This means that the lack of any of these functions will make the user's purpose impossible to achieve, so it is impossible to verify whether your business idea is accepted by users. The following classic diagram, which has been used repeatedly, just illustrates this problem. Let's feel it:

How to avoid this misunderstanding? Mark provides a classic idea of lean development: dividing functions from the user's point of view and vertically cutting user stories. Compared with the traditional function division method of "browse, place an order and buy", if your team is agile enough, you can try to divide functions vertically. The vertical division function can castrate every traditional function point properly, only keep the core part, and focus on the integrity of the user's journey. For example, "users can browse a single product, enter the address and phone number online to place an order, and use Alipay to purchase" is a common example of vertical cutting. It only keeps one option at each traditional function point, but it can support users to complete the whole process and achieve his goal.

misunderstanding cycle 2: MVP must be an actual product

Compared with the first cycle, the second misunderstanding cycle is a natural understanding for many teams that make delivery all the year round. In their view, MVP must be something that needs to be really made at the actual development cost, and it is tangible. In fact, MVP, as a quick trial-and-error tool strongly recommended by lean entrepreneurship, advocates the prototype of minimum living allowance, and the simpler the better. "Minimum Viable" is the most direct explanation of this concept. For example, if you want to make a travel recommendation app based on geographical location, you can spend a few months making a simple-looking web app that integrates GPS and big data processing, or you can make this one:

The former may cost you 1,+,while the latter ... three dollars is too good. What is the actual effect? Mark tells you through many user experience projects that the effect is similar, even the latter is better. Because it can quickly adjust the product prototype (redraw a picture) according to the user's timely feedback, and quickly get the user's second feedback. How about it? Did you begin to realize why your previous entrepreneurial project failed? Spent a lot of money!

Misunderstanding Circle 3: MVP is to pat the head and do it, and then verify it with users

It must be said that since the concept of MVP became a big fire, more and more product managers and entrepreneurs have regarded MVP as a feather arrow of their own belief in starting a business. When they had an idea, they boldly asked the developers to make a prototype quickly and take it to the market for verification. If they failed, they gave up decisively and started the second round of head-slapping trip ... In their view, this is the essence of lean development and the direct embodiment of "quick trial and error", and then ... the company went bankrupt.

Mark must warn everyone here that lean development is a lightweight development method to reduce waste, but it does not "eliminate waste". This means that all actions that can really eliminate waste are more valuable than the direct development of MVP. For example, market research, proper market research can kill an unrealistic business venture in the cradle and avoid any waste of development costs from the source. From another point of view, market research can provide ideas and perspectives for the design of MVP, which is an essential part of product design. If we can really do reasonable market research, we won't see the following embarrassing entrepreneurial spectacle: < P > Well, after talking so much, do you have a more correct understanding of the concept of MVP? What? Still not, then you'd better look at this MVP in Mark's heart:

More interesting articles, welcome to Mark's personal website: www.himateng.com.