To begin with, let’s define in a nutshell what this MVP is.
Minimal Viable Product is the very minimum that can be given to the market to “feel”, collect feedback and decide whether to develop it further, or put it on the shelf until better times. Accordingly, before developing an MVP, we need to decide what will be the very minimum that will be enough to probe the market.
And this is where the ground for misunderstanding and confusion appears.
From the point of view of any project manager, the development of an MVP is a project. The customer has already decided on the requirements, we can calculate the budget and terms – and that’s it, our triple constraint is ready, we can run according to our project implementation scheme!
Yes and no.
Let’s see how this usually happens in the project approach paradigm and compare it with the product approach.
Design paradigm
A marketer, based on a study of the US market, discovered the need of the Russian market for a certain product. In the USA, such a product already exists, there are features A, B, C, D and E, demand is growing, competitors are appearing. These features solve certain user problems – and a study of the Russian market shows that Russian users have the same problems, and they are solved just as badly and inconveniently as it was in the US before the release of the new product.
The marketer, after thinking, briefly writes down the requirements for the new product, and goes to the developers. Those, having connected analysts, specify the functional and non-functional requirements, draw up the TOR for the development, determine the triple constraint – and the project begins. About a month later, the design is approved, some amendments are made to the TOR – and now the team is ready to start implementation.
In two or three months, the product is ready, it is being tested, it is being rolled out into production, the advertising campaign has just arrived in time – hurray, we are launching!
What happens if something was not taken into account when compiling and validating mockups and design? Some of the project managers will now jump up and insultedly declare that it is impossible to take into account everything. That users often behave strangely, and in general, our UX architect is so great that he cuts most of the problems at the thinking stage.
But still. But still. Dear project managers, honestly, is it rare that a customer, having received a finished product, is sincerely surprised by it? Yes, he didn’t think of it somewhere. Yes, he misunderstood somewhere himself, signing mockups, design and technical specifications. It is normal for a person not to fully understand how the end result will look and work.
In any case, it has already happened. And this needs to be fixed somehow. Either within the framework of previous agreements, for which a buffer is often laid down when assessing the timing and cost – or by additional. agreement.
In any case, the product is ready, filed, polished and launched.
Next comes the collection of feedback from users, the development of new features, modification or removal of old ones. In general, normal product development.
At the same time, from the point of view of the project team, their authority begins at the stage of collecting requirements for the MVP and ends after its implementation. Developing a product in the project paradigm is extremely difficult.
But imagine that the same project team remains to develop the product. What will happen?
The marketer conducts another market research and proposes to include feature E in the product. The team clarifies the requirements, draws up technical specifications, sets a triple constraint, and rolls out a new feature in a month. Analysts work, technical writers work, a project manager works, compiling Gantt charts or a critical path, developers, testers, and implementers work. If later it turns out that the feature is ineffective or even harmful, you can start a project to remove it.
In general, this overhead is not obvious to anyone – neither the marketer, nor the project manager, nor the team members. Everyone is in business, everyone works effectively. Over time, even documentation can be reduced to a minimum. But the overhead is still there.
Where? Let’s try to compare.
Product paradigm
In the product approach, everything happens quite differently. Again, it doesn’t matter if it’s Scrum or another framework.
When the same marketer comes to the product and shows his description of what he considers an MVP. A good product will invariably ask the question: What is the relative business value of these features? Having understood, together with the marketer, their business value, he will give a very rough estimate of the labor intensity of each feature, connecting, if necessary, the competencies of the team.
Further, using the Easy First approach, the team will quickly release the first version of the product with one or two features. This can happen literally in one or two iterations. Moreover, if it turns out that some of the features can be implemented using a third-party service or a boxed solution, that is exactly what will be done.
With full awareness that for an industrial solution, this feature implementation option will have to be thrown into the dustbin of history.
In any case, the marketer – and through him the market – will receive the first version of the product much earlier. The user base will begin to be recruited – first internal, and then external. Feedback will start coming. It turns out that the business value of features in reality is somewhat different than previously thought. As a result, some features may not get into the final product at all, but others will appear, or it will be possible to focus on the main, killer-features.
Another important point is that product development ends only with the death of the product. This is the key difference from the project approach, which is always finite. As long as the product lives, it is actively used – there will be requests to change the functionality and add new features. And here the Minimal Marketable Feature (minimum useful functionality) comes to the podium.