From project to product.
Do your teams work to fulfil a project plan or to solve the real needs of your customers? In agile software development, product ownership is the unifying force. In this article, we describe the strengths of a product-oriented organization with clearly anchored product ownership.
The traditional approach to product development is very centred around projects. When a new product is about to be pushed out or existing products are expanded, the classic approach is to define a project lead by a project manager. Project managers are key roles who are experts in managing projects from specifying requirements and throughout a series of different phases to the final launch and commissioning.
Whether you work with digital or physical products, the process of a project will represent an investment. The investment will only start to pay off when the final product is available to customers. The development of digital products differs significantly from the development of physical products. One of the primary differences is that digital products do not have to be physically produced. The path from new products or product extensions leaving the hands of the developers until it is distributed to customers is therefore much shorter. It also has the possibility of delivering an early and incremental value creation. As a direct consequence of this, long phase-divided project processes are not an approach that naturally supports the development of digital products.
The second article in this series (Do you know or do you assume?) was dedicated to the uncertainty that is an integral part of the development of new products. This applies to both digital and physical products. Therefore, an iterative development process enables an earlier verification of your product and is a powerful tool for reducing the risk of resources being invested poorly. This is illustrated below.
Is your focus on delivery?
In the development of digital products, a classic project-oriented approach to product development can be a limitation on the business impact. One of the primary reasons is that projects are often based on a basic premise that the content is known in advance. This is rarely the case that you, as a company, have all the necessary certainty before a project starts. As a result, the focus of the project organization often becomes the delivery of the specified scope within the project’s budget and time frames.
A visual representation of a traditional and agile approach to software development is seen below. In the traditional approach to project management, the scope is determined at the beginning of the project, where the budget and time frame for delivering the scope is estimated. In contrast, it is the budget and time frame that is determined in the agile approach, where it is estimated which scope best meets the business’ goals.
An agile approach to product development is far more supportive of working from a product-oriented mindset. A product-oriented way of thinking is characterized by the development being based on a holistic end-to-end understanding of the product, where the outcome is above output. That is, the business impact is prioritized over the list of fulfilled requirements and is the driving force for the development team.
Without a strong focus on the product, it is very difficult to succeed in implementing agile methods. Without the right focus in the organization, the agile teams do not have the necessary framework, and the implemented agile methods become primarily an operational exercise for how the established scope is broken down and executed.
Do you dare release?
In the development of a new product, there will always be a phase in the development process before the product is put on the market. However, the product needs to be released quickly to establish an organization that works from a product-oriented mindset. Therefore, a difficult and always present question is; what and when should we release?
A very well-known example where the right balance was found is in the development of Danske Bank’s “MobilePay” which today is one of the most widespread and used apps in Denmark. MobilePay was developed by Danske Bank in a short process, where the product was taken from concept to release in 6 months.
During the same period, a competing solution, Swipp, was developed in collaboration between a large number of other banks in Denmark. MobilePay and Swipp were launched within a few months, but Danske Bank succeeded in winning the market. MobilePay as a case is very exciting precisely because many of the necessary prerequisites for developing successful digital products were present.
In line with the topic of this article, there are two things, in particular, that should be highlighted. Danske Bank came first and they launched a product that solved the primary need of their users. By focusing on the most important need, they managed to find the balance between releasing early and launching a value-creating product at the same time.
Releasing a product that does not include all the features on the wish list can be difficult for many companies. However, it is important not to set all one’s visions as prerequisites for release. By contrast, it is not a good strategy to release a product that does not solve the real needs of customers. It is a balance and we recommend that the first release should be focused on solving the most important needs of the customer. It can feel transgressive and require courage to release early. But it is a less risky approach and the further development of the products will be more in line with the users’ real needs and wishes. A good illustration of the incremental development of a product is seen below.
Product ownership
In an organization where a project-oriented mindset is very widespread, the project manager is found as a central role. In an organization that works from a product-oriented mindset, the product owner is to a greater extent the unifying force. It is very important to have well-established product ownership in the organization. This is done by having one or more “product evangelists” in the organization who knows all about the product by heart and who carry the visions and direction for the product’s development. Product ownership must not be exclusively reserved for individuals but must be rooted in the teams that develop and operate the product. It is important that the teams work towards the same shared goals that are based on a value-driven development of the product rather than meeting a number of requirements in a project.
The product owner, as the role is defined in Scrum, is very common but very difficult to fill. It is a complicated role that requires many different competencies. Besides being a challenging role, it is also a difficult role to implement for the organization. Around the product owner, there are a large number of anti-patterns. Among the most common is that the product owner is not authorized to make decisions. Without the necessary authorization, he or she often ends up acting as a proxy for one or more stakeholders. In such cases, the role is reduced to a backlog administrator who, with the best effort, collects and prioritizes wishes that are not necessarily coordinated with maximizing value creation.
Key takeaways:
-
In order to have lasting success with the development of value-creating products, it is important that the organization works from a product-oriented mindset with a focus on outcome over output.
-
To quickly move from project to product, it is important to release early
-
In a product-oriented organization, product ownership, rather than project management, is the total force.
-
In order to anchor product ownership in the organization, it is important that the product owner and the development team are authorized to make decisions.
See below for more information on the MobilePay case:
-
MobilePay won by making the complex simple.
-
What project managers can learn from Danske Bank.
-
Behind “The man behind MobilePay”.
