Methodologically, this is very similar to MVP: to create a new feature, a new project is not created, with its V-cycle stages, detailed documentation, and falling into a triple constraint. Instead, the product defines what will be the minimum useful functionality that can be presented to the market in order to get feedback from users. And the team takes this minimal functionality to work, often without a long study of the details.
While in the project approach they write use-cases and test plans, in the product approach they collect feedback from users and fix bugs. And if it turns out that the feedback is negative or absent, you can stop supporting the feature, or abandon it altogether. And to do this early enough, without investing in the full development cycle of all its functionality. Or invest in another feature that has a greater market potential, confirmed by user feedback.
In other words, the essence of the product approach to creating an MVP is to break the process of its implementation into very short cycles of creating value and receiving feedback, which gives much more flexible manageability and allows you to make decisions about the development of the product during its development.
Another feature of the MVP approach is the ability to literally make from shit and sticks (shit and bricks). That sounds scary to any project manager or architect — and great to an entrepreneur. If you don’t know if a new idea will work, there’s no point in investing hundreds of thousands of dollars in it and hoping for the best. It’s better to make something that can be used for a few thousand and attract investments to an already existing user base.
It can be argued that the development of an MVP is only a small part of the product lifecycle. That MVP can be developed within the framework of the project approach, and then enriched with MMF within the framework of the same project approach. Yes, that’s how it can work. This will significantly increase the feedback loop and prevent situational use of solutions “on the knee”. This isolates the development team from the business value of the product being created. But this is quite possible to work – and this is how they often work. Further I will try to show why this happens, and why this is not entirely true.
Perhaps the most important—and also the most difficult and therefore underestimated—benefit of a product approach is the ability to respond quickly to market signals and deliver exactly what the market needs. The project approach, on the other hand, is based on the unspoken confidence that we know exactly what the market needs – and we do just that. Comparing with military affairs – you can plan an operation, guided by the map – or you can make reconnaissance on the ground. As they say, it was smooth on paper, but forgot about the ravines.
However, the key problem in obtaining this benefit is the ability to withdraw feedback. The team needs to understand what business metrics the MVP or MMF is targeting. What information – system, user and other – needs to be captured, monitored, controlled. Unfortunately, it is often possible to observe a picture when the team is engaged only in development according to the requirements specification. Other people serve the product, they also collect a bunch of some information, third people analyze this information, and the fourth think what to do with it. The maximum that the team does in this sense is that it makes it possible to collect metrics by connecting logs and other tools, and makes dashboards for administrators and analysts. As a result, it turns out that the functionality of the system is created by people who do not understand the business sense of what they create.
Again, it is not uncommon for situations where information is not collected at all. Not only is there no one to analyze it, they don’t even look at it. The whole point of the fast feedback loop simply disappears. In this case, there really is not much benefit from the product approach. It is quite possible to include a project approach, invest money and see what will come of it, with a cycle of a quarter or even a year.
Summing up, I want to note that the product approach is NOT BETTER than the project one. Each is better within its applicability.
The thing is that very often – just VERY FREQUENTLY – MVP development is carried out in the project paradigm. And they get results. A good manager and a good team is the key to hitting the triple constraint.
But at the same time, no one even tries to think about what result would have been obtained if the team had approached the issue in the product paradigm. Moreover, often neither the team nor the manager is simply ready to work in this paradigm, they do not understand it. And, as a result, they simply do not know how to work differently.
But why this happens, and what you need to understand, be ready and be able to apply a product approach to development is a separate big conversation. Write in the comments if this topic is interesting and questions that you would like to receive answers to.