It happens that people close to the topic of software development ask: how is project work different from creating an MVP (Minimal Viable Product)? It is clear that at the same time, each question that asks its own context – accordingly, it must be answered in different ways. Generally speaking, however, design and product development are very different from each other. In general, everyone. This is not so easy to grasp, so let’s try to understand the problem.
Problematization: project or product development
If you look superficially, then software development is software development, whether it is a project or product development. There are some functional requirements – not always formalized. There are non-functional requirements – which are often forgotten at all. There are developers, there is a certain conditional manager, and there is some kind of methodology. Developers cut the code, the manager clears the obstacles in their way, resolves issues with the end client / user / customer. At the end, some result is shown. Sometimes, as they like to joke in the industry, the result even meets the requirements.
If you look a little deeper, it turns out that there are at least two huge areas of development that are radically different from each other in literally everything: from goal setting and formulation of requirements to execution processes and delivery of results.
These are the so-called “project” and “product” approaches to development. Each approach has its own characteristics, which we will consider a little further. So, if you dig even deeper into the product approach, then inside you can also highlight the development of MVP. Creating an MVP, being a part of product development, at the same time has its own characteristics and differs sharply from the development of an already full-fledged product in order to improve and expand it. In addition to MVP, you can also highlight MMF (Minimum Marketable Feature). MMF is not the subject of this article, just note that they are different things. They, unfortunately, are often confused, saying that all this is MVP.
And now, having an idea about the existence of all these differences, you can dig deeper into the details and consider how exactly the approaches differ.
Project vs Product
Let’s start with a project approach. There are different project development methodologies, different project management frameworks, but in general, I would single out two main things.
The main task of project management is usually getting into the triple constraint: Time, Cost, Functionality. From this requirement logically follows the need to agree on everything “ashore”, to fix these agreements, and to conduct often very tedious cycles of approvals for any changes.
This approach requires a specific team composition, processes, communications.
If we take a product approach, then, abstracting from a specific framework, we can say the following.
The main objective of the product approach is usually to create a product that is successful in the market. At the same time, neither the deadlines, nor the budget, nor the functionality can be fixed at all. The main thing is to maintain flexibility, situationality, and the ability to respond as quickly as possible to signals coming from the market.
This approach requires a specific team composition, processes, communications.
As they say, surprise surprise. The goals set for the system determine the entire content of the system: the material from which it is created, its structure, processes, internal and external communications.
Trinity constraint
When you talk to any business, they are interested in planning. What budget should be allocated, during what period the result will be provided, what exactly will be included in the result. Moreover, this is not a request for predicting the future – namely, planning.
Small errors are allowed in terms – usually up to 20% and cost – usually up to 10%, in functionality – here the error very much depends on the source of the requirements. If the requirements come from, say, the hypothesis of the marketing department, then there is more flexibility. And if these are the requirements of the new law, then there is trouble with flexibility.
However, we will not dwell on the pros and cons of each approach.
We only note that the project approach is ideal in a situation where everything plus or minus is clear in advance: there is a fixed budget, there are deadlines, there is an understanding of the desired functionality. Often incomplete. But this is already the task of analysts and managers: together with the customer of the project, to determine what exactly should be included in the result, what is desirable, and what can be neglected.
The specifics of the project system
In a project approach, work is usually broken down into understandable phases. For example, formalization of requirements and preparation of project documentation, design, implementation, testing and debugging, implementation. Details may vary, but the general approach of the V-model is generally maintained, even if it happens unconsciously.
Accordingly, a different set of specialists work on the project at different times. At the first stages, the load is more on analysts, architects, technical writers. At the design stage – for designers, layout designers. At the implementation stage – for developers. At the debugging stage – for testers. At the implementation stage (if any) – for implementers, if such a role is present in the team.
Including therefore there is a need to document everything and everything. So that, conditionally, the programmer does not run with any question to the analyst, who by that time is already working on a description of a completely different project. So that the tester clearly understands what and how to test, what are the criteria for accepting the result by the customer, which problems are critical, and which are, in principle, acceptable.
And all this is coordinated by the manager. He often acts as a kind of layer between the representatives of the customer and the team. In fact, there are two main channels of communication here: the manager and the documentation. Of course, no one forbids people to communicate directly when it is appropriate, but in fact, direct communications are far from always appropriate.