A fictional - but realistic "day in the life of a Product Owner" is provided below. Last night I couldn’t sleep. I was thinking about how to get a key stakeholder on board with my proposed approach for the product. This morning I met with them. The meeting went well. They smiled, nodded, and said they agreed with the plan. By the afternoon, I found out they were already taking actions behind the scenes to undermine it. Welcome to being a Product Owner. The Real Work After th

The Product Owner exists for one reason: to maximize value. That means creating and maintaining a clear vision, setting strategy, making tough prioritization decisions, and ensuring the team is always working on the most important things. This is real strategic work. It’s hard to do it well when the role is treated as a part-time side job. You have an entire team of developers working full-time to build the product. Doesn’t it make sense to have someone fully focused on decid

Sprint after Sprint, a lot of work remained unfinished at the end of the Sprint. Instead of returning that work to the Product Backlog or discussing next steps at the following Sprint Planning event, the vendor simply left the previous Sprint open. At any given time there might be four or five Sprints open for the same Scrum team. Don’t do this!

If you’re bringing in an external vendor to do Agile software development, you need to set things up so that you’re not stuck with poor performance and big bills. Here are a few practical tips I’ve learned the hard way.

I used to roll my eyes when highly-paid consultants would stand in front of leadership and say things like “Agile is a mindset” or “We need an Agile mindset shift.” But damn it… they were right. There really is an Agile mindset. And if you’re using Scrum without it, you’re most likely just going through the motions. And you could be leaving a lot of value on the table - not to mention creating a lot of waste. So, what do I actually mean by “Agile mindset”? Let’s get specific

Catch Me If You Can (2002), DreamWorks Pictures, directed by Steven Spielberg When you are using AI to refine something, run it by an AI. And then ask another AI what it thinks of the deliverable. For example, if you are ordering your Product Backlog, or brainstorming on how to communicate your Product Vision, or planning the right meeting agenda, work with AI. Get some ideas. And then, when you have a good approach, run it by another AI for feedback. If you're working wit

Let’s walk through the types of questions showing up in Product Owner interviews today—and what they’re really testing.

Red flags I look for (and why I walk away) After more than 20 years coaching Scrum teams, I’ve learned the interview isn’t just about them judging me: I’m judging them right back. I’m looking for clues about whether this is a place where I can actually help teams improve, or if it's just not a good fit for me. Not every Scrum Master job is worth taking. Here are my Red Flags Culture, culture, culture If they casually mention burnout, blame, or constant fire-fighting but show

Here are some of the tougher questions that might actually come up. We've grouped them by category and shown what strong (and weak) answers look like.

Too many teams are still organized around silos. Business over here. Tech over there. Maybe design somewhere in the middle trying to translate. And when people can’t talk to each other just because they have different skill sets, you don’t really have a team: you have specialists in a vacuum.

Rebel Scrum is excited to announce Siva Balu as the afternoon keynote speaker for Scrum Day Madison 2026 , happening October 15, 2026, at the Madison Marriott West . This year’s theme, “Agility in the Age of AI,” comes to life through Siva’s keynote, “ From AI Hype to AI for Your Business .” Drawing from real-world experience at a Fortune 3 organization and beyond, Siva will share how leaders can cut through the noise, apply AI responsibly, and deliver meaningful business

Teams run into this situation all the time. Someone notices a small problem. A developer says, “Oh, that’s an easy fix. I can knock that out quickly.” And then the question comes up: “Should we just fix it now?” The answer is a solid “it depends.” Scrum doesn’t give you a rule that says yes or no. Instead, it gives you something better: the ability to use your judgment as a team. Start With the Product Owner Before anyone jumps in and starts fixing something, the first questi

In a single building, we can create a mask, make the chip, test the chip, make another mask, and have a fast recursive loop for improving the chip design.

The Product Backlog is so much more than a simple priority list. It is a plan for how the Product Owner and the Scrum team will deliver the Product Goal and maximize value. But the Product Owner can't come up with this list - or even order it - entirely in a vacuum. Stakeholder feedback as well as input from the Developers is invaluable to ensuring that the Product Backlog is a good plan. Having a good conversation about the ordering of the Product Backlog comes down to g

For years we have heard the phrase “content is king.” Today, I think it's fair to say that context is king.

Scrum uses what I like to call a “just in time” approach to meetings.

Do they prefer Kanban? Let them use Kanban. Do they prefer Scrum? Let them eat cake (I mean, let them use Scrum.) Scrum with Kanban? Well, that's the best of both worlds—let them do it.

A dependency exists when a Scrum Team needs work from another team before they can complete their own work. For example, a development team may be waiting on the SQL team to make a database change. Or Human Resources may need software changes before updating the onboarding process. In short, dependencies are those times when one team is waiting on another. Dependencies are the number one problem when you start to scale Agile beyond just one team. So what can we do about it?

Scrum is not an end unto itself. It's a great tool for helping a team focus on value, but the goal isn’t to “do Scrum.” The goal is to maximize value for the customer.

Scrum training isn’t (just) about certification or even "learning the rules". It’s about alignment. When teams train together, they don’t just learn Scrum—they learn how to work together. And that shared understanding is often the difference between a group that simply does the work and a team that truly performs.