Products, projects and other animals



Product or project? Disputes on the definition of these concepts do not subside, and this is not idle debate. The management methods depend on the characteristics of each discipline, and the expectations of interested parties depend. I want to present my definitions of the concepts of “product” and “project”. I want to emphasize right away - these will be exactly my definitions based on many years of practice. It is unlikely that you will find their word for word in certified literature, but I will try to show all the calculations that lead precisely to such definitions. I will gladly discuss in the comments if your point of view differs from mine.

A project is an activity. A product is also an activity. Upon its completion, a tangible result may appear in the form of an IT product, but software is never an end in itself of a product. Unlike the project, where the very fact of creating a working IT solution will be a significant result. The goal of the product creation activity is to solve a specific problem of a specific group of people. The quality of a solution to a problem can be measured in money, likes, the number of lives saved, the number of accidents, or simply the subjective concept of “quality of life”. Yes, since we are, after all, IT specialists, we use IT tools to solve problems. However, the result of the product as a whole cannot be assessed by the conformity of the terms of reference and the developed IT product. But in the project, this is how we evaluate the result.

The aim of the project activity is to fulfill the task in a clearly defined time frame and budget, with a given quality. Even if the project assignment is written in the first phase of the project, the project always has a customer in whose interests this assignment is written. The project is the customer, the product is the problem.This is a very important difference! Even if the customer of the project formulates the goal as “solve the problem for me”, it will not be equivalent to the product for one simple reason: responsibility. As soon as the project team forms the task and brings it to the customer for signature, the responsibility for the fact that the proposed method solves the problem is transferred to the customer. Yes, in some cases, you can reduce the risk of missed solutions by using Agile approaches (in order not to start another holivar, let's assume that in this context Agile is “an approach that reduces the risk of misses as a result of short development cycles, constant analysis of the result and the ability to change the direction of movement at any iteration ”). But a project always has limitations. At least in time. So, responsibility forthat at the end of the project, the result will not be achieved, it will still remain with the customer (especially, especially with the Agile approach, where the customer is involved in the work quite tightly).

The product has no customer. There are users whose product solves the problem. But they are not customers at all. Henry Ford is credited with the phrase "If I asked my users what to do, I would still attach the fifth leg to the horse." It is not so important who came up with the phrase, but it perfectly illustrates the difference. Ford solved the problem of the rapid and independent movement of middle-class people. Yandex taxi solves the problem of fast car delivery regardless of belonging to a taxi fleet, and the use of a smartphone and an IT system instead of a single dispatch center allows you to beat the latter in price and quality. Delivery-club solves the problem of food diversity. Etc.

A product always has an investor. It can be either a founder who invests his time and accumulated money, or a separate company investing money or connections. An investor differs from the customer in that it does not accept responsibility for the result from the team. The team is responsible for the product result. To understand whether a product is moving in the right direction, product metrics are generated. Regarding their changes, these or those changes made in the product for a certain period are evaluated. The project also has metrics, but they relate mainly to the development of time or budget. To understand the difference, let's look at a simple example: the metric "budget execution" for the period showed an excess of the fact relative to the plan. The analysis showed that we caught the segment on which we did not expect contextual advertising.The conversion of the segment to the target action showed that there is potential. If we make a product, we will analyze and strengthen the competitive advantages of the product in the new segment, increasing the budget. If we are doing a project, then this is a clear step beyond the boundaries of the project and we must adjust advertisements in order to remove unnecessary traffic.

Each product has at least one competitor - a familiar way to solve a problem. For Henry Ford, these were horseback riding or horse-drawn carriages. For Yandex taxi, call taxi companies or call a single dispatch service. The Delivery Club fights, first of all, with “cook it yourself”. And the effectiveness of each is not the convenience of the interfaces of their applications, but the quality of the solution to the original problem. If Yandex-taxi will always arrive much faster than through the dispatcher, then no matter how inconvenient the application, they will use it. But in Tolyatti, for example, still a taxi, ordered by phone of a single dispatch service, arrives faster and in more places. Therefore, in Tolyatti Yandex taxi as a product is unsuccessful, despite the super-cool application.

Projects may well have no competitors, since the goal of the project may be to optimize some process or just collect data, reconnaissance in battle. The project ends as soon as its goal is achieved or the deadline for its implementation. The product is alive while the problem is alive. Product changes are a way to survive in a competitive environment. Each iteration, the product team should answer the questions “what can we change so that it becomes even easier / faster / more comfortable for our users to solve their problem”. The project team solves the inverse problem - how to prevent the growth of the project volume.

Now, based on the above characteristics, let's derive the definitions of the project and the product.

  • — , , , . ( ) , .
  • — , . , , , , — , . — — .

Before drawing conclusions, I want to answer a silent question from readers: "What does the picture in the title have to the topic under discussion"? The most direct. Jacob Jordaens depicted the second meeting of a satyr with a peasant from Aesop's fable “The Man and the Satyr”. At the first meeting, the satyr asked the peasant, blowing his own hands in winter: “

What are you doing?” Why are you blowing on your hands?
“I warm them with my breath.”
In the second meeting, which is in the picture, the satyr asks the peasant: “
Why are you blowing on the soup, trying to warm it?” Is he so hot?
“No, I blow on the soup to cool it!”

From this dialogue, the satyr concludes that humans are suspicious two-faced creatures that are best avoided.

Definitions of the concepts of “product” and “project” are needed in order not to fall into the same situation as a satyr. They are needed to apply the right tools at the right time, choosing the right control system. In order not to try to evaluate project activities with product metrics or vice versa. In order not to try to formulate a product budget on the basis of technical specifications for an IT system. To clearly focus the team on a specific work strategy. For example, when designing IT systems in a project, it makes sense to choose the least risky solutions. And in the product are those that meet the win-win concept. The choice of an iterative waterfall for the development of the project is a completely natural step, as it allows you to more accurately control the budget and timing. The use of flexible approaches in products is more convenient, since they are the ones that make mistakes more often and faster.Use approaches in accordance with reality, do not fool yourself - and there will be less frustration in life.

All Articles