Change of mentality: project vs product.

Have you ever noticed that when we are involved in a project we talk about a viable minimum PRODUCT? Why do we talk about a PRODUCT owner in Scrum projects? Shouldn’t it be Project Owner?

The word "project" has been overused, it is a concept that has been established with strength in our day to day. We cannot say "I belong to this team", we usually say "I am in this project".

This is because we have always been taught that we work on projects and that in the IT sector everyone belongs to one. On the other hand, when we do an "internal project" we usually call it a product.

Is the difference between a project and a product important? Why do projects managed with Scrum also fail?

The difference between a project and a product can make the difference between success and failure. Let's look at the definition of project that the Project Management Institute gives:

"A project is a temporary group activity that takes place in order to produce a product, service or result, which is unique. It is temporary because it has a defined beginning and end, and therefore has a defined scope and resources".

If we analyze this definition, there are two things that stand out as problematic: defined scope and start and end date.

Closed project VS Iterative project

Every project is always closed because it must have an end date. On the other hand, a product does not have an end date, it is considered to be endless in the sense that it will die the day it ceases to be profitable or that it does not to be evolved further, but it does not have a marked date where it is no longer developed more.

Seen in this way, it seems that a project is more limited and controlled. However, anyone who has experience in development will have experienced the 3 truths of software:

1. We can never have all the requirements before we start.
2. Requirements change over time.
3. We always want to do more than what time and money allows.

If we assume these 3 truths, it is impossible to have a definitive scope, so if we have to calculate an end date we will end up doing it with a high probability of error.

But let's see more differences.

Project Objective vs Product Objective

In a project one of the objectives is to meet the date to deliver an agreed scope with a predicted cost and defined quality.

Many teams end up reducing the quality (with the consequent increase in maintenance costs) in order to reach the defined date.

The product, however, goes beyond meeting a date, as it seeks to generate value for the organization (whether money or other intangible good as brand image). The product may have dates, of course, but its success is not measured in compliance, but rather in the value it generates. What organization would pay for software that nobody wants? Way more than you think, believe me I've seen it dozens of times!

Track by % of progress vs Track by value

Another difference when making software with a project is the % of progress. The % of progress tells you how you are doing with respect to the final objective.

The theory works if it were not because the scope usually varies during the project. Some people make calculations such as "If we have 10 months time and we’ve used 9 months we are at 90%", but it is still a self-deception.

In the products it is different. There is no % progress because there is no end to reach on which to compare.

Depending on the context and the objective of the product, we will have to define what measurement we will take into account to measure the value it contributes: income, retention, efficiency, etc. In digital products we will have to define our measurement and make it increase with the passage of time.

Project Manager vs Product Owner

As for the leadership of the team, in the project model it will fall on the Project Manager, who is the maximum person responsible for compliance with the date, scope, cost and quality.

Therefore, if you generate software that fulfills everything but no one uses it, the Project Manager will consider it a success, since their responsibility is limited to construction, not to a subsequent sale.

However, when developing a product with Scrum, the key figure will be the Product Owner, whose responsibility is to generate value. There could be delivery dates, but they will be strategic so as to generate value.

If the dates are met and the software is rejected in the market, then it will not be a success. Therefore, you must control not only the scope or requirements, but also the generated value and the costs of ownership (Total Cost of Ownership).

That is why a good Product Owner values ​​quality, because he understands that low quality generates, in the medium term, maintenance costs and negative impact on their product.

In addition, a Project Manager is mainly concerned with the team. Although it is true that you have to identify and manage the stakeholders and their expectations, you will spend more time with your team. In the case of the Product Owner we found a key difference.

A good Product Owner will spend 50% of their time with users, understanding their needs to know where to add value. The other 50% will be with their team to transmit what they have learned from the interested parties.

Here I want to point out something. Developers get paid to make software either in a project or for a product. Good developers want the software they create to be useful for an end user, that it makes sense, making software that nobody wants is discouraging and can be a cause for loss of talent in organizations.

The presence of Business

Another key point is the relationship of IT with Business units. In the project model, Business units appear usually at the beginning to give us the requirements and at the end to certify that it obtains what it requested.

Along the way, Business units are not present except to change the requirements, and this management ends up being very hard for the Project Manager. When we make a product we need Business to be present, we do inspection and adaptation with business on each Sprint to analyze the market and the value of our software, furthermore, it is recommended that our Product Owner belong to the Business unit.

And the most important thing! How can we increase the chances of success? In the case of product it is vital that the user is present. For that we do not stop doing inspection and adaptation with them.

It is not about doing what the user asks you, it's about understanding what you really need and providing solutions that give you value. There is a quote from Henry Ford that says "if I had asked my users what they wanted, they would have said faster horses".

If while your product grows you show the users, you will increase the options for that software to make sense and add value. In a project, the user does not usually comment because the mission is not to sell, only to meet the requirements that Business gave us.

Resource Efficiency vs Flow Efficiency

To sum up, it is worth mentioning the concept that Jerónimo Palacios taught us about the difference between Resource Efficiency vs Flow Efficiency.

When we do a project we look for resource efficiency, which basically consists of trying to have the whole team 100% occupied. In this way we encourage that the greatest amount of work is done, but there is a danger of falling into specialization.

In an Agile product, flow efficiency is further promoted, which consists of reducing the response time to the market in order to satisfy users and long-term sustainability of the model through shared responsibility for tasks. An example of this is the rise to production. In Scrum, we look for the increase that we have just generated from the first Sprint, ready to go up to production.

While in a project this is left until the end because it is more "efficient" (in terms of resources), to do everything at the same time and stage). Of course, this increases the risk that you accumulate a lot of untested software in the market and that no one wants it, Scrum tries to avoid it by putting the user as soon as possible to test your software.

The efficiency of resources is always associated more with projects because we have specialists that we try to keep busy. In a product, the concept of shared responsibility among team members is sought in order to bring the functionalities we are developing to the end user as soon as possible.

This is another reason why Scrum works better for flow efficiency, its events, roles and artifacts are designed so that the speed of interaction with the end user is fast.

How is a project transformed into a product?

Before finishing I would like to tell an anecdote. With a team I collaborated with recently I saw how they were transformed from project to product as a result of gaining the confidence of the organization.

They started, like any project, defining a scope and transmitted a date to the client, they reached an agreement and signed a contract. After several months, one day I asked the Scrum Master: When did you finish? The answer left me frozen: "I do not know... right now we are delivering in each Sprint what the Product Owner asks us based on what the users ask, we are signing contract extensions for months with no defined scope".

Although they still called it a "project" they had not realized that they had become a digital product.

Conclusion

Many companies understand the transformation on how to update their website to new modern technologies.

If you continue to make software based on undefined requirements, without having your user nearby, through personal bonuses to meet dates, with closed dates, then we cannot say that you are transformed even if you have microservices and a NoSQL database.

Whereas if you set up an Agile team around your "web" product, you work through investments, perform inspection and adaptation with the user and always look at the value it generates, then you are able to compete in the digital world.