The tasks and challenges of the product owner

For me, these three basic rules have proven themselves as a product owner:

1. Disassemble the elephant.
   Every task, every problem, every challenge can be broken down into smaller parts. 
2. Solve one challenge after the other and not all at once.
   Take one of the identified challenges, focus on it, solve it, and only then devote yourself to the next one.
3. Take a step back whenever possible, reflect on yourself and your work and expand your planning horizon.
   This way you don't lose the overview and you learn continuously.

In addition to observing these basic rules, as a Product Owner I have always set myself the following three overriding goals:

1. Always have a clear vision and communicate it to everyone.
2. Be aware of how you contribute to the success of the company with your work.
3. Exude enthusiasm for what you, as Product Owner, are developing with your team.

At the beginning of a project it is usually only a matter of starting the development of the Minimum Viable Product (MVP) as quickly as possible and without major problems. The entire work of the product owner should therefore be geared towards this goal. From my point of view, the necessary steps can be divided into personal and project-related preparation.

Personal preparation primarily involves dealing with your own new role as Product Owner. On the other hand, there is the necessary preparation of the project or product in order to be able to enter the development process.

Basic rule one says that one should break the big whole into smaller parts, then apply rule two and solve the challenge.
In my opinion, the search for the first problem is quite simple. In most cases you are the problem yourself. As the saying goes, "What you do often, you do well." However, if you are new to the role of product owner, you probably do not have the necessary experience and practice.

The first task in the context of personal preparation is therefore to deal with the tasks and responsibilities of the role of the Product Owner. Regardless of the method of later implementation (Scrum, Kanban, XP etc.), it is important to understand how professional, agile product development works.

One should always start with the basic pillars: What are agility and empiricism? Furthermore, a good understanding of lean principles and the "Manifesto for Agile Software Development" is a good start. Based on this, I can highly recommend reading books like "INSPIRED: How to Create Tech Products Customers Love" by Marty Cagan or "The Lean Startup" by Eric Ries. Of course, googling is also an absolutely passable way to grope your way slowly. The important thing is that you try to develop a feeling for what the team expects from you later on.

In addition to this self-study, I recommend that you also look for professional support. Especially for learning first methods for daily work, trainings, coachings or meetups can be attended or obtained. Large companies now offer a number of internal formats that project teams can use. If this possibility does not exist, it is advisable to bring experienced service providers such as Merkle on board and use their offers, e.g. for training.

Once you have a theoretical understanding of what the role of the Product Owner roughly involves in terms of technical requirements, powers and tasks, it is advisable to make a comparison with your future role in the project. Here, the central question is whether the framework conditions allow the role to be performed professionally.

In the following I have compiled a small list of initial questions to check the role of the Product Owner in the project:

• Do I have the authority to make operational and tactical decisions in the development process alone?
• Do I have the budget to realize my project and can I make decisions on my own responsibility?
• Do I have the necessary backing of management positions?
• Do I have sufficient time for my role as Product Owner?
• Can I contact other departments or stakeholders without hurdles?
• Am I able to work with the development team on a daily basis?
• Am I able to argue professionally confidently in the domain of the future product?
• Do I roughly understand the technical framework?
• Is a personal, local cooperation with the implementation team possible?

These questions do not necessarily all have to be answered with a clear "Yes" in order to do a good job as a Product Owner. However, a positive answer to the first points on the list will considerably increase the chances of success of the project.

In addition to these outwardly directed questions, a prospective product owner should also ask himself the question of how he and his team can get excited about the upcoming challenges. A good Product Owner lets his fire spread to the team and offers the "why" around which the team can form. Only if the product owner himself has a clear vision and represents the added value of the company will his enthusiasm infect others.

A good start for the development of an idea, for example, is a filled out Business Model Canvas. The value proposition in particular should clearly show for which target group, how and on the basis of which concrete gains and profits you want to develop the content of your product. The remaining fields serve primarily to make people aware of the economic context in which they are operating during and after development. Of course, a good business model also supports internal argumentation or justification for investment decisions and can be used for product marketing purposes.

Subsequently, it is recommended to transform the value proposition into a vision. Templates such as Roman Pichler's "Product Vision Board" or simple methods like the Elevator Pitch Template and the Vision Box can be used for this purpose.

The vision serves primarily as a model for product development. In the course of development, it is up to the product owner to decide to what depth and breadth he wants to shape his product and in which areas money should be invested. In order not to lose track of this task, I as a product owner can use the vision to check and align my decisions with regard to their business value.

In summary, the personal preparation is primarily intended to become saddle-fast in the professional domain, product vision and one's own role.

As a complement to personal preparation, development must also be placed on a solid basis for long-term success. Here I would divide this area into three fields of action:

1. Putting together a team
2. Hypotheses and requirements
3. Control mechanisms and processes

Let us first look at the "Team" field of action. Here, the product owner should, depending on the framework, seek to close ranks with other roles. In Scrum, for example, the Scrum Master should be closely involved in order to enable the development team to achieve their best possible performance.

First of all, it is important to understand that product development is in the area of knowledge work. If one follows the systems theorist Helmut Willke (Organisierte Wissensarbeit, 1998, p. 161), this is accompanied by the challenge that knowledge can become obsolete and must be constantly renewed. He also states that one simply cannot know everything.
These basic conditions already show that a team is needed that is willing to work continuously on itself on the one hand, and on the other hand that deliberately brings together diverse competencies and knowledge. The team as a whole is the decisive factor for this type of work.

In this context, I would like to join the well-known product manager Marty Cagan (INSPIRED, 2018, p. 33) in recommending to every prospective product owner that he should ensure that his team is made up of the best people he can find as knowledge carriers. Only a cross-functional team of capable people will ultimately build the best possible product.

Once the product owner has assembled his team from a professional point of view, it must be checked to what extent the colleagues are already familiar with agile working. It may well be the case that a colleague is absolutely suitable from a technical point of view, but his/her working methods or personal principles are not compatible with the principles of agility (see Manifesto for Agile Software Development). The product owner should probably then do without this colleague in the team.

The consideration of experiences with the framework should also not be underestimated when putting together the team. Depending on the level of maturity of the team, it is in the product owner's interest to train and educate his colleagues. This is the only way to ensure that he/she will continue to have the best team for the job behind him/her. As mentioned earlier, training is a good first step in this process.

In my view, another decisive facet of functioning teams is a clear understanding of team roles. Everyone should be aware of who the Product Owner is and why they hold this position. Depending on the framework, the other roles should also be specified and explained. A clear definition of the roles helps to avoid overlapping in competences and tasks and to keep track of what can be expected from whom.

Explicitly not meant here are roles like "Tester" or "Delivery Manager", because in my experience these roles are mainly used to delegate unwanted tasks away. The team members have to be aware of the fact that in the course of product development the constellations change and have to be adapted to new situations. The agile principle "Inspect and Adapt" applies here as well.

In addition to clear roles and a well-trained and diverse team, what is needed above all is a common direction - in other words, a common vision. The better the Product Owner has worked this out in the course of personal preparation and, if necessary, validated it, the easier it will be for him to convince his team. As I mentioned before, in my view one of the product owner's central tasks is to gather his team behind the vision and to answer the "why" clearly for everyone. Knowing the value and meaning of one's own work within a larger context is a key driver of motivation for each team. Ultimately, everyone in the team should be able to answer the following questions: 

1. Who is our target group?
2. What needs of our target group do we address?
3. How do we contribute to the success of the company?

In addition to the team-related aspects, the vision forms the basis for development and thus for the professional requirements.
This is where principle number 1 comes into play: dismantle the elephant. The task of the entire development team, including the product owner, is now to break down the vision into smaller packages and formulate initial hypotheses.

Ultimately, it depends on the task at hand, at what flight level the hypotheses are located and whether one starts completely on a greenfield site.
The lower the experience in a given area, the more likely it is that a design sprint, for example, will be necessary to identify the greatest challenge within the vision. For this, a solution hypothesis is developed, which is roughly tested at the end of the Design Sprint. The result can be used to enter into detailed implementation later. During the solution finding process, new requirements and hypotheses will arise, which will bring us closer to the vision step by step.

However, if you are moving in an area in which you already have a lot of experience, you can resort to concrete methods. If, for example, you want to develop an online shop, the underlying customer journey is probably relatively clear and the first tasks are usually obvious. In order to obtain the first working hypotheses, the product owner could set up a story mapping workshop. Hypotheses, for example, in the form of user stories, are formulated here for the operation of the individual customer journey steps.

The business model of the product owner is always the starting point for hypothesis development. Later on, it serves as a model to avoid getting lost in the jungle of ideas.

The last, but no less important field of action in the context of development-related preparation comprises the elaboration of work processes and steering metrics.

In addition to his role as visionary, the product owner is also a "value maximizer". It is also part of the Product Owner's job to ensure that the investments are worthwhile and that he can prove this.

A first step to show the added value of the development is to provide the hypotheses with an expected business value. Of course, this value is also an assumption and includes various dimensions:

1. Business value - everything that pays directly into the profit
2. Market value - estimated enterprise value
3. Efficiency value - increase efficiency and reduce operating costs
4. Customer value - value of a customer for the company
5. Costs due to delay - opportunity costs and risk

The product owner must decide on a case-by-case basis whether the solution of a hypothesis will pay sufficient attention to the dimensions. Accordingly, business value is one of the central prioritization metrics, along with effort, risk and dependencies.

Behind each of the individual dimensions there are also measurable KPIs, which are used to check whether the hypothesis has been fulfilled after a release. For example, surveys could show that customers of your B2B online shop know their products by heart, but have problems finding them in the shop. By focusing on product search, it is hoped to increase sales by 5% and customer satisfaction by 7%, as well as reducing bounce rates by 2%.

Now one should always test this solution prototypically to assess to a certain extent whether it will work. Ultimately, however, the value remains an assumption until it is proven by the market. This means that only the release to the customer and the measurement of the KPIs can provide clarity. These metrics should be incorporated into the work of the product owner at the strategic, tactical and operational levels and should be consistently demanded by management. In this context, another task of the product owner becomes apparent: the management of stakeholders.

Roadmaps are a proven tool. They serve as a basis for discussion and planning and thus ultimately for transparency. The problem with roadmaps, however, is that they are often seen as dogmatic and detailed plans that must be adhered to. The alternative is problem and hypothesis-driven planning (Marty Cagan, The Alternative to Roadmaps, 2015).

In order to create the necessary planning transparency both internally and externally, the product owner should therefore draw up a roadmap that shows the following points:

1. When roughly which hypothesis should be approached 
2. Which technical dependencies exist
3. Which technical dependencies exist
4. What dependencies to management and business (steering committees, trade fairs, etc.) there are
5. How to plan financing (e.g. financial deadline)

When using roadmaps, it is important to check and update them at regular intervals. If this is not done, they lose their usefulness and do more harm than good.

Now that I, as product owner, have formulated a vision, assembled my team, formulated initial hypotheses, defined their metrics and made a rough plan, the question arises of how to put all this into an operational mode.

A typical development process extends from the generation of ideas, through the sharpening of initial implementation approaches and finally culminates in concrete implementation and optimization. It is the product owner's job to ensure that what he has in mind is delivered. Only in this way can he approach the vision.

As long as I as a product owner have not gained enough experience to set up a process myself without violating the principles of agility, I should fall back on proven frameworks such as Scrum or Kanban. These can serve as "support wheels" and with their rules, metrics and the numerous literature they can make the start of the implementation much easier. The more experienced the entire team and the product owner become, the more meaningful and easy it will be to adapt the process to their own needs.

At this point I would recommend every Product Owner to get advice and support and to join forces with Agile Coach, Scrum Master etc. If you work together with service providers like Merkle in your setup, you can also rely on their consulting competence, e.g. through Product Owner Consultants.

A good personal and developmental preparation and the confrontation with the domain are the basis for successful product developments, satisfied teams and ultimately satisfied customers.

The tasks one faces as a product owner seem overwhelming at first. However, if you follow the steps mentioned above, it can be easier to get started. First of all, you check your own abilities and your own position. Then you develop a vision, put together the best team in the world and get your colleagues involved in the idea. Once this has been achieved, the first requirements are established in the form of hypotheses, parallel metrics for measuring success are developed and a rough plan is drawn up. The final step is the definition of an implementation process involving the team.

What follows is the first step on a journey that may not always be easy, but is in any case exciting, instructive and formative: The processing of the first disc of the elephant.