How to Make Your Team's Collaboration With the Product Owner More Efficient
Maintaining the efficiency of our teams is one of the most important roles of a Project Manager in Netguru. While we tend to it in every project, there is no universal recipe for it, as each of our team setups is unique.
One of the pieces of the puzzle that differ the most is the Product Owner – as they come directly from the companies we work with, they have different backgrounds, experiences, and working cultures. A product owner’s involvement is key to the success of the product you are making – it’s vital that we, as PMs, make sure the cooperation goes smoothly for everybody involved.
This article is based on the presentation I gave at RevolutionConf 2019, an IT conference that brings together people of diverse specialties and gives them space to share their experiences.
Making sure you are one team
The first thing to do is check whether your PO is actually a member of your team on equal terms. This is a pitfall a lot of projects fall into: the Product Owner and the rest of the team have asymmetric relations, where the PO is the person in power, whose chief focus is to communicate their requirements and oversee the delivery of the results, while not being open to collaboration. This means that the PO is not a team member, they act as a supervisor and are treated like one. This really hampers sincere communication and improvement in general. While this may sound harsh towards Product Owners I’m working with, this is not my intention. I believe we all sometimes have instinctively limited trust towards others and there is no bad faith in it.
The situation described above is wildly different from a setup where we establish a horizontal relation of partnership, and work together as one team – addressing our difficulties and assuming everyone's best intentions. One way of starting the shift in the mindset here is to discuss the project goals – to make everybody aware that they are, in fact, common for everybody here. If you feel like I’m stating the obvious, think if you’ve ever had a moment when it felt like the PO’s goal was to manage the team to do what they want, and the team just wanted to get those particular things done and be left alone.
What close collaboration means in daily reality is that the PO should be present and participate in all team meetings actively. This is especially true for the retrospective, as this is a starting point for further improvement of the cooperation. Theoretically, this is exactly in line with what Scrum recommends. In reality, though, the PO very often operates separately due to time constraints, feeling irrelevant in the meetings, or the rest of the team not being open to allow his presence at all meetings. You should not permit this kind of thinking to stop the PO from getting truly involved. Instead, make sure that if any of the above issues turn out to be true, they are addressed appropriately. Explaining what the value behind each event is and why the PO’s presence is required to make them fruitful is a great starting point. Going beyond that, you can iteratively work on making the collaboration more and more efficient.
Defining your roles and expectations
Making sure you make a true team with the PO is only the first step towards fostering an efficient collaboration. Another part of this would also be clarifying the rules by discussing the roles we all play, and our responsibilities and expectations towards one another. While the basics of each can be self-explanatory even based on the role names – the details of how we split our responsibilities and areas of ownership, no so much.
In cases like this, it’s better to state the obvious than to risk misunderstandings, which would only be discovered later on, most probably in a crisis moment. Ideally, you should aim to write the results of the discussion down, like a contract, and make it transparent and visible so that people can always make a reference to it. In most cases, it would be digital, but if your team shares one space, finding a place to make it visible in your office would be awesome!
The obvious benefit here is clarity, but having those roles written down should also be helpful when giving somebody feedback – especially if you need to point out that they are not delivering on some of their responsibilities. If you can back your argument with a contract you have created, it is way more legitimate and less subjective. Think about a situation where you don’t like it that somebody smokes – you can try to tell them about it or you could show them that there is actually a sign that forbids smoking.
If trying to regulate relations between people in the team sounds rough or formal, remember that it’s widely accepted to do something similar when introducing Definitions of Done, or Service Level Agreements. We work in complex environments, and introducing more order into those environments is something we should all strive to do. Additionally, regulating the relations does not only serve to make sure people do their part, but it also protects them from being challenged with unrealistic expectations. However, the danger of this being treated like an imposed, formal document is exactly why the basis for creating it should be a team-wide discussion. This will make sure that the regulations are a consensus that has been reached by the same people that will be working according to them.
Reaching this kind of agreement should open up the field to more transparent exchange of feedback within the team. If we have done a good job making people aware they are on the same team and we defined roles clearly, we have laid the groundwork for creating an environment where giving feedback is seen as something aimed to drive us towards our goal and work more efficiently. At the same time, it usually pays off to offer to help. Even if it’s not evident what you can do for them, even asking open-ended questions like “is there anything I can do to help you address this?” gives them room to accept your assistance, but also shows that you are acting in good will.
Time – a finite resource
I’ve also mentioned being available for the team as one of the requirements towards the product owner. The biggest difficulty here can quite obviously be time constraints. This is even more so if that person is higher up the ranks (let alone a C-level executive) and has a lot on their plate, even before becoming the decision maker for your project. Having in mind that a PO will have to provide you with information regarding tasks and priorities on time as well as clarify and respond to queries from the team as they arise, it’s extremely easy for the PO to become an information and decision bottleneck for the team.
So, your PO will most likely have their agenda full, and it’s part of their job to have all those meetings, which makes it unlikely that you could change that. What you can do, though, is to make sure that you have a fixed spot in their calendar and you don’t end up forgotten when other meetings get scheduled. It’s natural for project events: standups, sprint planning, retrospectives. But if you find it’s a day-to-day reality that you are having problems with the PO not having time, plan for more than that. Slots for catch-ups – which functioned like appointment slots – were a turning point for a project of mine where the developers had previously thought they would waste the PO’s time by asking for a call, so they ended up playing ping-pong with emails or Slack. Similarly, I’ve scheduled a weekly one-on-one call with the PO. We did not always have something to discuss, but we could always cancel it last minute if we did not see the value.
It’s also good to eliminate unnecessary communication by making sure you have the Definition of Ready implemented and followed. A Definition of Ready won’t be any help if it’s only a meaningless piece of paper. If the Definition isn’t applied, it might a high time that you reviewed it, as it may simply not align with the project needs anymore.
I’m not sure if saving time is the first thing you think of when you talk about readiness, but for me, this is pretty much what it boils down to. Without it, you can end up with several rounds of clarifications (distributed over time) and potentially risking extended time for response with each one of them.
At the same time, let’s remember that all this helps us make the PO’s time involvement more efficient, but their role will still require a considerable time investment. In line with what we said before regarding open feedback and roles, make them aware if you believe the team is not reaching their full potential due to their unavailability.
The one time I had to ask a PO to be more available – I decided I would be very graphic about how it affects the team. I asked my team to track how much time they spend during the week being unable to work on the tasks which we deemed to be a priority, because they did not get all the necessary info. It was not obvious at a glance how much we were being blocked, because it was distributed over numerous short periods of time throughout the week. Besides that, the guys always found something project-related to work on, such as increasing the test coverage, refactoring the code or doing research. It was a shocker for everybody that this easily topped 20 hours per person on average, which was over 50% of their time!
Empowering your team to be the decision makers
To minimise the likelihood that your PO becomes a bottleneck, you can also delegate part of your decision making to other team members, for example developers. For some industries with a lower level of entry knowledge of best practices may be enough to call some of the shots. While those decisions should be transparent to the PO, the PO doesn’t need to be involved in the decision process for every minuscule detail.
In one of the projects I managed, we needed to dial it up to 11 on this one. Our PO had a very high-level vision of the product he was building, talking to the users and showcasing it at the events. That said, he did not feel comfortable discussing how features should work in more detail than an epic-level user story.
What we did was to shift towards a setup where, after gathering as much information as possible from him, it was the developers who proposed how to implement the desired functionality into the application, and presented it back to the PO. Seen in a vacuum, this solution was far from ideal. In the long run, I worked with the Product Owner to enable them to take those decisions and be able to shape the application, but in the short term, we needed to delegate those responsibilities.
Know what the endgame is
The kind of empowerment I’ve mentioned above requires your team to have an understanding of the product they are working on. I’ve touched upon discussing what’s our common goal in the project – this is a good starting point, but, obviously, there is more to be done. Ideally, you want everyone to know what the target audience is, what the competition is like, what the unique selling points are, and how all that translates into the development plan – both for the next sprint as well as for the entire roadmap.
Can you take decisions without that kind of information? You can, but those would not be informed decisions – they would be based on your individual assumption of what the product would be, or based purely on benchmarks of similar applications.
One of my clients has recently said that “engineers that have no context will only ever be able to go from task to task. Engineers that have context will be able to deliver fully fleshed out projects.” In this case, we have inadvertently and slowly ended up only having discussions about the business value at a Jira ticket level – no broader perspective was provided to the developers. We both admitted that it was our failure – providing them with in-depth explanation, while at the same time not noticing that they are lost in what this means for the product.
I really appreciate this simple unceremonious wording. It’s really a quick win to start discussing all this in your projects. Sprint planning is the most obvious opportunity, but you can hold a separate meeting for that, or even plan workshops where all this can be reviewed. Whichever you decide on, try to make sure that this is a habit rather than a one-off event.
Being in a good spot means that your developers will have an in-depth understanding of the value behind their work. But ideally, you want to end up in a place where they can challenge the PO’s decisions constructively to make sure how the priorities they have chosen align with the bigger picture, and potentially point out opportunities you might be missing, or pitfalls you might fall into. All this can help you make sure that being accountable for delivering value is not limited to one person – it’s a shared responsibility of the entire team. Ultimately, the decision will always remain with the product owner, but having other people able to assist them should be beneficial, as long as this is done in good faith and perceived as such.
Identify the decision makers
Discussing availability, I mentioned the risk of working with a C-level PO who may not have enough time to coordinate your work properly. Ironically, if you collaborate with someone at a lower-rank position, you run another risk – that of them not being the real shot callers. What this means for you is that you might be working based on what your PO tells you for an extended period only to have somebody who is an actual decision maker pop by to check on the progress and impose their opinion, changing the direction in which your project is headed.
Agile principles tell us to welcome change. It is a must if you want to deliver a product that actually responds to market needs and is competitive. This is something we should accept, and make sure we address those shifting circumstances in the most productive way possible. This always means that a part of your team’s work will either have to be adjusted, or may even be rendered irrelevant – you’d rather have this happen sooner rather than later.
How can this be done in practice? The Scrum Guide tells us that the Sprint Review is a meeting open to all stakeholders, and this is something you should leverage. Even if you don’t work in sprints, it should not stop you from running a demo for the people interested in the status of the application you are working on. This gives space to inspect the increments of your work and give feedback about the product at regular intervals. Be open about your intentions with the Product Owner – doing so promotes transparency and helps them make sure that they are on the right track. If you believe there is a risk that their decision will be overridden by someone else, this is surely something you want to address with them and bear in mind.
Having those people present during your review means they will actually be shown a product. Otherwise their, understanding of the product might well be limited to burndown charts, timelines, and invoices. Give them those insights as early as possible. If their opinion matters, you should be interested in making sure that they have the opportunity to express it early and in a way that will help you create the best possible product.
Keep looking for improvements - and do it in good faith
The advice I’ve presented here is very high-level, as I wanted it to be applicable to as many cases as possible. It may not cover all the problems you could be facing – and it was not my intention. It’s very likely that, once you address your major problems, you’ll be able to identify the minor ones, moving towards the optimal team setup, but never quite getting there. As long as you see the collaboration between your Product Owners and the rest of the team improving, you’re surely doing a good job as a Project Manager!
Some Tips and Tricks:
- Observe how the rest of the team communicates with the Product Owner. If they have to think twice before reaching out to him – or they hesitate to do it themselves and reach out to you, the Project Manager as an intermediary – you need to work on improving the relations within the team.
- During the stand-up, treat the Product Owner as an active member of the team; ask them what they have done to progress towards the sprint’s goal and what obstacles they are facing.
- Your Product Owner most probably has some sort of KPIs or other metrics defined for the product. Encourage them to make them transparent to the team. Discuss how all of you can impact those – knowing this is great for motivation.
- Try to map the stakeholders your Product Owner reports to or to whom they reach out for input, know what their role is in the development of the product and when involving them closer could pay off.
