From projects to products

During the meetup on Thursday 17 February, Caterina Palmiotto, agile coach and expert in team facilitation and team coordination, accompanied us with an in-depth look at the theme “from projects to products”.

Working with products vs working with projects

Product

When we talk about a product, we have to consider its entire life cycle and also understand what it means to “evolve the product”. The process, considered in its entirety, is used to understand whether the product you are working on really meets the needs of the end user.

On the right, an example of the life cycle of a product that allows the market performance of all phases to be considered.

Project

On the contrary, when we talk about the project – in its most classical sense, as a container that aims at the realisation and delivery of the product or its first release on the market – we refer only to a small part of the entire life cycle.

From this point of view, the project does not allow us to understand whether what we are creating really meets the needs of the final customer. Precisely, the biggest challenge begins when we release the first version of the product. It is at that point that we can start to gather the necessary information to assess how to evolve it in the subsequent phases.

Therefore, the key point is not just the making of a product. In order for it to be valuable for the customer, it is necessary to observe what happens when it goes to market and to collect user feedback throughout the process.

What happens when a project ends?

At the end of a project, almost all the people involved are allocated elsewhere and it often happens that only a few individuals are left to manage corrections and evolutions of the asset produced. These “unlucky” few will usually have to work on other projects, perhaps for most of their capacity. They will therefore have to manage product evolutions in their “spare time”.

This dynamic may lead to feelings of frustration and poor performance results, as it prevents the managers involved from both being able to concentrate on other projects and to be able to respond effectively to the last stages of the product.

As an illustration of this, when we talk about a product we have to consider the whole life cycle; project delivery is only one element within it.

The product and the MVP

We give priority to the overall result of our product
rather than the individual project delivery.

The product is an object of value. It creates value by responding to the user’s needs. It is not a list of functionalities, but a list of answers to the needs expressed by the customer.

The MVP – the Minimum Viable Product – represents the product in its simplest and most basic version (albeit in its crudest representation), which makes it possible to respond to the customer’s primary need.
For doing this, the production process must necessarily be user-centred, constantly considering his point of view for any decision about the product being made, and his or her point of view must be constantly taken into account in any decision about the product being manufactured.

The incremental iterative approach

In order to engage the user and keep the focus on their expressed needs, the Agile methodology uses an incremental iterative approach. This approach allows the company to constantly get feedback from the final user and to understand if what is being implemented really meets his request.

Few examples and some considerations.

1. 1. The incremental iterative approach to producing a car. In the first case, the solution will be to propose to the customer a basic product that already satisfies their main need and from which corrections and improvements can subsequently be made according to the user’s feedback.
   2. The incremental iterative approach to building a hotel reservation application. In the second case, only by deriving the essential functionalities will it be possible to build the skeleton of the first version of the product that meets the primary needs of the customer.
      Even in this case, the good can be corrected and improved according to the user’s own feedback, iteration after iteration.

The incremental iterative approach allows to make changes to the product step by step, according to the customer’s requirements: instead of offering a definitive product that satisfies all his needs only after the production of entire product, it is offered a basic product that meets the user’s primary need, so that he/she can start trying it out right away, and assess what secondary needs need to be prioritised.

A further consideration: by adopting this approach, the customer’s priorities may change and the final product may turn out to be different from what was initially imagined and requested.

The value

When monitoring the progress of the project, the approach considers two elements:

1. the effort our company is facing and, consequently, the remaining effort to realise the product initially imagined;
2. the remaining value that has to be delivered, assessed in relation to the overall need expressed by the customer.

The diagram shows how, by always prioritising the customer’s needs during implementation, the remaining value decreases exponentially, while the remaining effort decreases more slowly over the course of the iterations. If production is interrupted for any reason, the customer will already have received most of the desired value. The customer may also decide to stop production in order to save some of the budget because he is already satisfied with the given product.

The incremental iterative approach can exploit:

• user story points, for effort assessment;
• value points for understanding and assessing customer value.

This information is useful for prioritising the functionality that has to be implemented.

The feedback

The main objective of the incremental, customer-oriented iterative approach is to obtain feedback from the customer at each stage of the process.

It is therefore necessary to activate a feedback loop, through the following phases:

• definition of a product vision;
• construction of a backlog: i.e. the list of functionalities that can satisfy the customer’s needs;
• realisation of the product through an incremental iterative approach;
• collecting feedback from the user at each interaction, to understand if what is being implemented meets the needs;
• measuring the metrics established, to understand if the product is actually being used and what to do to improve its adoption.

From the last two steps, you collect data and information that allow you to update your vision and backlog to correct course and, for example, focus on a revised and improved target.

A critical step: questions and metrics

When defining the vision and the product roadmap, it is appropriate to imagine also a roadmap of questions to be answered throughout the product evolution.

In the first phase, therefore, you could have doubts and questions without a clearly defined answer; for each of these, you can propose assumptions on the basis of which metrics are defined.

Metrics have the function of constantly measuring and evaluating the effectiveness of the decisions taken. On the basis of the results obtained, it is possible for you to choose and prioritise the corrections that have to be made to the product and update the metrics accordingly.

A quote and a warning: Conway’s Law

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Melvin E. Conway.

In order to adopt an approach that puts the user at the centre, you need to keep business problems away from the customer product. Specifically, communication problems.

Consider an example of a typical communication barrier in silos.

Project Management and team

In a project approach, the main objective is to meet the budget and deadlines.

In such a circumstance, teams often experience overload and don’t even have time to ask what the purpose of the functionality is, which is usually required by another business department. And they are not even asked, because they just have to concentrate on “churning out” one functionality after another as fast as possible.

It is hardly possible to monitor whether what is being implemented is really useful, and the Project Manager will find himself making decisions without having a complete overview, as he will have information about the costs but not about the potential revenues of the product.

Product Owner and team

On the contrary, in an Agile context, where you focus on the product and on how to solve a need, the figure of the Product Owner is essential to facilitate communication between those who make the product, other company departments, the user and the external environment. In this way, the PO can collect and transmit all the information useful to make decisions on the evolution of the product.

At team level, the way people manage to work around the product will influence the realisation of the product itself.

For a good result, the team must be able to follow the entire product life cycle and continuously contribute to its improvement, following the various corrective and evolutionary steps until it is withdrawn from the market. The true product team should include all the people involved in the product lifecycle – from the analyst, to the release engineer, to the customer support person.

In this way, you can maintain the right focus on all phases of the lifecycle and a strong motivation to make the product maintainable over time. Such an approach favours workflow efficiency rather than resource efficiency.

The extreme of the product approach: the Haier case

Let’s take a look at a real-life case involving the Haier Group Corporation, a Chinese multinational. With the desire to push for strong decentralisation, Haier has gone to an extreme with its product teams: it has created a network of teams, each acting as a startup.

The organisation acts as an incubator for start-ups, supporting them with the necessary resources to grow them until they are ready to be launched on the market.
Their goal is to maintain a “zero distance” with the customer, turning mass production into mass customisation. They want to provide customised products and services to meet any customer need or desire.

The startups are independent in making their own decisions about the product, and the market will then determine whether the choices made were right or not. Haier has in fact put in place a profit-sharing mechanism that ensures to reward anyone who creates value for the customer.

This reality represents a co-creation and win-win system with absolute alignment on the goal to be achieved for all people involved.