Product Ownership – Resources

I started out less than ten months ago as a Product Owner, with life made a little more interesting that I was working across 2 products and 4 (remote) teams. Over the course of the next few months, this expanded somehow to 3 products and 9 (remote) teams! I’m very very pleased to report that when I return to work next month, I will be down to one single (significant) product and four teams – ok, still remote 😦

The upshot of these challenges was that I had a lot to learn in my new role, and I would like to acknowledge the resources I used along my growth journey to help me. These helped my clarify my role, focus on the key things I needed to do, and most importantly, develop the right mindset to be a good Product Owner. These key people have been my ‘virtual mentors‘ and I’m super-grateful to them for the wonderful work they do sharing their knowledge and insights to everyone.

Roman Pichler:

A great overview, as well as lots of in-depth articles on Product Ownership

An equally informative view of Product Management, the framework and how it fits in with Product Ownership with Agile in large organizations.

Intercom – Des Traynor:

Great blogs on Product Strategy, some fantastic free books to download, and every re-read yields a new gem. When I grow up, I wanna be like Des Traynor. 🙂

Medium:

One of my best finds of the year – a community of people writing about everything under the sun. Some great articles on Product Ownership, but you will need to find them under the general Product Management Category.

Product Talk – Teresa Torres

Teresa focuses on the hows and whys of building the right thing, and has inspired me to think about how to apply user-centred thinking and design when breaking down themes into Epics and Stories.

Jeff Patton

I held out for months so I could attend Jeff’s Passionate Product Owner Training, and it was worth it. Every minute was riveting, one of the best courses I have EVER been on, and I learned so, so much. I’m a finicky so and so but the ONLY thing I had to bitch about was the food (which was done by someone else). Life’s hard! 🙂

As a starting point, read this massive, super-informative post packed with ideas, techniques and tips.

Other Resources:

While the above were my “Go-to” blogs, there have been a few other websites that have been great to dip into from time to time.

The Unbreakable PO – hasn’t been updated for a while, but some good classic techniques and tips.

Crisp’s Blog – Henrik Kniberg’s blog – All things Agile, but some great PO focused posts.

Finally, a MUST-WATCH video that you can point people to when they ask what a Product Owner does – thanks to Spotify for this gem. I prefer reading over videos any day – but this one is a GEM!

Do you have any other awesome PO resources to share? I’d appreciate trying something new, I’m always learning!

Three months in as a Product Owner

It’s….. been a busy few months!

Actions:

Product One – Coordinate the backlog and sprint planning across 1 experienced team in Christchurch (where I’m based) and 2 new teams in Auckland. Make sure the experienced team (doing the bulk of the work) have enough to keep them working on a large focused customer delivery. In addition, the two new teams need well defined, small but independent stories that will help them learn the code and domain, and enable to start contributing value to the product.

Product Two – Having just taken over this team in Canberra and with no depth of experience in the domain, I have focused on getting good processes and touchpoints between the team and me established. I am leaning heavily on my Product Manager who is the Domain Guru to help, and we have got one release out, completed Release Planning for the next one, and with ongoing regular contact, the team continues to perform well remotely

Product Three – Another new team in Canberra, with a different Product Manager, significantly different domain, and significantly different style of working. Once again I am focusing on learning the team’s operating style, and getting our processes ironed out. The focus with this team, and a relatively new product, is to really understand the main use cases and try to stop going down the rabbit-hole of edge cases so we can take a viable product to market ASAP. A lot of our process refresher discussions and Release Planning has focused on this.

Wins:

All the teams are great, accepting of the changes and enthusiastic and positive about working together.

We’ve had some great SCRUM / Process discussion sessions and are on the same page about how we want to work.

Our structured Release Planning and backlog grooming sessions have been great, and teams appear to be happy with the process leading to a clear and defined scope and target date – which hasn’t always been consistent.

Challenges:

It’s hard to ask the right questions and uncover the areas that are critical v/s not when you don’t know very much about a domain area – and of course this domain is so complex, with lots of clinical risk. However this is going to be a critical skill and I need to learn how to do this – fast!

It’s difficult to work with remote teams, and much more so when the people on both sides are new. We’re still working out what each of the individuals are like, what each of us want, how we work, and it’s exponentially harder remotely because you can’t read facial expressions or body language over Skype chat. You could get left out of key conversations or miss little details because you’re not listening to the little chats going on, and they often forget to loop you in – or don’t think it’s worth asking about. A couple of times, even with discussions, people have finished up a conversation with some people thinking a different decision was reached than others.

Expectation Management!  Frankly, it’s difficult when Product Managers (who are so influential in what is done, and how the team works) work so differently. One (who has a number of products in their portfolio) is happy to provide general direction and guidance, check in regularly and give you lots of autonomy and background information to stories, and access to clients and stakeholders to understand the business value. Another (who has just one product and therefore more time) prefers to be a lot more hands on, will work with UX and Technical leads to fully develop the user story and all artefacts, and just present it to the team as “Build this” and resists sharing information about context, background, or users. You can guess which one I find more inspiring! 😉

All in all it’s been a huge learning curve, but oh boy is it busy and stressful! I’m hoping that in the next 3 months, things will settle down and standardise and it won’t feel quite like the never ending race anymore!

 

Lessons learned as a new Product Owner

I knew I wasn’t signing up for an easy gig. Moving from Business Analyst to Product Ownership meant a significant shift in my roles and responsibilities anyway. Being a Product Owner for 3 products and four remote teams right from the get go, without any real domain experience to help, was always going to be a challenge. It’s a good thing I’m too stubborn to be scared of anything like that!

This isn’t the story of a miracle or the happy ending of a movie. Things haven’t fallen into place like magic. I’m still learning, I’m still struggling, but I know I’m going in the right direction. Here are the three biggest things I’ve learned, though.

Working with remote teams is HARD

I always knew this one was going to be problematic. It’s difficult not being a part of impromptu conversations and questions, and communicating by Skype chat or video with a large team means you miss a lot of non-verbal communication. I do travel to do important stuff like Release Planning face to face, but that is once every 2 months, and it’s not really enough to build strong bonds with teams.

I’m still working out how to get better at this but one thing I have learnt is that the teams where the team leads are proactive and will always be thinking about when they need to loop me in produce much better outcomes than teams where they don’t. If you figure out how to do this better, please help me!

Standardize Processes as much as possible

Make sure everyone understands roles and responsibilities clearly, and who to involve when. This goes a long way towards helping people decide when to reach out vs when to solve the problem themselves.  And try to ensure that your processes are similar for each team and product – because the difficulties arise when you’re trying to do things differently for each – the stress of remembering to do the ‘right’ thing for that team or product is more.

Don’t be afraid to ask for Help

Change is hard, and people resist it. With no direct authority, not being co-located, and without the deep domain knowledge that the team can turn to you for, it’s difficult for them to see the value in the Product Owner role. The Product Managers and Development Managers have been fantastic in impressing on the teams that this is an essential ingredient of creating good software and they have stepped in and reinforced this. When I can’t be there, the team leads have been fantastic ‘eyes and ears’ for me and have given me so much valuable advice on how their teams work, how to achieve a particular outcome or what to watch out for. I’m lucky to have some great people helping me – and all I had to do was ask!

I know that we’re past the forming stage, and I’m wondering if/ how storming will happen – and hoping to get to norming ASAP… watch this space 🙂