First Challenges as a New Product Owner

Imagine it’s your first day at a new school and you are asked to join the basketball team as their captain and coach. Everyone is playing along nicely when you show up, the new kid. You have been playing basketball for some time but you never had any decision making position before. And now here you are, trying to figure out how to help the team score more hoops and keep the fans happy.

This is more or less how my first weeks as product owner felt like. I have been in software development for 10 years now, but never in the PO role. Our product is relatively new but being developed by an established team, in other words it is already in good hands. So, to be useful both for my team and product I realised that I needed to come to terms with some challenges.

Not knowing the team’s dynamics

When starting in a new team, the problem is not learning about the Agile ceremonies or their backlog tool. The team already had a good working rhythm, producing good quality software every 2 weeks. The challenge is figuring out what are the balances within the team that make good work possible. When they need what you know as a PO to go forward and when you should step back and let them do their thing. Participating early on in all the team meetings seems like a good starting point. Just listening and paying attention to what people say and the way they react can provide a baseline of how things are under normal circumstances.

Lacking the lessons learned by the team

Even with the best documentation in place, sometimes it is hard to understand why it was decided to take a certain course of action. Deriving why there is resistance to some ideas is even more complicated. Is it because it is something new and scary or is it because it was already tried out and failed? Finding out why the product and the processes have shaped in a certain way is essential in planning their future direction.

Getting up-to-date while development continues

The world doesn’t stop spinning just because you arrive. Having to catch up on the work that has been done so far while things keep on going forward feels like a juggling exercise. How much time to spend on understanding what the product can already do versus on shaping up the functionality under development? I’ve decided to go for a 80% to 20% approach. Unless there is something really controversial in a new feature, I sit back and trust the team’s decision; that way I invest my time in catching up, aiming to become productive sooner.

Taking product decisions

As a tester I am used to provide information about the state of the product to help the business decide on how to proceed. I was also lucky enough to work with teams that accepted most of my recommendations. Nevertheless, I was never the one making the decisions on the priority of features to be developed or coming up with the expected impact of these features. As a product owner I am supposed to make these calls. And even though I can’t see this initially happening without being heavily reliant on the guidance of the team, the prospect of working with them increases my confidence that everything will be OK in the long run.

I guess the answer to my challenges is time. Time to get to know the people, their story and the product. And who knows maybe even with time I won’t have to be the sole decision maker but we shift to a no dedicated PO paradigm.  Only time will tell.