Supercharge Your Product Owner

A lot has been written about what makes a good Product Owner (PO), what attributes and characteristics they should have in order to make a project a success. There are many different opinions — it should be a full time role, what behaviours they need to elicit from their team, where they should spend their time.

The reality is that many Product Owners have never done the role before, or simple didn’t want it in the first place. They are given the reigns to a project simply because they were in the room at the time, or they happen to be a subject matter expert.

I still believe that a strong predictor for the success of a project is how invested and engaged the PO is on a project. After all, they set the tone and give direction to the team!

But even if they did want they PO role and they are the right person, many POs are in demand and are too time poor to commit fully to one team.

How can you, as a product development team, support your PO?

Development Teams

While you can’t force someone to be engaged or motivated, a development team (especially an experienced one) can do a lot to support the PO role — making life much easier for someone who is either new to the role, or someone who is not particularly comfortable in the role.

These are the things that came to my mind first, but I’d love to hear other ideas on how you and your team have helped someone in the PO role develop and even thrive, when at first they may have struggled.

You spell Team with a PO

The first thing to remember is that you’re all one team — it’s not the team and the PO. Regardless of how engaged the PO is, treating them as somehow separate to the team will not improve the situation.

Have some empathy for everyone on your team, but especially a PO who may not be all that excited about the role or product. There might be very good reasons for them to be distracted or uncomfortable in the role. The secret is to ask.

Open up the communication with your PO and explain to them why their behaviour is impacting the team, but then let them give their side of the story. You might find you have more in common than you realised.

Provide structure

This one can be difficult for less experienced teams, but for more mature teams providing structure for the PO to work within is essential — the PO does not need to be battling the business and the team.

Software development requires discipline and direction. The PO is primarily responsible for the latter while the development team is responsible for the former. It’s not the POs role to be telling the developers or designers how to build software (if they are, that’s another conversation you need to have). It’s essential every one has clarity on their role and responsibilities. This includes the PO and this is where a mature team can really help the PO to understand their role and responsibilities on an agile team.

Make it safe to experiment

Just like a team needs psychological safety to continuously improve, so to the team needs to provide a space within which the PO can feel safe to experiment. This means giving realistic feedback on effort and risk. It may also mean challenging business decisions as well as getting creative with technical solutions to business problems to work within business constraints. No project is perfect, but collaboration is essential if you using an agile mindset to product development.

Similarly, provide a space within which the PO can feel safe to voice their fears about the project. If the PO feels like the project may be a death march, then you need to know that as a development team. You can also help support the PO here, even if it’s to support them in asking the business to cancel / pivot the project.

Visibility

It is essential — for all teams and agile processes — to track the project in whatever way is necessary to enable full visibility on the outcome. Velocity is a very common (although generally misunderstood) metric for forecasting, but you need cycle times, CFDs and other metrics to ensure you and your PO have complete visibility on the state of the project.

A cornerstone of agile product development is knowing where you are, so that you can plan a small step forward, asses the outcome and then rinse and repeat. You can’t course correct or improve your project or process if you don’t know where you are right now.

Visibility will also provide some surety for the team in the short term and makes clear to the PO the impact of changes to the team and backlog. Visibility also provides concrete data points for the PO to take to key stakeholders to support changes to project direction.

Short-term roadmaps with two or three lower fidelity horizons are a great substuitute for 12 month road maps. Planning is essential to agile delivery, but plans are mostly useless — planning helps to make changes to scope and project direction visible to all. Planning is a continuous activity and change is not bad (we should embrace it, it is inevitable after all), but the impact to the team, to delivery, to the users must be made visible.

Be aware of The System

Every system is perfectly designed to deliver the outcome it produces— so be aware of the system you are in, who are the influencers, who are the real decision makers and key stakeholders. Collaborate with the PO to develop an approach to dealing with stakeholders and those outside the team attempting to exert influence through indirect channels.

Development teams can also help support less technical POs by building relationships with key technical stakeholders or dependencies in the wider organisation.

Technical dependencies can be obvious to technical people, but not to POs. Don’t assume anything, but be prepared to help the PO understand the implications of a shared development environment or lack of automated testing.

Change happens

When change happens — as it will! — switch into problem solving mode. As stated above, the PO can provide direction, but it’s up to the team to get innovative and look for novel ways to solve the problem and provide that back to the PO. This will help enormously in their ability to plan (and re-plan). Look for comprises and explore the space.

For example, a feature X suddenly becomes critical — but what is it specifically about that feature that is so important? Can some cut-down version meet the need initially? Can it wait two weeks until a later release? Is there another way the decision maker hasn’t considered (this is likely). Give the PO options.

The PO is trying to make this work, whether engaged or not — they may or may not be in a difficult situation — but if you let them know it’s hard and listen to them, then they will be far more likely to listen to you.

Helping your PO help you

There are many other ways a development team can help their PO, the above are just a few ways I’ve seen that worked, in their own contexts.

Above all else you need to make sure that you’re supporting your PO as best you can — if the above aren’t working then have a conversation about how you can help them. Be it training, talking about challenges, impediments or outside influences.

It’s amazing the difference it can make when a PO is supported and the whole team (PO included) is invested in not just the outcome, but in making the journey a smooth and fun ride!