Agile projects have become the norm in software development outsourcing. Aligning with the agile best practices and masterly implementing them on your agile projects is no longer an option if you care about your reputation. We are fully aware of what it takes for an agile development project to be successful. But what if we also knew what could go wrong and avoided doing it in order to spare the entire team of disappointment, frustration and mediocre results?
Based on our experience on agile product development, we have thought of 5 things that the Product Owner might do wrong and how to fix it.
Let’s see them in more detail below:
1. The Product Owner does not make sure the entire Scrum team shares the same product vision
There are various people with different expectations and skills interested in the product success. The question is how to ensure their energy convergence? It is essential that the Product Owner defines a vision based on the input gathered from all of them and then makes sure that everybody adheres to that vision. There is never enough communication on product vision. It is important to be the owner of what and why to build and let the development team deal with how, meaning empower them explicitly on that aspect. There are cases when the Product Owner has technical background, starts telling people about his vision and functional flows to further go into technical details. But people do not understand the vision, the business flow and his technical advice is not good enough to make the best recommendations. He needs to communicate more at the business and functional level.
Recommendation: as emphasized by Roman Pichler (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”. So it would not be wrong to say that an essential part of the Product Owner’s mission is to make sure that everybody in the team has well understood the product vision and that their collaboration is meaningful.
2. The Product Owner’s responsibilities are shared among different people
We may stumble on the following situation: 2 people are assigned on a project and share the Product Ownership responsibilities. When the first one starts to work on the project, the second one stays away. When the first lefts, the second one comes into play and his perspective either changes or invalidates the first one’s vision and roadmap. Part of the work is wasted and creates tensions between the two of them. When there are 2 Product Owners on the project, it is highly likely for each of them to focus on their own assignments and locally optimize while losing track of the bigger picture. The impact? The development team might not be able to close flows, might have different UX rules and even develop things differently or things that are technically incompatible. They no longer know who they should listen to or to whom to go to unblock a situation. The result is higher waiting time and certain delays in the decision making process. Not to mention the stakeholders. They do not know who they should ask about the product and who has the overall picture.
Recommendation: we admit, however, that it is possible to have several persons contributing to product management and that it would be wrong not to exploit their potential. We recommend to assign a single Product Owner on the product and involve the others depending on their skills or the existing needs: business experts (who will help the Product Owner create and define his product), technical experts (as part of the development team) and other interested parties that have specific expectations and can act as stakeholders.
3. The Product Owner does not involve the development team enough in backlog management
Imagine the development team has a business experience in the field where the client wants to develop his product. Even so, the Product Owner starts the discovery phase working alone: understand what competitors do, who the users are, define his vision. He works very hard to prepare his first backlog version to present to the development team until he realizes that they have such a rich experience that their input changes most of what he has done so far. Moreover, the technical hypotheses, risks and constraints are not dully taken into consideration for backlog definition and ordering. The late involvement of the development team may change the overall roadmap and generate many issues that were already widely communicated.
Recommendation: the Product Owner should give more credit to the development team from the very beginning. This will help him save time and money.
4. The Product Owner does not adapt to change (lacks an agile mindset)
The Product Owner has a vision and a plan but does not pay attention to the signals the market is sending him: he does not release the product on the market as often as possible or he does so but adopts a push instead of a pull strategy. He imposes his vision and does not care about what people want and are willing to pay for. He should be ready to adapt the product roadmap and even change the vision accordingly. A good Product Owner should think like an entrepreneur: think beyond the project, think about the product and how it changes the organization and makes it grow.
Recommendation: the Product Owner should involve the stakeholders (end users, sponsors etc.) in the validation of his hypotheses. He will thus have the chance of integrating quick feedback in the developed product. If they do not see the product, they can imagine anything else and it is possible for what they have imagined to have nothing to do with the product. Thus, higher the chance for the product to be a disappointment at the end. Not because the product is not good enough but because it does not rise up to their expectations. The Product Owner must go out of the loop and invite the stakeholders’ representatives to the Sprint Review meetings, release the product on the market as soon as possible, get real feedback from the market and define new hypotheses.
5. The Product Owner does not have enough knowledge about business or product ownership practices
There may be 2 extremes:
1. The Product Owner may only have business knowledge. If he knows the business very well, this does not necessarily mean that he is a good Product Owner. Nevertheless, this skill is a must-have because the Scrum Master is there to coach him on the best practices and offer his support on either sides.
2. The Product Owner may only be aligned with the product ownership best practices. But as the need is often linked to the business and expressed in business terms and specific flows, learning the business is imperative. If the Product Owner is not familiar with the field, he will find it hard to feel the market, the end users’ and other stakeholders’ needs, to ensure a coherent business flow and finally to deliver value.
Of course we may think of the situation when the Product Owner lacks both knowledge about business and product ownership practices. But we will not go in that direction because it is quite easy to guess that the chance of total failure is very high.
Recommendation: the ideal case would be for the Product Owner to master them both. If this is not possible, it is better to assign a Product Owner who masters at least one of the two very well and who shows the ability to quickly learn the second one from a coach, from the Scrum Master or by himself. In other words, if the business is simple, it makes more sense to focus on product ownership best practices. If the business is more complex, with a high learning curve, it is recommended to take a person from inside the business and train him on product ownership. In the end, a Product Owner should be able to master both skills. Last but not least, it is important to make sure that the entire Scrum team is cross-functional (has all the required skills and means to deliver increments autonomously).
These are just a few of the difficulties a Product Owner may face on his agile projects. If you want to know more about the topic or have a project you need help on, contact our experts.
You may also be interested in:
Tags: Agile methodology