We’ve introduced you to many roles in our company already: the different roles of developers, our Designers, the UX team, and our Scrum Masters - but we never talked about Product Owners, or in short - POs, until now.
According to the Scrum framework, the job of a Product Owner might appear as a clearly defined role which is occupied with less obstacles than others. A PO is “just” the one who defines the backlog tasks and the sprint’s direction. But it’s sometimes not as simple as that. There are moments in every PO’s working life where they need to be the rock in the sea, while actually feeling like sitting in a nutshell thrown up and down by the waves. But let’s have a look at this job in detail - what are the challenges POs have to deal with? And which role do they actually take over in a Scrum team?
Searching for good solutions instead of bad compromises
It differs from company to company how much a PO is involved in the stakeholder management. But a PO cannot do a good job without getting in touch with several opinions of the people they are working with.
There is marketing telling them, that the feature is good, but not outstanding - so the team should invest more time to enrich it with additional features. Sales colleagues on the other hand need features to present the product as a powerful package - so the team should come up with more features in a shorter timeframe. And there might be a CTO who wants to see topics on the roadmap that improve the technical part of the product - but will never be directly displayed to a user.
As you can see, in the worst case there are various opinions that would lead to different product directions. And most of the time, they are more or less ALL VALID. So, sometimes POs need to be an octopus with people dragging on each of its eight arms, and still come up with a good solution instead of a bad compromise.
Overcoming challenges and being successful
Collaborating with the development team at eye-level in an atmosphere of trust and respect is the key to be a successful PO. Nevertheless, there are sometimes stumbling blocks lying on the road that might complicate the communication between the Scrum team and their PO.
Managing resources
According to the Scrum Framework, the PO and the development team have a sprint planning where they commit to a certain range of stories, and a sprint goal that they would like to tackle. But it’s real life: different issues can always occur on the way to implementation, and your commitment will not work out: Colleagues get sick, unexpected problems come up, the task leads to new questions that need to be solved first, … and so on. But still, you have a communicated deadline you have to stick to.
In this situation it is up to the PO to push the team, and motivate it in order to meet the deadline without burning human resources. This is not always an easy task. It’s about keeping motivation high, shifting priorities, and making concessions. But working under a high workload and time pressure will only work out for a limited time period, and if the team relationship is based on trust and respect - as mentioned above.
Keeping up perspectives
Every team needs a perspective. Questions such as “What is the product vision?” and “Is it reflected in the backlog?” need to be answered. A PO stays in contact with many people in and outside the company, and collects a bunch of information about the product and the market. But what exactly should a PO communicate to the team, and what is only deflecting them from their work? Forwarding everything to the team would be as useful as not communicating anything. In both ways, a PO would fail in giving the team orientation. So, a PO needs to strike a balance in order to enable the team to create a good, user-centric product.
Rocking the daily business
It catches us all. But the team should never get the impression that they are in a rat race. With the retrospective, the Scrum framework provides a good atmosphere for every team member to express their feelings. But it’s also up to the PO to motivate the development teams by given them space for own ideas in tasks, leaving open slots in sprints, and letting them also pull issues and tasks they’d like to work on. Maybe even by planning whole days to tackle more technical tasks that are not presented on the roadmap.
Staying open-minded
Another important aspect: A PO should stay open-minded, and try to keep a neutral perspective on the product. Even with a totally new project, it might only take six to ten weeks to lose this perspective, suddenly no longer being open-minded and sticking to internal restrictions.
When coming across a cool new feature the first thought should never be: “Great feature, but we can’t do this for our product, because we have technical restrictions, and costs would be to high”. So, POs sometimes need to push themselves and reset to zero. They need to assess the benefits that a feature brings to the user and weigh over the challenges that implementation brings. Sounds easy, but this can sometimes be the hardest part of the job. But if a PO manages to tackle this, not only the product, but also the personal working life will benefit.
Challenge accepted!
All the mentioned points above may sound like being a PO is a struggle - but this is not about complaining. Sure, all these aspects are challenges, but they are also the reason that gives the job its attraction. You are working with your team on a very exciting and varied field of work. By involving lots of people you never stop learning and gain new perspectives and ways of solutions.
About the author
