The Product Owner Team

Guest contribution by | 10.10.2019

Scrum’s pure philosophy teaches us the Highlander principle: “There can only be one” – the Product Owner. Discussions about his or her tasks, responsibilities and what he or she isn’t are held regularly. And this Highlander thinking works like a dogma already from the beginning. What actually happens when a “submarine project”, usually aimed at innovative product development, suddenly appears in the organisation? Why? Because it is stuck and meets with increasingly less trust in its own organisation. The technical development team’s attempt to develop something highly innovative seems to fail. Product management and sales “know nothing” and the management wonders where all the development funds are going? What does our customer really want? Can we ever make money with the new product?

Hold it: Complicated or complex?

Let’s start with perception. When the above-mentioned submarine project was started, it was assumed that the complicated product development process could also be successfully applied in this project. Now, however, the project team does not deliver reliable results because it does not have too many components in its hands. The additional external know-how, the many external suppliers and the fuzzy project goal are to blame. Or could this have been foreseen beforehand?

A wonderful example of the transition from complicated to complex projects. Here and in the following, complexity for the sake of simplicity is used synonymously with uncertainty. If this difference is not perceived from the outset for an upcoming project, things often get out of hand. The overview is lost, the confidence in a diffuse project goal and the satisfaction of all involved parties dwindles. Due to the lack of perception, the participants could not be prepared for the uncertainty in the sense of prevention.1

In order to make the difference between complicated and complex clear once again, I like to use my flyer methapers. Motor flying is complicated and gliding is complex. Why is the latter complex? Because in gliding it is not possible to predict exactly where and when an updraft will be located that can be used for the reliable ascent of the glider. And because the cross-country glider pilot knows and has trained how to deal with this uncertainty, he can fly several hundred or even over a thousand kilometres in one day only with the forces of nature, without knowing exactly where the updrafts are located.

Start with the “Why?”

Back to our deadlocked project. One of the most helpful approaches to getting clarity about the status of the project is the question of “Why? What are you doing the project for? This question works wonders. Simon Sinek used this years ago in his lecture “Start with why – how great leaders inspire action”.2 At the centre of his “Golden Circle” is the “Why”. It refers to meaning and is directed towards the future. Only when people have a sense, a suitable “why” can they intrinsically commit themselves to a goal.

The meaning is not higher, faster, further, but rather represented in the metaphor of a “gift”. What is meant by this? In the end, the customer is enthusiastic about the new product. The organisation becomes more profitable with the new product. The teammate gets what he needs for his next step or the team delivers exactly what it promised. When all of the above occurs, it creates a positive energy, like a good gift that brings a smile to the recipient’s face. And not only that, it also makes the giver smile.

With the clarification of this question also the attitude of all involved can change. A vague project goal that is regularly iteratively and incrementally sharpened with the “Why?” offers the space and opportunity for an innovative product development that aims for a “meaningful gift” for all stakeholders. Thus, dealing with the uncertainty regarding the fuzzy project goal is a question of attitude. The uncertainty in the project goal can be reinterpreted as an opportunity for innovation (known as reframing in coaching).

The gift as a metaphor for the overall benefit

The project client is always the customer who is willing to pay for the added value of a product. He determines what his desired product (gift) must be like so that it becomes desirable and attractive to him. To determine the customer’s needs, there are a variety of ideation tools to develop innovative product ideas. These can be concepts such as Design Thinking and Customer Centricity or the Walt Disney method.

The results of this process lead to a “feature list”, i.e. a “customer wish list”. Features are characteristics, properties or functions related to persons and groups. These can be defined in “Feature Stories” whose structure resembles that of “User Stories” in Scrum. A typical formulation is: “As <role> I want <target/wish> to achieve <benefit>”.

From the point of view of the organisation that is to develop this product, however, the total benefit is not only the customer benefit of the “external customer”. Also important are the technical feasibility, the sense and finally the profitability of the product over the life cycle. In the sense mentioned above, in the end a meaningful gift for all participants only emerges if the overall benefit consists of one or more customer-related, technical and economic features.

Solving conflicting goals in the Product Owner Team

Let us remember the starting point, the deadlocked submarine project. The product management wants features that are not or not yet technically feasible. The technical project team deals with features that are hip, but bring only minor benefits for the external customer. The project management simply wants the budget and timeline to be adhered to. All contradictory requirements that have to be addressed, discussed and agreed upon in order to reap overall benefits.

In this situation, it is beneficial to take responsibility for the three views, the customer benefit (which always refers to the external customer), the technical feasibility and the economic benefit of people with different mandates. In this context, mandates mean assuming responsibility for the project in the sense of competence-oriented leadership. A type of responsibility and leadership that exists temporarily and is based on the fact that the person who is most competent in a specific area assumes leadership for a fixed period of time and accompanies the process. Ideally, an “overview team” is formed for this purpose, which overviews the respective areas of responsibility in the market and in the organisation.

Based on the role of the Product Owner in Scrum, a Product Owner Team is used in these cases, which is responsible for the success of the project. This construct of a Product Owner Team (POT) is a central component of the agilean approach.3 Agilean is a hybrid approach that holistically combines agile and lean approaches to accelerate complex product development, focus teams on customer benefits, and focus on the “why” of all participants. In our above mentioned project the customer perspective could be represented by product management, the technical feasibility by a systems engineer and the business perspective by project management.

Agilean Roles

Responsibility and tasks of the Product Owner Team

In the sense of competence-oriented leadership, product owners should both have profound expert knowledge in their area of responsibility and also have an overview of the areas of the other two so much that they can critically follow the argumentation and justifiably comply with or contradict it. With their mandate, the product owners as a team are jointly responsible for the project results, i.e. the “Why” and the “What? This means that they formulate the results that are needed to achieve the project goal from their perspective. In doing so, they can use the expertise of other colleagues from their areas to determine the objectives.

This in turn requires an often challenging agreement process, in which it has proven beneficial in practice to have the product owner team accompanied by a neutral coach. The coach’s task is to bring conflicts of interest back to a factual level, to create mutual understanding and to open up a solution space. The systemic question technique can often provide helpful services to clarify the different perspectives.4

In the agilean approach, this agreement process is referred to as a “conclave” because it is only completed (even without white smoke) when the Product Owner Team has agreed on joint project results in the sense of the “gift metaphor”. The results pay for the features mentioned above and are visualised in the form of a result scenario. This so-called “Stage-Result-Board”, in its origin a kind of Kanban-Board, is the compass for the whole course of the project. It is dynamically adapted to the current situation, whereby the goal of fulfilling the project features (the “Why”) serves again and again for orientation. An incremental and iterative approach is essential for the verification of customer benefit, technical feasibility and expected profitability. In agilean, the Product Owner Team manages the results in a lean manner and works agilely in dealing with uncertainty.

Bottom line

Innovative product development projects are now part of many companies’ day-to-day business. Often, the classic product development process is used because agile approaches “don’t work for us”. Perhaps it is precisely in such environments that an individual cannot keep track of everything and therefore lacks trust. For example, in the submarine project mentioned above, it is first necessary to restore trust in the organisation. The use of a product owner team, which brings in the mandates of different perspectives and also represents them in the organisation, has proven its worth.

 

Notes:

Product Owner Teams are part of the LeSS Huge framework.

[1] and [4] Uncertainty prevention and systemic questions to reduce uncertainty – Blog post by Astrid Kuhlmey
[2] “Start with why – how great leaders inspire action” – lecture by Simon Sinek
[3] Agilean approach in Detail (German): https://www.agilean.de

Prof. Dr. Volkmar Langer
Prof. Dr. Volkmar Langer

Volkmar Langer is a physicist and professor for “Networked IT systems and innovative learning formats”. As founder of the management consultancy LACOBE GmbH, he supports people, teams and entire organisations to develop their full potential.

This is where a hybrid concept of learning and working comes into play: agilean is the name of the human-centered approach, which not only contains agile and lean elements, but also gives teamwork a meaningful flow within a well-defined framework of action. As a trainer and coach, he trains master, product owner and coaches in the agilean approach.