A “Day in the Life” of a Product Owner

The team-level Product Owner arguably has the most difficult job on the product team. Since we are all friends here, let’s just assume she does. She is the connector of the business to tech, design to QA, and everything in between. She also deals with the day-in and day-out chase to prepare high-quality epics and stories for the next sprint. That, she cannot do alone so more coordination and discovery is required.

Last but certainly not least, she is the lens into user needs, struggles, and goals for the product team. She’s the advocate for the product and all things that affect its customer community. She doesn’t do that all by herself as she is supported by others in product management, executives, and technical support, but to the product team it all comes back to our fearless PO.
So what does a day look like for a team-level Product Owner? Here’s one that seemed pretty typical to me.

——————

06:00 a.m

Alarm goes off. You are exhausted. You decide to set your alarm back to 06:45 a.m. and take your 7 a.m. meeting from home. You can get cleaned up after the meeting and go into the office then.

07:00 a.m

Start work – You immediately jump on a story authoring call with a product team in India. You struggle through your sleepiness to bring energy to the call. You get through a handful of stories and leave the rest for offline review. The team was a bit distracted, as were you, due to the time of day. You like that team, though, as they ask good questions and seem genuinely curious about customer needs. You wish you had more time to give them.

08:00 a.m.

You begin triaging the day’s emails and meetings. Are there any meetings you can skip or defer? No…crud. You still have a bunch of stories to write for the next sprint, and that has to get done ASAP so they can be reviewed and blessed before planning. You dig into a few emails that came in from the teams overnight. Support has a couple product questions that you respond to quickly.

You look up at the clock and realize it is now 0845. You’ve missed the window to get cleaned up and go to the office, so you decide to work from home today. Your company is pretty down with the remote thing. You have a lot to get done today, so this’ll save time.

09:00 a.m.

You log into the daily stand up for product team #1 and listen to the tech lead drone on and on about a bug they are trying to fix. You resist the urge to tell them to take it offline. You zone out for a few minutes thinking about the stories you have to write this afternoon. Your attention comes back to the meeting. They are still talking about it. You check LinkedIn on your phone. You realize it is 09:15, excuse yourself, and go to your next standup.

09:15 a.m.

You log into the standup for product team #2. This one is going better. The team is quickly going through where they are at on each of the stories in the sprint. You field a few product questions and table one as you need to get more info from some stakeholders. You quickly make a note of it, so you won’t forget later. The team is on track and seems stoked for the week.

10:00 a.m.

You are at the product management department’s weekly staff meeting. The PM directors are all pontificating about strategy trying to suck up to the big boss. You ponder whether you want to jump in today and look strategic or tune it out and start working on those stories. While you are deep in thought, the Scrum Master from product team #1 pings you about the bug conversation. She wants to know what you think they should do. “Dang, maybe I should have paid better attention during standup.” You ask for three options from the tech lead and architect, fully knowing that you’ll most likely choose the cheapest one.

You focus back on the meeting for a moment and realize the head of user experience (UX) is going on about the new standards library. He is always talking about standards libraries. You zone back out and respond to a few emails. You get busted not paying attention because you are on camera, and they see you making faces at your email. Oops, you own it. Three of your peers Slack you on the side, giving you a good-natured hard time about being busted. They all were doing the same thing, of course.

It’s your turn to give a quick status. Do you mention the bug thing? Umm, no. You say the India team and product team 2 are on track. Product team 1 is working through some support issues – yeah, that’s it.

11:00 a.m.

Now, you are in the Sprint Planning prep meeting. You never learned about sprint planning prep meetings at the agile class the company made you go to, but here you are in one every other week. During this meeting the head of engineering starts going through your stories and those of your three PO peers. Once reviewed, they assign them out to developers for the next sprint. This is arguably not a good, agile practice, but you are pretty much over it as long as the team gets the stuff done.

The head of engineering notices that about 8 of your stories aren’t done yet. You say you know and that you are meeting with the tech lead and architect to author those this afternoon. He gives you a little grief, and you remind him that it is still a full week until the sprint starts. You question some of your life choices and look forward to getting out of these useless morning meetings into doing real PO work this afternoon.

12:00 p.m.

Lunch break? – haha, nope! You nuke some leftovers and eat in front of your computer. You zone out mindlessly surfing Facebook for a few minutes, and then the virtual parade starts. The Scrum Master from team 1 pings you on Slack. “Where have you been? Why haven’t you responded to my question yet about the bug?” You select a direction on the bug thing and pray that this situation is settled.

The tech lead from team 2 pings you. “Hey, look at these designs UX did. We can’t build that with the existing framework and component library. Aren’t they the ones defining the standards? They should know that.” Sigh…ugh.

Finally, your buddy from the sales group calls to chat about the weekend. You like this person, but he has a lot less to do than you do. You troll for some gossip and find out there is a big pitch going on for your product later in the week. You maneuver to get invited to that and wonder why the product manager never includes you in sales and customer conversations.

1:00 p.m.

Ah, it is finally time to get to those stories. You join the tech lead on the Zoom call and small talk a bit while waiting for the architect to join. She’s always late. The architect never shows up and doesn’t respond to Slack messages. You and the tech lead ponder rescheduling, but you both remember how impatient the head of engineering is. You decide to go forward without the architect.

You and the tech lead have an awesome conversation. You do some whiteboarding and do some story mapping of what the system steps are for this capability. This is easy online with the virtual whiteboarding tools the company uses. You realize it isn’t 8 stories but instead about 12, but you both feel better about the team’s ability to execute on them. The two of you sketch them out in Jira, and you promise to put the finishing touches on them later this afternoon.

Learn how to virtually white board and facilitate an architecture discussion online

2:30 p.m.

You log out of the meeting and finally have some “desk time.” The head of engineering has sent you a Slack. “How are those stories coming?” Fine, you say while noting that the architect didn’t show up … again.

You spend some time adding acceptance criteria and cleaning up your horrible spelling in the stories. You add some casual language and “haha’s”, hoping that’ll cause the developers and QA to actually read the stories. Now, you have 12 stories ready and plenty to keep your teams occupied for the next sprint. You breathe a quick sigh of relief and then send the links out to key team members for review.

3:00 p.m.

The architect pings you on Slack asking why she wasn’t involved in the story authoring and telling you that the stories are all wrong. As you fight the urge to tell her where she can stick the stories, you mention that she was invited and didn’t come to the meeting at 1 o’clock. She claims it wasn’t on her calendar. You see it on her calendar.

You coordinate a quick Zoom session with her and the tech lead and walk through everything that was discussed during the earlier meeting again. After she listens, she understands your direction but also adds some things you and the tech lead hadn’t thought of. You need three more stories. Ugh…the product manager is going to kill you when he finds out this is going to take 3 sprints now instead of 1.

4:30 p.m.

You finish with the architect and tech lead, do some cleanup on the stories, and then resubmit them for review. You look at the clock and go “dang, I can’t believe it is so late.”
You look at your calendar and realize you just missed your 4 o’clock 1-on-1 with your boss. He was probably relieved, though, as he thinks you are kind of negative and too mired in the tactical details. He didn’t ping so you decide to just play it off.

5:00 p.m.

You look at emails. You have 52 unread messages. You return a few quick ones, and then decide to call the product manager to catch him up on the day’s events. You two jam for a bit, and you explain that the feature is going to take longer than expected. He asks if the architect and tech lead are padding, and you say you don’t think so. Actually, you fear it is going to take longer than they are saying.

You ask the product manager why he didn’t include you in the big sales call later in the week. He says he forgot. You remind him of the need for you to understand the market and customer, and he says, “yeah, yeah, yeah.” Since he kind of feels guilty, you take this opportunity to ask if you can attend the company’s big user conference this summer. He says he’ll think about it.

5:30 p.m.

You’ve read the same email 3 times. It is a huge wall of text from one of the developers on product team 1. You just can’t even right now. Why can’t they write shorter emails with clear questions in them? You decide to shut down for the day.

6:00 p.m.

You start Slacking your fellow PO from your phone. The two of you are going off about different PO things and the head of engineering. Finally, you ask if he wants to have a beer with you. You two meet up and share your days with each other. He’s jealous that you get to work with product team 2. You remind him that you also have product team 1. You both lament about the uselessness of the Product Management meeting. You have three beers and talk each other off the ledge. You get him to agree to help the head of UX with the standards library. When he sobers up, he’ll likely rethink that.

——————

Okay, we’ve made light of some of the events that happen to POs, but I can tell you this is more normal than satire. If this sounds like your world, how do you get the most from days like this?
When I was a product owner, I felt a constant pull between the tactical chase of preparing stories for the next sprint, time-wasting activities like meetings and email, and then trying to be a true “product owner,” doing discovery and product management activities. Time management and balance is critical but so difficult when you are in the day-to-day grind.

If I had the chance to go back and do it all over again, here’s some things I would do differently.

1. Beat the chase

I define a ‘Chase’ as a situation when you are fighting just to prepare enough stories for the start of the next sprint. The chase gets exhausting sprint after sprint if you can’t get ahead a little bit (say a sprint or two). You feel that steady pressure and can’t even think of going on vacation.

The product owner above is right on the cusp of beating the chase, though. Because the feature she worked on with the architect and tech lead ended up being so large, she now has more stories than she needs for the next sprint. This could be the springboard to get ahead. Keep the gas down in the next sprint, and fearless PO – you have beaten the chase! Another thing I would do is always have a few, valuable yet small, stories ready in the backlog. These can be rolled in when the team is lacking other work or when product discovery is lagging product delivery.

Lastly, don’t be afraid to pull in others to help you. Product discovery (or simply put, creating a backlog) is the job of the whole team and not just the Product Owner.

2. Convert emails to standup questions (or Slacks)

Emails are the curse of every PO, especially long emails. When I was a developer, I never understood why product owners wouldn’t respond to my emails. When I became a PO, it became clear. I wrote long, detailed, technical emails. They were huge walls of text. No one wants to read that. Then in the end, I wouldn’t summarize and wouldn’t usually make my question or ask clear. Responses didn’t come or when they did it was usually just more questions.

As a PO, I always coached product team members to do the following:

1. Ask the question first
2. Make the question yes/no or a choice of options that you propose
3. Try to limit it to one question per email. It’s cool to send multiple short emails

These days, as a PO encourage your teams to bring their questions to standup. That’s a great time to surface them and then you can plan to stay after for offline convos. These questions can all be knocked out at once then; the whole team can hear if relevant, and verbal communication is always better than email.

If your team doesn’t have a standup or it can’t wait, encourage team members to shoot you a Slack. That paradigm forces people into more concise messages and is easier to have a conversation in. Do these things, and you’ll have less email in your inbox which means more time for higher-value activities

3. Influence by walking around

There is nothing more important in your role than talking to people. You should be finding a way to talk to everyone. The relationships you forge during your time as a PO and the skills that you learn with respect to influencing without authority will serve you for your entire career. When I worked as a PO, I would make a conscious effort every week to talk to people. We were in an office environment, so I could usually do this in person. They were my fellow Pos; they were people in engineering, and they were people in other departments that supported us like sales, marketing, renewals, finance, and tech support.

From these conversations I built relationships, but I also learned about their world and their perspective. All of these things ultimately affect our product and customer experience. They knew what was going on and often things I didn’t know. Also, when it came time that you needed something, they were always willing to help.

If you work in a virtual office, this is harder, but you can still do it. Make a note to call some people on Friday afternoon or in the morning/evening when you know they are starting or winding down their day. Be respectful of their time and understand if they don’t have time to chat. More times than not, they’ll appreciate that you connected with them.

4. Think strategically while acting tactically

This one is a biggie for everyone in product roles. Whether you are a team-level product owner, a product manager, or even a chief product officer, you wish you had more time to work on strategic stuff versus tactical stuff. As a team-level product owner, I often had a chip on my shoulder thinking the product manager didn’t want me to contribute or that my role was cast as the lesser product person in the pair who doesn’t have the skills to work on strategic stuff.

Looking back, I judged that unfairly. If I had it to do over, I would focus more on thinking strategically while acting tactically. If you can do both of those things, you are a powerful force on a product team (or anywhere). Here’s some things you can try.

• Engage in the strategic discussions in the PM meeting. You don’t have to be a butt kisser like the directors, hahaha, but don’t pull back from that conversation. If nothing else, ask questions. This is also a great time to offer some leg work to prove out an assumption with market/user data.
• Ask the PM how you can help. He doesn’t have enough time for this stuff either. A good PM will gladly accept your help, but think of specific things you can do. Don’t fall into the trap of saying, “Why don’t you include me more?”
• Get close to the UX people. They often have a lot of customer contact too. If you can work with and help them, you’ll be in front of the user more. Also, if you can get the chance to observe usability testing, DO IT!! Offer to take notes and assure them that you will keep your mouth shut.
• Provide your PM with data any time you can. Challenge the team and the PM to instrument the product with analytics that will allow you to make data-driven, product decisions later.
• Engage the PM and the team in product discovery sessions that take an idea and bring it all the way down to stories versus letting the PM hand off an epic or worse a vague roadmap idea to you. Make discovery a thing that blends strategy and tactics. You’ll then be at the center of it, and you’ll end up with a lot better product understanding across the team.
• You are likely thinking that you don’t have time for #3 and #4, and you may be right. I’m hopeful that by doing #1 and #2 that will buy you some breathing room to invest more in #3 and #4.

Here’s some questions to ask yourself every day to stay on track.

• How much time did I spend on meetings and email today?
• What is blocking my product team right now? Is it me? Can I help?
• Am I ready for the next iteration?
• Have I talked to a customer today? Have I talked to a customer this week?
• Have I talked to the product manager today? Have I offered input or help on strategic work?
• Have I talked to sales / support this week? Have I learned about customer or market problems?

Fight on fearless Product Owners. You are vital, and you are loved (even if the head of engineering doesn’t always say it).