A day in the life of – agile product owner

productfernJuly 25, 2020

One of the joys of working in product management, business analysis or user research is the variety! No day is the same and the mix of activities constantly changes. Welcome to the ‘day in the life’ series where we profile different roles and what they are up to in an average today. Starting off with an agile product owner.

As I talked about in the ‘what is product ownership?‘ post, usually a product owner is associated with the Scrum methodology. There are different types of product owner dependent on the product you’re managing. Today, I am focussing on a product owner who has an internal product. So one which is only used by people within the same organisation.

A calendar notebook with a day view open to symbolise the day in the life of an agile product owner

9am – reviewing the upcoming user stories

I work with two business analysts who mainly write the user stories for the product. They do a great job at turning our vision and insights into stories for the dev team. One has told me that all the stories for a specific feature are ready to go. I log into jira and read through the different stories. I cross reference the stories to some of the user research we had done on the flow through the system and make some suggestions. Usually I will just add a comment at the bottom of the story for consideration.

When I’m finished I change the status on the feature so the team knows it is ready to go to the next stage of refinement. I reflect through the backlog and move the feature higher up in our priority list. It’s important to keep our view of priority flexible based on the feedback we are getting.

10.30am – joining the stand up as an agile product owner

We have a later stand up because we are all currently remote and across some different time zones. We run round the group and the devs say what they are working on. They flag a few questions, some which I can unblock immediately and some which I add to my to-do list. I take part in the stand up and let the team know how a demo I delivered yesterday went. We are rolling the product out slowly to new areas and are getting positive feedback from some future deployments.

11am – tracking service desk tickets and feedback

One of the easiest way to understand what our current users think is to run through service desk tickets. I have a weekly meeting with our support team to see what problems have been coming up. This also helps to show if there are any areas which might be hard for users to understand.

They compile a report which goes through the most common issues. Some of them I know we have a future feature which might help solve their issue. Some of them I add to my to-do list to consider how they might fit in.

1pm – stakeholder briefings and communications

A huge part of my role is to help stakeholders understand and use my product. As my product is an internal one, this can be a bit easier as we are expected to be rolled out across the business. But that doesn’t make it any easier! I still want my product to be a positive experience for users and for us to get real business benefit from using it.

I meet with different stakeholders, first with another product owner to decide about future integrations. Whilst I rely on my technical team to figure out how it might work, we first need to decide if the business benefit is there. We run through some processes and some scenarios which may make sense. It’s decided that we need to run some user research first to see if that benefit would actually be feasible. I write a note to brief my UX team in our meeting tomorrow.

I also attend a wider team meeting to represent my product. We run around any updates we have made. I get some great inspiration from seeing what other internal products have been developed.

2.30pm – conducting sprint planning

After a quick break to grab a cup of tea, it’s back to the product team to complete sprint planning. One of the business analysts usually leads the session based on what features I’ve put in the top of the backlog. We go through each of the stories and debate over priority of what should come first from both a technical and design perspective.

Once we are all happy we have a good plan in place, we pull the stories into the sprint to start from the following week.

4pm – debrief with my business analysts

It’s been a busy day so I finally have a call with my business analysts to discuss the work they’ve been doing. We go through a variety of items from updates in processes, questions on feature stories and thoughts about UX. We agree priorities moving forward and they are happy to continue the work.

5.00pm – emails and prep for another day as a agile product owner

As we are all remote at the moment, a lot of my days can be full of meetings and calls! I always make sure to leave an hour at the end of the day to sit and go through my notes from the day. I answer some emails and fire off some emails myself for some of the actions I’ve taken from the day.

Checking my calendar for tomorrow, I make a list of the priorities I want to get covered. Now to relax before another busy day comes around!

What next?

Keep your eyes peeled for the next installment in the day in the life of series! Let me know what you want to see next.

How does this day compare to your typical day?

Share this post:

Promotional image which can be shared which says a day in the life of an agile product owner with product fern logo.

Leave a comment

Your email address will not be published. Required fields are marked *

Prev Post

What is the difference between a business analyst and a product owner?

Next Post

How to combine product management and user research