The 8 Biggest Mistakes of a Product Owner

The role of the Product Owner is the most important role in a software development team. This role is far from easy, the area of responsibility is large and varied, the workload is usually as well, and so it may happen that “the seams start to burst” somewhere. I have compiled eight of the most common mistakes made by product owners that have the greatest impact in product development. So that the whole talk doesn’t get too negative, I also added specific tips on how to solve the situations.

• Mistake No. 1: Product owner doesn’t collect or ignores end-user feedback
• Mistake No. 2: The Product Owner Is Far Away from the Development Team
• Mistake No. 3: The Product Owner Doesn’t Have Enough Decision-Making Power and Credentials
• Mistake No. 4: The Product Owner Says “YES” to Everything and Doesn’t Know How to Say “NO”
• Mistake No. 5: Product owner forgets the big picture
• Mistake No. 6: The Product Owner Makes Too Detailed Plans
• Mistake No. 7: The Product Owner Tells the Team How They Should Work
• Mistake No. 8: The Product Owner Focuses on the Output and Not the Result

The role of the Product Owner in an agile team

Before we take the Product Owner to the table and dive into the mistakes, let’s take a quick look at the roles of an agile software development team. Strictly speaking, it is a Scrum team, but over time, the roles of the Scrum methodology have spread widely outside of Scrum and the role of the product owner has reached almost all agile teams.

The roles of an agile team are broadly divided into three:

• Product Owner (PO)
  Who gives direction to product development and validates the solution (and is not the project manager)
• Developers
  Those who build a high-quality solution include service designers, architects, programmers, testers, etc. – all team members who actually develop the product
• Scrum Master
  Who creates an effective development process (see more Who is a Scrum Master?)

The role of the Product Owner is the most important role in an agile team. It is his timely and well-thought-out decisions that are the basis for creating a successful product.

Dear Product Owner:

• knows the end users well and collects feedback
• is responsible for creating business value by constantly setting priorities
• defines the product vision and business goals
• makes decisions about what to develop in the product and what not
• is responsible for a clear and transparent Product Backlog
• monitors and analyzes the achievement of business goals.

The responsibility of the product owner is great and the field of activity varied, so it is understandable why not all tasks can be completed all the time. However, some of the Product Owner’s omissions can have a fatal impact on the entire project, which is why it is good to recall them from time to time.

Mistake No. 1: Product owner doesn’t collect or ignores end-user feedback

Despite the fact that the user-centered approach has long been widespread and popularized, there is a surprising amount of ignoring the opinion of end users. It occurs in both startups and mature products, and it always appears in a more or less hidden form. There are mainly two situations:

1. The product owner is sure that he knows exactly what the users want and doesn’t bother to double-check it.
   In words, it is of course oriented towards the interest of users, but there is no numerical proof of user interest, instead there is only the deep personal conviction of the product owner. A good example here is a startup manager who does not validate his idea with potential users and is unwaveringly sure that his product solution is perfect from the start. Or a product owner of a large e-service in the country, who, as a professional in his field, has developed a kind of tunnel vision that drifts further and further away from the simple skills and actual needs of ordinary end users.
2. The Product Owner doesn’t know exactly how to ask for feedback from users.
   This is a better option than the previous one, because at least the product owner is not ignorant, he simply does not have the necessary toolbox. There are many tools and tools for collecting feedback, but it is difficult to choose the right option that suits the situation. During intensive development activities, some methods are more effective (e.g. user test group, interviews, etc.), while during the calmer follow-up development of a mature product, others are more effective (e.g. satisfaction surveys, visitor statistics, etc.). The number and size of target groups must also be taken into account.

What to do?

Ask an expert for advice (or google it) and choose the right tools for you. Start with a well-thought-out and systematic collection of feedback from end-users and stakeholders and, of course, feedback analysis. As a bonus, you will have numerical evidence to justify development decisions or, for example, apply for budget resources from the board.

Finally, don’t forget the classic golden rule: “Don’t believe what users tell you, see what they do.”

Mistake No. 2: The Product Owner Is Far Away from the Development Team

Projects where the product owner either does not see the developers at all or is seen very rarely are seen more often in the public sector and in the case of larger projects (public procurements), but can also be encountered in the private sector when the client and the executor are different companies.

The classic situation is the following (and it is very stubborn to disappear): the customer’s product owner mainly communicates with the IT project manager of the development company (in larger projects, also with business analysts), who acts as the “interpreter” of the parties. The Product Owner usually does not meet or communicate with the developers. There is an expression about this that “developers are kept behind a wall”.

Such a “broken phone” style of work organization is far from agile principles and slows down development enormously, not to mention the high risk of creating “lost in translation” and incorrect functionality.

Developers must be able to ask about the idea and content of developments directly from the source and get quick and competent answers from the product owner. If this option does not exist and development is started on the basis of a user story description alone (which is never enough), then developers are forced to invent answers to their own questions. Or they ask their project manager, who politely waits until the next time they interact and asks the product owner the question, who then answers and the project manager sends the answer back to the developer, which creates two more questions for the developer and .. Do you see the pace?

What to do?

Involve the Product Owner in regular (e.g., 1x a week or every other week) development team planning meetings, where developers are introduced to the next developments that need to be started.

On the other hand, involve developers in review meetings aimed at the Product Owner, where the developers will receive valuable feedback directly from the Product Owner and, if necessary, can also assess the complexity of the Product Owner’s change requests on the spot.

Be sure to create a joint project chat where the entire development team and the product owner are present, who can quickly answer current questions.

If the Product Owner does not always find time for planning and review meetings or chat communication, they must appoint an authorized person (proxyPO) and give them the necessary credentials to make decisions.

Mistake No. 3: The Product Owner Doesn’t Have Enough Decision-Making Power and Credentials

In larger organizations, it may happen that the role of the product owner has been assigned to a person who does not actually have the right to decide on the development of the product. Of course, this fact becomes apparent quickly, because the developers do not get answers to their questions, and the product owner avoids making decisions in every possible way.

If most of the product owner’s answers are in the style of “I’ll talk it over in house and then let you know”, then it’s clear that someone else actually has the right to decide, or in the worst case, the product owner doesn’t have the courage to decide.

Of course, there are topics where the wider circle of the customer should be involved from time to time, but the product owner must have such a strong vision and understanding of the product that they dare and know how to make the lion’s share of the decisions themselves.

What to do?

The Product Owner must ask for and receive a decision-making mandate, either from the management or from their boss. If such a mandate is not to be given, the actual decision-maker must be involved in the project in the role of the product owner or the product owner must be replaced. Unfortunately, a change of product owner must be undertaken even if the product owner has a full mandate but does not have the courage to decide.

Mistake No. 4: The Product Owner Says “YES” to Everything and Doesn’t Know How to Say “NO”

This problem is equally prevalent across sectors and projects of different sizes. The company carrying out the development complains that “the customer wants everything, but they don’t have enough money” or, in the case of an in-house development team, “the business side wants everything, but we don’t have enough people”. The product owner, on the other hand, is dissatisfied: “I want to build an awesome product, but the developers are so slow” or “they are too expensive”.

If we leave aside development companies that are too slow and expensive at the moment (yes, there are unfortunately some on the market as well), then as a rule, this is a place where the product owner has to look in the mirror very deeply and for a long time.

Below is a slide that I spend quite a long time on during product owner trainings . The Pareto principle is like a law of nature that fits well in many different contexts. There are two messages hidden in this picture, one of them is good news and the other… Not so good.

The good news is that you don’t need to make 100% possible functionality to create an “awesome product”, only the most valuable ones are enough. And the wallet doesn’t have to be bottomless.

The second, harsher reality is that it is very difficult to find and pick out the winning 20%. Even with the 20/80 principle, a successful product owner has to make hundreds or even thousands of correct prioritization decisions – which feature is more valuable and which is not? What to do and what not to do? In what order should you do the feattures? What to do more thoroughly and what to do minimally? What do I have enough budget for and what do I not?

It’s endless and constant prioritization, and it’s up to the Product Owner and no one else to do it.

No product owner will ever have enough budget to realize all potential ideas and dreams in the product. It would also be a complete waste of money. The most important task of the product owner is to find and implement the most valuable 20% part and leave the remaining 80% undone. You have to be able to say “NO”.

Of course, the percentages of 20/80 may not always be exactly the same, but in general, the idea remains the same.

What to do?

The same recommendation applies here as with mistake No. 1 – if you are in the role of a product owner, constantly collect and analyze feedback from end users and other stakeholders (with numbers!), make decisions based on the product vision and the feedback received. Don’t fall off the train, don’t give up setting priorities even if it’s tedious and difficult, make few YES decisions and a lot of NO decisions, be strong and determined. This is the only way you can become a truly great product owner:)

Mistake No. 5: Product owner forgets the big picture

Product owners who have been working on the same product for a long time may get stuck in a time horizon that is too short. The same can happen in the case of a product owner who loves attention to detail or has a technical background.

Therefore, it is useful to rise above the level of everyday work from time to time and review the entire development direction, vision and business goals of the product as a whole – are we moving in the right direction, is the product roadmap realistic, are we still creating maximum value or maybe we have deviated, are we achieving the set business goals?

What to do?

Organize regular product vision meetings (e.g. quarterly) that would be important milestones and where necessary decisions are made in the long term. The big picture and product roadmapupdates should definitely be introduced to the development team, not only at the beginning of the project, but also after each major change. Understanding the big picture is very important and valuable for developers.

Mistake No. 6: The Product Owner Makes Too Detailed Plans

It is the natural responsibility of the product owner to plan the product, both in the long and short term. Planning is of critical importance in an agile approach, whereby the entire project is not planned in detail in advance, but details are only discussed in the near future. There is no point in planning the distant future in detail, because unexpected changes will happen sooner or later anyway.

All agile project plans are open to change and nothing is set in stone (usually there is a budget), but the plans are always there and updated (see more about agile planning Myth No. 4: There is no planning in agile development).

Also, do not write a detailed analysis document that is too long before the project, as was done in the old days in the waterfall era. This does not mean that a proper analysis is not necessary before the project. Prefer the pre-analysis option, which generally maps out all the necessary functionality and adds priorities based on business needs, but does not go into too much detail.

In an agile project, the Product Owner no longer requires the developers to follow a detailed terms of reference document to the letter, as in the case of waterfall projects in the past, instead, the details are specified before the start of each development cycle and written in the Product Backlog(which is also part of the documentation). This approach provides an opportunity to adapt to new changes on an ongoing basis and ultimately create significantly greater value.

What to do?

Apply agile principles when creating the product brief, and agile planning throughout the project. Accept unexpected changes consciously and calmly and adjust your plans accordingly.

Mistake No. 7: The Product Owner Tells the Team How They Should Work

This mistake may not have as fatal an effect as the previous ones, but it certainly does not have a good effect on the work atmosphere and motivation.

The responsibilities of the roles of an agile team set everything up well:

• the product owner is responsible for WHAT is being built
• developers are responsible for HOW it is built

(see again the picture of agile roles at the beginning of the story)

The Product Owner must describe the business needs as well as possible, what needs to be done in the product and why. However, there are usually several possible technical solutions and the decision on which one to choose must be within the competence of the developers.

Development work is very creative and a professional product owner (even if they have a technical background) will not take away the joy of creation from developers and impose their solutions. Describing business needs alone is a sufficiently voluminous job.

What to do?

In the role of a product owner, do your best to describe the business needs very accurately – who and why the functionality benefits, what problem it solves, what the expected end result should be. But don’t dictate how it should be done technically, trust your developers. Usability specialists create mockups in collaboration with programmers, and the product owner can give them feedback and recommendations.

Mistake No. 8: The Product Owner Focuses on the Output and Not the Result

If a product owner proudly announces that “My project was completed on time and on budget!” or “We always stick to the annual budget!”, then I have taken a closer look. Were these the only metrics that mattered? What was the main success criterion? If there are no other indicators on the table, then things are bad.

In that case, I am not convinced that this product will add any value to the world. If this value was not measured and considered important, it is unfortunately likely that the result was “yet another product“. We are back in the past 20 years old.

What to do?

Define and measure business goals both when creating a new product and during further development. Business goals must also reflect, among other things, the activity of using the product and user satisfaction. Never forget to validate whether the finished product is valuable to the end users/organization/world.

Summary

The role of a Product Owner is complex and requires a lot of dedication. At the same time, product development management is one of the dream jobs in the IT sector. Experience comes with time, but until then, you can learn from the mistakes of others and try to avoid them.

• Mistake No. 1: Product owner doesn’t collect or ignores end-user feedback
  What to do? Start collecting and analysing feedback in a well-thought-out and systematic way
• Mistake No. 2: The Product Owner Is Far Away from the Development Team
  What to do? Involve the whole team in planning and review meetings
• Mistake No. 3: The Product Owner Doesn’t Have Enough Decision-Making Power and Credentials
  What to do? Apply for the necessary credentials or carry out a change of product owner
• Mistake No. 4: The Product Owner Says “YES” to Everything and Doesn’t Know How to Say “NO”
  What to do? Make decisions based on the vision of the product and the feedback received. Keep in mind the 20/80 principle.
• Mistake No. 5: Product owner forgets the big picture
  What to do? Have regular vision meetings once a quarter.
• Mistake No. 6: The Product Owner Makes Too Detailed Plans
  What to do? Apply an agile approach to planning and creating a task
• Mistake No. 7: The Product Owner Tells the Team How They Should Work
  What to do? Describe business needs, but leave the technical solution to the developers
• Mistake No. 8: The Product Owner Focuses on the Output and Not the Result
  What to do? Make sure that the business goals of the product also reflect the activity of using the product and user satisfaction.

I wish you success in your role as a Product Owner! What lessons have you experienced?