Agile Projects: 5 Mistakes Product Owners Should Avoid

Agile projects have become the norm in software development outsourcing. In working with a wide range of different companies and products, we’ve seen all of the different ways projects can go off track and result in disappointment, frustration and mediocre results.

Here are the five common mistakes product owners make and what you can do to fix them.

1. Missing a Shared Product Vision

Each team member has their own expectations and skills invested in a product’s success. So how do you ensure their visions align? First, the product owner must define a vision based on the input gathered from each team member and ensure that everybody then adheres to that vision.

There can never be enough communication about the vision of a product. Of course, the product owner needs to know what to build and why, but they should empower the development team to decide how to create it.

A misaligned vision can occur when the product owner has a technical background and explains their vision in those terms. But people may not understand the overall concept through those technical details. Therefore, the owner needs to communicate at a business level to clarify their vision.

Recommendation: As emphasized by Roman Pichler, a product management expert, “The vision should communicate the essence of the future product in a concise manner and describe a shared goal that provides direction but is broad enough to facilitate creativity.” An essential part of the product owner’s mission is to make sure that everybody on the team has a good understanding of the product vision so that their collaboration is meaningful.

Additional resource: “Agile Transformation: Connecting the Dots of a 2-year Transition to Agile Best Practices”

2. Shared Product Owner Responsibilities

Two product owners are assigned to a single project: what could go wrong with that? Turns out, when the first person starts to work on the project, the second one stays away. Then, the second person comes into play, and their perspective changes or invalidates the first team member’s vision. The result is wasted work, creating tensions between the two team members.

When there are two product owners on a project, each of them will likely focus on their own assignments while losing track of the bigger picture.

The impact? The development team might missalign user journeys, define different UX standards or even develop things in a technically incompatible way. Worse, development team members no longer know who is leading the project. The result is a longer waiting time and delays in the decision-making process — not to mention that the stakeholders aren’t sure who should be providing updates.

Recommendation: It’s possible to have multiple contributors. But, we recommend assigning a single product owner and involving others depending on their skills or the product’s needs. These teams might include business experts who will help create and define the product, technical experts who will be a part of the development team and stakeholders with specific expectations for the project.

Additional resource: “IT Outsourcing: Should the Product Owner Come from the Client or the Provider?”

3. Poor Backlog Management

Imagine bringing on a development team with industry experience, but the product owner starts the discovery phase in isolation. Then, after doing their research, they prepare their first backlog only to realize that the development team has such rich industry experience that they should have been brought in to contribute earlier. Involving the development team late in the process may change the overall road map and generate many issues that were already widely communicated.

Recommendation: The product owner should bring in the development team early to help with alignment and save time and money.

Additional resource: “Critical Checkpoints in Scrum — Part 1 — Release Planning”

4. Failure to Adapt

This issue occurs when the product owner has a vision and a plan but doesn’t pay attention to market signals. Instead, they impose a vision and don’t care about what people want and are willing to pay for. The product owner should be ready to adapt the product road map and even change the vision accordingly.

A good product owner should think like an entrepreneur. They should think beyond the project and how the product will help the organization grow.

Recommendation: The product owner should involve the stakeholders (end users, sponsors and so forth) to validate every hypothesis. Involving stakeholders often allows them to integrate feedback into the developed product quickly. If stakeholders don’t see the product, they may develop unrealistic expectations for the project, creating a higher chance for the product to be perceived as a disappointment. Therefore, the product owner must invite stakeholders and their representatives to review meetings, release the product on the market as soon as possible, get real-time feedback from the market and define new hypotheses.

Additional resource: “Gathering Reliable Data to Appreciate Agile Performance, from Developers to the CEO!”

5. Poor Understanding of the Business or PO Best Practices

If a product owner lacks knowledge, this usually shows up as a lack of industry knowledge or familiarity with well-understood PO working methods.

The product owner may only have business knowledge, which doesn’t necessarily mean that they are a good product owner. In this case, the scrum master can typically coach the owner on the best practices and offer support.

The product owner may only know product ownership best practices and nothing about the business. But understanding the company is imperative. Suppose the product owner is unfamiliar with the industry. In that case, they will find it hard to understand the market and the needs of end users and other stakeholders, ensure a coherent business flow and deliver value.

Recommendation: The ideal product owner masters both the business and product ownership best practices. If this isn’t possible, it’s better to assign a product owner who has mastered at least one and shows the willingness to learn the second quickly. If the business is simple, it makes more sense to focus on product ownership best practices. If the business is more complex and has a high learning curve, it’s best to take a person inside the company and train them on product ownership.

Last but not least, it’s essential to make sure that the entire scrum team is cross-functional and has all the required skills and means to deliver increments autonomously.

Understanding the difficulties a product owner may face on agile projects can lead to improvements that can boost product quality and fit – not to mention development velocity! If you want to learn more about the topic or have a project you need help with, contact our experts.