A Day in the Life of a Product Owner

So you want to be a Product Owner? Here’s what your work life will look like on a Monday.

Published

You hear the alarm clock on your iPhone ringing. 7:00 AM. Yawn. Open your eyes. It’s time to wake up and get out of bed.

Trying not to get tempted by the notifications on your phone’s gigantic screen, you get up, brush your teeth, wash your face, and take a shower.

Now that you’re decent and finally feel like a human being again, you turn on the coffee maker, pour yourself a cup of joe, sit quietly at your kitchen table, pick up your phone and open the Mail app.

Happy Monday!

The most experienced developer on your Scrum Team phoned in sick, and your Sprint ends Wednesday.

Your team, already at reduced capacity with two Europe-based developers OOO on a national holiday, needs you to make a trade-off or two on the Product Backlog to be able to meet the Sprint Goal.

You have a choice: deliver the business-critical feature you have already postponed by one Sprint because of that third-party dependency you and your Scrum Master could not solve in time, or fix a serious bug reported by a customer whose trust in your product is already a little shaken.

Decisions, decisions… You let that marinade as you finish your cereal for breakfast, get dressed for work, and go to the garage.

On the way to work, your boss—who gets up at 4:00 AM every morning and gets to the office early, right after she completes her morning run—sends you a DM, asking if she can “check something really quickly with you when you get to the office; won’t take more than a minute or two.”

Knowing she has to give a presentation to the board at noon, you wonder what kind of questions she will ask and how many custom SQL queries one of the few developers on your team will have to write to answer them.

Still, your boss is your boss, and the board is the board. One way or another, you’ll have to squeeze them in.

You arrive at the office and go straight to the kitchen area to pour yourself a second cup of coffee. Your Quality Assurance Manager greets you excitedly to tell you that he has finally managed to reproduce the annoying bug that some users had been complaining about.

The news is anything but good: it’s related to that age-old code nobody on your team knows anything about. The one written by that vendor your company stopped working with years ago, in a language nobody in your team even understands.

“When it rains, it pours,” you say to yourself as you accept reality for what it is, place the cup of coffee on your desk, and take a deep breath before heading to your manager’s office.

The new board members are very much into dashboards, your manager tells you, and, over the weekend, they’ve asked her if she could come up with a prototype for a “bird’s eye view dashboard” with metrics to report on in their meetings.

Alas, none of the developers on your team have ever worked with Tableau, and it will take them forever to learn it. You’ll have to dust off your old analyst hat and create a dashboard yourself once someone runs a few SQL queries and sends the raw data in an extract.

Back at your desk, you add a task for custom reporting, assign the highest priority to releasing this delayed feature, and deprioritize fixing the bug for the already frustrated client. Before you forget, you draft up a backlog item for that age-old code you’ll need to discuss fixing with your team.

“One Sprint at a time,” you tell yourself, “one Sprint a time.”

Setting a meeting with the VP of the frustrated client to tell them the bad news, they accept your invite and send you back the peppery response of “we are hoping to hear that you have finally prioritized to address this increasingly pressing problem.”

Remembering that breathing technique they taught at the mindfulness session during last year’s all-hands event, you breathe in, then breathe out—and repeat a few until your pulse returns to some degree of normal.

“Extract done,” a developer on your team wrote on Slack as you were just starting to read how Tableau worked.

After skimming through every single one of the tutorials on page 1 of Google and an hour or so of trial and error in Tableau, your “bird’s eye view” dashboard is finally starting to look like something that wasn’t put together in less than a day… but the numbers look weird.

As you dig deep into the contents of the .CSV file extract, you notice that one column is missing. Getting close to the lunchtime deadline for your work, you beg your developers to update their queries and re-run their script so that you can get a file with everything you need.

Eventually and at a great emotional cost, they do, and, with your manager already walking toward your desk impatiently, you hit “Publish,” and, voilà, version 1.0 of the dashboard is done.

“Hmm…” she looks at the gauges and charts. “I’ll be honest with you, it’s not quite what I had imagined, but it will definitely do. Can you help me understand why this is visualized in that way, though?”

It’s lunchtime. Biting into a salami sandwich from the café downstairs and after a quick back-and-forth with your manager, you already wish you had fallen asleep and woken up on Saturday morning. No, make that noon!

As you ride the elevator back to the office, you think to yourself that you can’t wait to get yelled at by that frustrated client. Ironically, you and your team have worked wonders for them. But despite your best intentions, there’s been one problem after another, not all of which under your control.

The meeting’s over, and you feel emotionally drained. You ping your boss, who’s just coming out of her board meeting, to expect an escalation. She replies to you, “OK.”

Yikes. Did the board not like the bird’s-eye-view dashboard? Were the numbers wrong because you got one of the metrics wrong?

Adrenaline pumps through your blood as you picture the worst that could happen and tell yourself that you could always go back to being a bartender like you did that year back in college.

“BTW,” she texts you, “the board love it. Great job! ;)”

Just as you relax your shoulders and smile, an email from the Scrum Master on your team flies in. “All the developers on the team are pretty mad at you. What happened? Let’s talk.”

Tight timelines, last-minute requests, and constant delays from third-party dependencies have taken their toll. How can you explain to your developers that as a Product Owner, you can’t just wave a magic wand and make everything better?

You talk, and the two of you make a plan for the Sprint Retrospective. As always, you take the blame. But you knew from the moment you applied that this was part of your job. Besides, you are not doing it for the recognition.

You set about formulating a Sprint Goal, drafting user stories, and thinking through acceptance criteria for the next Sprint, a.k.a. Sprint 50. “Wow, 50 Sprints already? I need to come up with a gift or two for everyone on the team.”

When you look back, remember where you and your team started. The fires you put out. The features you delivered. The processes you implemented. The moments you experienced. The growth you’ve experienced. The sheer number of times you’ve defied gravity and survived the odds.

“It’s hectic,” you think to yourself. “But it’s all worth it.”

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.