Product Ownership Beyond the Backlog

0:00Welcome to skill number one of the PSPO2, the advanced course. And this one is all about product ownership beyond the backlog. So most product owners learn how to manage a backlog. That's PSPO1. And experienced product owners learn how to maximize product value. This course is going to take you from PSPO1 over to 2. So this skill reframes product ownership from a role focused on work management to one centered on decision making and investment thinking and continuous value optimization. Notice that word continuous. It's never a one and done. And hopefully by the end of this skill, and hopefully the course, you'll stop seeing the backlog as a primary responsibility of product owners and begin seeing it as one of the many tools used to achieve better product outcomes. So let's go a little further and talk about our case study. Welcome back or welcome to PulsePoint Medical. Now the company is not struggling because the teams are ineffective. They're delivering sprint after sprint. They are completing stories and they

1:17are maintaining a healthy backlog. But the customers aren't noticeably happier and revenue has plateaued, meaning it's leveled out. And we all know that leadership wants it to continue going up, up, up. Sales is frustrated, obviously, and support is overwhelmed with recurring requests. And yes, I use air quotes once in a while. So leadership keeps asking why so much work produces so little measurable improvement. Lots of work, very little improvement. And at first glance, it may seem like a delivery problem. It isn't. It's a product ownership problem. Many product owners spend their days just organizing work. They refine backlog items. They answer questions from developers and they meet with stakeholders and they help prepare for sprint planning.

2:13And those activities are important, but they aren't the purpose of product ownership. The purpose is to maximize value. So throughout this course and starting in this skill, we're going to start with a single question and I'm going to ask it over and over. If everything is important, how does an experienced product owner decide what actually deserves attention? And that question begins here. And just so you know, I'm wearing my do good work hat by Anthony Annarino. So get ready. We're going to do some good work starting now.

0:00Let's jump into it in section one. The backlog is not the product. So this first section is focused on separating backlog management from product management. And the first thing you need to recognize is that the backlog is the means to the end. It's not the end itself. So let's start with a simple question. If I handed you or someone else, if they handed you a perfectly organized backlog, do you think you would automatically have a successful product? And most people will likely say yes. But experienced product owners know better. So let's dig into this a little bit further and figure out why. Why does the backlog receive so much attention? Well, companies usually focus on the work that's visible. They can see it. It's on the board. It's right there. That's why we have transparency in Scrum. Backlogs are tangible. They can be reviewed. They can be organized, measured, discussed ad nauseum. And that means too much. But they're visible. So it's easy to think of them as the product itself. The backlog becomes the center of attention, even though

1:18customers never experience the backlog. And this is internal, by the way. So it's easy to think that all of your stakeholders, internal and external, are focused on the backlog. But your customers experience the product, not the stories. They don't celebrate completed backlog items. They don't need to. They don't want to. They don't even know about it. And if they did, they still wouldn't want to. They experience the outcome. Things like faster workflows, easier interactions, fewer frustrations, and better outcomes. Stories disappear after delivery. It's the customer value that remains.

2:03And let's talk about value. Busy doesn't mean valuable. Let's say PulsePoint's backlog has hundreds of items and the teams stay fully utilized, which is going to make engineering management pretty happy. Velocity remains consistent. But why isn't customer satisfaction changing? And if it does, it's very little. I mean, think about it. Everyone's working, but few people are improving the outcomes. So let's talk about the difference between outputs versus outcomes. Outputs. Stories are completed. Features are delivered. Velocity is achieved.

2:48And it feels really good. But that's not the same thing as outcomes. Here are some of those. Customer adoption, meaning they like it. It goes up. Reduced complaints. Reduced trouble tickets. Increased renewals. Improved revenue. Higher engagement. Do you see the difference? Experienced product owners are aware of both, but they optimize for the outcome. Make no mistake. And this is why organizations fall into this trap. It's a lot easier to measure activity or busyness than it is value. Activity produces reports. Value requires observation and evidence. And most importantly, patience. Organizations very often reward completion because it's easier than measuring the impact. So let's think of this through a better mental model.

3:45Think of the backlog as a map. You've probably seen a map before. And a map is very useful. But owning the map is not the same as reaching your destination, especially if you don't know how to use it. Likewise, maintaining a backlog isn't the same thing as creating a successful product. So let's go back to PulsePoint. The backlog looks healthy, but the product doesn't. That tells us that the real question isn't, what should we build next? That's the wrong question.

4:20The question should be, why are we building this at all? So let's talk about the next skill. By now, hopefully, very quickly, we've stopped confusing work or busyness or activities with value. So let's start asking why the outcomes actually matter. The backlog organizes work, but it does not define success. Great product owners never mistake activity for achievement. But if managing work isn't the goal, what exactly are experienced product owners trying to accomplish?

4:57Well, let's figure it out in the next section.

0:00Welcome to Section 2. Let's talk about owning outcomes instead of work. And you can see it in the graphic. Let's look over here to the left. These are simply outputs. Stories completed, velocity, the burndown chart, how much of a percentage we hit on the sprint goal, defects, release progress. Do you see the difference? That's just work. The real difference is over here. It's the outcome that matters. And sometimes it's harder to measure, but you can't ignore it because that is the end state you are after. Maybe it's an increase in customer satisfaction or a better adoption rate or renewal rate, whatever it is. Ultimately, the outcomes are what the customers experience, and that's what you're trying to own. So let's jump into it.

0:55Let's say that every request sounds urgent and every stakeholder believes their feature matters the most. Experienced product owners ask a different question before discussing solutions. What problem are we actually trying to solve? And that's a good one. So let's figure it out. The first thing we need to do is start with the problem. Features are simply proposed solutions. Problems should be investigated first. I can't tell you how many times I've seen people do an excellent job of solving the wrong problem, and many times it was never a problem. They just made it up in their head. So when we jump directly to implementation, we risk solving the wrong problem exceptionally well, and we're good at it. So let's talk about some different types of outcomes.

1:50First, you have customer outcomes. Well, who can tell you the most about that? Well, that would be the customer, whoever it is, internal, external, or both. And then we have business outcomes. Who can tell you the most about that? Usually finance and leadership. Maybe they captured more market share. Maybe they reduced churn. Maybe they increased profit. Maybe they made the value optimization of any particular product higher, whatever it was. Think organizational outcomes, and hopefully they are positive because positive is always better. Strong product owners try to find the alignment between all of them. And there's a huge difference between what somebody wants and what somebody needs. On the predictive project management side of the house, I can very clearly tell you what that is. The difference between want and need is money, and stakeholders are really good at describing what they want. And customers often reveal what they need through behavior rather than words. Think adoption. Learning to distinguish between the two is a competitive advantage. So let's go back to PulsePoint for just a moment. Sales requested a

3:09custom dashboard for a major prospect. Kind of makes sense. And support asks for improvements to reduce recurring calls. They're trying to bring down trouble tickets. And engineering recommends addressing technical debt because it slows delivery. Now every request has merit, and everybody is operating in a system that they believe is within the best interest of that system. Nobody is competing with anybody else on purpose. Nobody is trying to be malicious. And the product owner's job is not to pick a favorite. It's to understand which decision creates the greatest value.

3:50So we need to figure out how to measure success before we build anything. Before approving work, we should ask, what changes if we succeed? And how will we know it? What evidence do we need to tell us that we're right or wrong? You can confirm or refute, but you need to do one of them. If success can't be described, then the work probably isn't ready. And the outcome itself will create a better conversation. When discussions focus on outcomes instead of features, stakeholders begin collaborating instead of competing. Go back to my previous example. Sales wanted something. Engineering wanted something, etc. And when we have a conversation about the outcome, the opinions will shift to evidence. I think you understand the difference. And if we do that, the decisions become clear. Not easier, just more clear. And I don't like to say clearer because there's too many r's there. Don't think for a second that the trade-offs don't still exist because they do. But now they're grounded in purpose instead of politics. So we need to look beyond delivery. We delivered some

5:08software. Yay! Is that really the finish line? No. Figuring out whether or not it created value, that's the finish line. Because think about it. Let's say we deliver something every week and sales never increase and revenue never goes up and customer satisfaction stays flat. What are we really doing? Are we creating better outcomes or just better outputs? Because one does not automatically equal the other. And experienced product owners don't measure success by how much they shipped. They measure success by what changes after it ships. So let me leave you with a final question. If every decision influences future value, how should experienced product owners think about those decisions?

0:00Welcome to Section 3. Let's talk about the product owner's real decision space. Now, most product owners might believe they spend their time prioritizing work, but experienced product owners spend their time making decisions. The backlog simply reflects those decisions. And let's take a look at it on the screen. What's actually in the backlog? Maybe as a reminder for you, and maybe even me. Well, we have tech debt. We had some fixes along the way and we have to take care of them eventually. Tech debt. What about new markets? Should we do something to try and expand into that? Maybe this feature will take us out of this region into that one. And what about a key customer request? Or really, any customer request. Compliance, always a big deal. We should stay compliant so we don't incur some kind of penalty by the governing body for this particular product.

0:59Think medical device products. Do you really think someone wants to run out of compliance with medical devices? I don't think so. What about upgrades? How can we make sure we're sustaining the architecture for the next 10 years? I don't know, but maybe we should talk about it. What about innovation ideas and experiments? There's a ton of stuff in the backlog, and that's the space where the product owner is trying to make decisions. So let's go a little further and talk about why that matters. Well, right out of the gate, every decision has a cost. Choosing one item means you are delaying something else. Even saying yes carries a hidden not yet for something else.

1:47The only way you can delay everything is just to say no to everything, and we know you're not going to do that very long. You have a fixed amount of time and budget and attention and development, and each one of them is a limited resource. Ultimately, value is only one variable. One feature may offer tremendous value, but arrive too late. What happens to the value then? Let's say you have a fire at the house, and you put it out with the garden hose, and then the fire truck shows up. It would have been nice 15 minutes ago, and obviously they're an important aspect, but what about the value that could have been delivered if they had shown up earlier? You see the difference? And that may be a little weird, but it's the first thing that jumped into my head. Another feature may reduce organizational risk, and maybe another one unlocks future opportunities. Experienced product owners rarely optimize for a single factor, so let's talk about investment thinking.

2:55Imagine that every backlog item was competing for funding, and they usually are. Some of them offer quick returns. Others reduce future cost. Others reduce churn. Now, some of them might be high risk with potentially high reward. Every item becomes an investment competing for scarce resources, and I talked about that just a moment ago, so let's go back to PulsePoint. Leadership is asking for analytics. Support is requesting usability improvements, and engineering is requesting an infrastructure upgrade. Compliance definitely wants some regulatory updates. None of them are wrong. None of them are malicious, but they are all competing with one another. You only have a finite amount of resources, so the product owner's responsibility is deciding which investment creates the greatest overall value, and every single one of those decisions requires a trade-off.

3:58Great product owners don't avoid difficult choices. They simply make them transparent. They explain why something is being delayed just as clearly as why something is moving forward, so you need to become comfortable with uncertainty. Perfect information rarely exists. If it did, we would always know what our customers want, and we would always be able to deliver it, but waiting for certainty often means missing opportunities. Experienced product owners become comfortable making thoughtful decisions with incomplete information, and the backlog becomes evidence. Instead of looking at the backlog as simply a task list, think of it as visible evidence of your product strategy. Every ordered item tells a story about what the company currently believes matters the most, so we need a new way of seeing things. Product ownership is not about organizing work. It's about making investment decisions repeatedly, thoughtfully, and transparently, and the backlog records those decisions. It does not make them. Great product owners think like investors long before they think like administrators, so let me ask one more question.

5:18If product owners are constantly making investment decisions, what information should influence those decisions? Let's find out in the next section.

0:00Welcome to section four and this one's going to blow your mind. Hopefully, maybe just a little. Let's see the whole product system. Now product ownership exists within a dynamic system of customers and markets and organizational goals, technology and stakeholders and engineering. You're marketing customers and finance and executives and sales and marketing. Do you see the system? Because there's a lot going on here and it may look busy, but it doesn't make it look less true or rather it's not less true because it looks busy. I think you understand what I mean and what is firmly planted right in the middle value. So think about it. Products don't exist in isolation. They can't, which means product owners can't exist in isolation either. Every decision they make is influenced by forces inside and outside of the organization. So let's dig into it. Products live inside system and every product interacts with customers and users and competitors and regulations and technology

1:15and organizational strategy and market conditions and lions and tigers and bears. Oh my, maybe not those last three, but if you ignore any one of them, you can have unintended consequences. So imagine a product lens. Instead of just seeing the backlog items, experienced product owners constantly scan the larger environment, the system, if you will, for the signals that influence value.

1:46So we need to listen beyond the stakeholders. Now stakeholders do provide valuable perspectives. They always will, but they don't possess the entire picture. They only see their part of it. Engineering sees what they see. Finance sees what they see. The end users, the customers, well, they have their own view as well. Customers, usage data, market trends, operational constraints, business strategy. Every single one of them deserves and gets a voice. So let's expand the view. Let's say we go back to PulsePoint and a requested feature appears very valuable until market research reveals that competitors are solving a different problem, which begs the question, why? Why are they solving a different problem? And suddenly the conversation changes.

2:42The context will change decisions. So you must balance multiple perspectives. No single perspective in the land of unicorns will win every discussion. And we are firmly in the land of unicorns, scrum.org, not where you work. Product ownership requires balancing competing viewpoints without becoming captive to any one of them. And the system constantly changes. Customer expectations and needs evolve. Technology moves. Think of AI. No one really understood it two years ago. And now it's everywhere. My toaster has AI. Business priorities shift. Product ownership is continuous adaptation. Not one time planning, not anymore. Oh, and it never was. So you must look for signals. Experienced product owners notice changing customer behavior, support trends, market movement, technical constraints, emerging risk, unexpected opportunities. Small signals now often become major decisions later.

3:57So you absolutely must see more than the backlog. You must see beyond it. The backlog is only one representation of a much larger product ecosystem. The product owner's responsibility extends well beyond it. So great product owners develop situational awareness. They don't simply react to requests. They think about and interpret the system that created those requests. So here's a question. If requests are coming from every direction, how are experienced product owners supposed to respond? Let's talk about it in the next section.

0:00Let's take this idea out of pulse point for a few minutes and look at what it might mean in the real world. So consider Bosch power tools. Think about something as seemingly straightforward as a cordless power drill or a laser measuring device. If you're looking at the product through a narrow product owner lens, you might naturally focus on customer needs or features and improvements and what might come next. And nothing is wrong with any of those things. But now let's widen the lens. Bosch develops physical products that have to move from an idea through engineering and sourcing, manufacturing, distribution, sales, customer use support, and eventually the end of the product's useful life. Suddenly there are a lot more things capable of affecting the outcome. Bosch provides a great example with its Quigo green laser.

0:57When Bosch set out to make the product more sustainable, they didn't just look at the features of the laser itself. They examined the product across its entire life cycle from the raw material they're going to use to make it, through manufacturing, through distribution, to how customers use it and eventually dispose of it. Now think about what just happened to our decision space. We went from what should this product do to questions like what materials should we use, where are those materials coming from, how will manufacturing affect our goals, what happens during distribution, how will customers actually use the product, and what happens when they're finally finished with it. That's a very different view of a product and Bosch's broader approach to product development reinforces the same idea. The company describes simultaneous engineering teams where manufacturing works alongside product and process development along with purchasing, logistics, and other areas while new products are being developed.

2:07Why? Because decisions in one part of the system affect decisions someplace else and that's where I want you to put yourself in the picture of the product owner. You don't suddenly own manufacturing, you don't run purchasing, you don't control logistics, and you certainly don't control your customers. But if decisions in those areas can material affect your product outcome, can you afford not to understand them? Probably not. That's the wider lens we've been talking about in this skill. A product owner with a narrow view might ask, what should we put in the backlog next?

2:47An advanced product owner needs to be capable of asking a bigger question. What's happening across our product system that should influence what we do next? Notice that I didn't say you need to control the whole system. What I said was you need to see it. Because once you see it, you can keep asking better questions. You can bring the right people in the conversation. You can recognize constraints earlier. You can spot opportunities that would never appear if your attention never moved beyond the product backlog. And you can make better decisions about where the product should go next. That's why I like the Bosch example. It reminds us that the product isn't just the thing we're building. There's an entire system around it. And sometimes the most important information a product owner needs is sitting somewhere well outside of the backlog. So maybe one of the simplest ways to describe the transition towards advanced product ownership is this. Keep managing the backlog. Just remember to look up from it once in a while.

3:52Thank you.

0:00Welcome to Section 5, and let's talk about moving from requests to decisions. Now, experienced product owners evaluate requests rather than automatically accepting or rejecting them. They don't automatically say no, and they certainly don't automatically say yes. Well, who's competing for it? It may seem real easy to say yes to the CEO. He is the CEO. But what about compliance, and what about engineering, or customer support, or even sales? How do we decide what should happen? We understand the from whom. We know what that means. And sorry about that. I got a little crazy. But another important question is, why now? That one always gets me started. Why now? Well, let's go a little further and figure it out.

0:56I'm sure we can. Oh, and let me come back on screen. I think I forgot about it in the last section. Sorry about that. Anyway, now every request solves something. Hopefully, behind every feature request lies a problem that somebody wants solved. They think it needs solved, whether it's engineering, the CEO, sales, finance, compliance. It doesn't matter. And understanding the problem that it's supposed to solve matters more than immediately discussing solutions.

1:29So you need to be curious before you commit to it. Instead of immediately accepting requests, you should be asking, why now? For whom? Compared to what? What evidence supports this? And by that, I mean, what evidence do you have that says this problem should be solved right now ahead of everything else? And what changes if we actually succeed? So let's say PulsePoint has five different requests, and you saw it in the graphic. You had sales and support, engineering, compliance, and likely the most important, leadership. But how can leadership win every single time?

2:14That is not empowerment. That is not PSPO2. That is not advanced. That is a dictatorship instead of a partnership. And that's what you're really looking for. Now, every one of them is convinced that their request is the most important, but experienced product owners slow the conversation down before speeding decisions up. So you must absolutely separate urgency from importance. Urgent requests, and they all seem to be urgent, receive attention first. But important requests create lasting value. Those aren't always the same thing, no matter what they're telling you.

2:57So you need to challenge these ideas respectfully, sometimes aggressively, but definitely respectfully. Questioning assumptions or their evidence? That's not opposition. That's your job. It's responsible product ownership. Strong product owners can challenge ideas while maintaining strong stakeholder relationships, and that takes time. It takes rapport, and it also takes trust.

3:28Well, how do we build trust? Transparency. Transparency builds trust. Stakeholders don't always agree with decisions because some of them are always going to go against their request. It must. Can you really solve everyone's request at the same time with limited resources? And the answer is no. The problem you have is they don't always appreciate understanding those decisions. So if you explain the reasoning and the evidence and the trade-offs, you are being transparent. And transparency, once again, is the only way to build trust. You also need to ask better questions because better questions lead to better products. Better questions lead to better outcomes. The quality of product ownership often begins on the quality of conversations that happen long before development even begins. Go back to what I said a moment ago. Why is this request the most important, and what evidence do you have to support it? Is it just in your head, or do we have some kind of market research? I have no idea, but before I can decide,

4:44I'm going to keep asking questions. I want to see the receipts, so bring them. Remember, every decision teaches something. Good product owners don't simply approve work. They learn from every decision, and they use that learning to improve the future decisions. So let's reflect. And yes, that is the reflection glide. Requests begin conversations, and evidence will guide those decisions. But value, that's what determines the priority. And if this is what experienced product owners do every day, what qualities define them? Well, let's talk about it in the next section.

0:00Welcome to section six and let's define product ownership. Now we've spent this whole skill expanding product ownership together beyond backlog management and now it's time to redefine the role completely. So here is your product owner. If we're going to redefine it, what is she doing? What are her qualities? What is she tasked with? Well, she's a decision maker and when I say she, I mean the product owner. A value optimizer, a continuous learner and an alignment builder.

0:38The PO must also be a strategic thinker, aware of the systems and there are multiple systems at play. You have the internal system, the external system, the overlap perhaps with a competitor or perhaps with a partner or a vendor. Think of a Venn diagram and you're sitting right in the middle of it. You must influence people and be a strong communicator and you must always be outcome focused and I hope you notice that it doesn't say anywhere that you should agree with everyone. You should accept everyone's request. You should always be saying yes. It doesn't say that anywhere because if you do that, that's the old definition of product ownership, not the new one. So let's drive on. Let me come back on screen one more time. Here we go. First and foremost, product owners are decision makers. Now the backlog doesn't create value. It's just a list really. The decisions the product owner makes, that's what creates value. Product owners are value optimizers because every decision they make is seeking to maximize the value within the limited resources that they have, within the system that they operate and by the system I mean

2:00the CEO, finance, sales, engineering, customers, compliance, and the constraints, time, cost, money, quality, risk, the industry, the market, the trends, whatever it is. That's a lot of Venn diagrams. In fact, I'm not even sure what that's called when you have that many circles that overlap, but it's pretty complicated. They're also continuous learners. Every single release provides evidence. Every customer interaction creates learning. Great product owners are continuously adapting. Notice it didn't say stagnating. You can't. Every customer request is different. So every situation is different. Every request is different. So why isn't every situation an opportunity to learn? And it is. Thanks, Bob, for pointing that out. Thanks, Captain Obvious. And product owners build alignment. Alignment with who? Well, customers, stakeholders, developers, leadership. There are a ton of different perspectives out there, and if you can coalesce them, if you can align them, if you can set the proper expectation,

3:15you can turn that into better products when they have a shared outcome. But notice it says shared outcome. So product owners must think strategically. Today's backlog influences tomorrow's product. Experienced product owners constantly connect immediate decisions to long-term direction. And here's a kicker. They do it without authority. Very few product owners possess formal authority over everyone influencing the product. It's not set up that way.

3:48It's not supposed to be that way. You have influence and trust, strong communication skills, hopefully, and your credibility. They become your most valuable leadership tools. So let's go back to PulsePoint. The PulsePoint product owner never became more successful by writing better stories. None of them do. They become successful because of better decisions. Everything else improved because of that mind shift. So here's a new mental model. The backlog simply isn't your primary responsibility. Value is. Always. The backlog is just one of the tools to pursue it. So advanced product ownership is measured by decisions. It's measured by learning.

4:36And most importantly, it's measured by the outcomes. Not good backlog maintenance and refinement. And here's one more question before we finish this section. If product ownership is really about investment decisions, how should experienced product owners decide where to invest first? I don't know, but I'm thinking we'll figure it out together really soon.

0:00All right. Welcome to the final section. Let's talk about some key takeaways and what I would like you to carry forward into the next skill and the course. So let's go back to the opening story. PulsePoint did not need a better backlog. What they needed was better decisions. So let's talk about some of the major transformations they're going through and the key takeaways for this particular skill. Backlogs organize work, but they don't create value. It is not the product.

0:32Products succeed through outcomes, not outputs. Outputs, work, activities, busyness, stuff. Does stuff really create value or is it the outcome that creates the value? I know you know the answer. And every backlog item is an investment. So those decisions you are making are investments. Product owners must think in systems, not isolated requests. So think about your house. Let's say you want to vacuum the living room, the carpet. Do you keep the vacuum in the living room or perhaps in a closet somewhere? Okay. So if you do, that's now two parts of your house. And let's say you're trying to clean the windows. Do you keep the cleaning supplies near the window or do you likely keep them in a cabinet somewhere, maybe under the sink or in the laundry room? Notice how the system simply expands just because you're trying to make decisions. Well, the same thing happens here. And I hope that's not weird, but again, it's the first thing that popped into my head. And the first thing that pops into my head isn't always the

1:48best. So better questions produce better decisions. You can't simply be a yes man or woman for product ownership. How can you make better decisions? You can't because every decision is yes. You know the problem with that one. And finally, product owners optimize value continuously. It's not a one and done. It can't be ever, I guess, unless maybe you have one backlog item left and I've never seen just one. So here's what I'm going to leave you with this week or next week. Perhaps every time someone asks you to prioritize a backlog item, pause for just a moment. And instead of asking yourself, where should this go? Ask yourself instead, what value does this create? And how will I know it? That one question has the potential to change not only your backlog, but the way you lead products. And here's one more thought. If every backlog item represents an investment competing for limited time and money and attention, then the next challenge isn't simply deciding what to build. It's learning how experienced product owners evaluate investments

3:08under uncertainty. And we'll get into that in the next skill.