Product Ownership Beyond the Backlog

0:00Welcome to skill number one of the PSPO2, the advanced course. And this one is all about product

0:07ownership beyond the backlog. So most product owners learn how to manage a backlog. That's PSPO1.

0:16And experienced product owners learn how to maximize product value. This course is going

0:23to take you from PSPO1 over to 2. So this skill reframes product ownership from a role focused

0:31on work management to one centered on decision making and investment thinking and continuous

0:38value optimization. Notice that word continuous. It's never a one and done. And hopefully by the

0:45end of this skill, and hopefully the course, you'll stop seeing the backlog as a primary

0:51responsibility of product owners and begin seeing it as one of the many tools used to achieve

0:57better product outcomes. So let's go a little further and talk about our case study. Welcome

1:04back or welcome to PulsePoint Medical. Now the company is not struggling because the teams are

1:11ineffective. 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

1:25has plateaued, meaning it's leveled out. And we all know that leadership wants it to continue

1:31going up, up, up. Sales is frustrated, obviously, and support is overwhelmed with recurring requests.

1:39And yes, I use air quotes once in a while. So leadership keeps asking why so much work produces

1:46so little measurable improvement. Lots of work, very little improvement. And at first glance,

1:54it may seem like a delivery problem. It isn't. It's a product ownership problem. Many product

2:01owners spend their days just organizing work. They refine backlog items. They answer questions

2:07from 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.

2:18The purpose is to maximize value. So throughout this course and starting in this skill,

2:25we're going to start with a single question and I'm going to ask it over and over.

2:30If everything is important, how does an experienced product owner decide what

2:36actually deserves attention? And that question begins here. And just so you know, I'm wearing

2:43my 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

0:08on separating backlog management from product management. And the first thing you need to

0:14recognize is that the backlog is the means to the end. It's not the end itself. So let's start with

0:21a simple question. If I handed you or someone else, if they handed you a perfectly organized

0:29backlog, do you think you would automatically have a successful product? And most people will

0:35likely say yes. But experienced product owners know better. So let's dig into this a little bit

0:43further and figure out why. Why does the backlog receive so much attention? Well, companies usually

0:50focus on the work that's visible. They can see it. It's on the board. It's right there. That's

0:56why we have transparency in Scrum. Backlogs are tangible. They can be reviewed. They can be

1:03organized, measured, discussed ad nauseum. And that means too much. But they're visible. So it's easy

1:12to 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

1:26all of your stakeholders, internal and external, are focused on the backlog. But your customers

1:32experience the product, not the stories. They don't celebrate completed backlog items. They don't need

1:41to. They don't want to. They don't even know about it. And if they did, they still wouldn't want to.

1:48They experience the outcome. Things like faster workflows, easier interactions, fewer frustrations,

1:56and 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

2:12hundreds of items and the teams stay fully utilized, which is going to make engineering

2:17management pretty happy. Velocity remains consistent. But why isn't customer satisfaction

2:24changing? And if it does, it's very little. I mean, think about it. Everyone's working,

2:31but few people are improving the outcomes. So let's talk about the difference between outputs

2:38versus 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.

2:55Customer adoption, meaning they like it. It goes up. Reduced complaints. Reduced trouble tickets.

3:02Increased renewals. Improved revenue. Higher engagement. Do you see the difference? Experienced

3:10product owners are aware of both, but they optimize for the outcome. Make no mistake.

3:16And this is why organizations fall into this trap. It's a lot easier to measure activity

3:22or busyness than it is value. Activity produces reports. Value requires observation

3:31and evidence. And most importantly, patience. Organizations very often reward completion

3:38because 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.

3:52But owning the map is not the same as reaching your destination, especially if you don't know

3:59how to use it. Likewise, maintaining a backlog isn't the same thing as creating a successful

4:06product. So let's go back to PulsePoint. The backlog looks healthy, but the product doesn't.

4:13That 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.

4:27By now, hopefully, very quickly, we've stopped confusing work or busyness or activities with

4:35value. So let's start asking why the outcomes actually matter. The backlog organizes work,

4:42but it does not define success. Great product owners never mistake activity for achievement.

4:49But 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

0:06in the graphic. Let's look over here to the left. These are simply outputs. Stories completed,

0:13velocity, the burndown chart, how much of a percentage we hit on the sprint goal, defects,

0:20release progress. Do you see the difference? That's just work. The real difference is over

0:27here. It's the outcome that matters. And sometimes it's harder to measure, but you can't ignore it

0:34because that is the end state you are after. Maybe it's an increase in customer satisfaction

0:41or a better adoption rate or renewal rate, whatever it is. Ultimately, the outcomes are

0:48what 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

1:01the most. Experienced product owners ask a different question before discussing solutions.

1:08What problem are we actually trying to solve? And that's a good one. So let's figure it out.

1:15The first thing we need to do is start with the problem. Features are simply proposed solutions.

1:22Problems should be investigated first. I can't tell you how many times I've seen people do an

1:28excellent job of solving the wrong problem, and many times it was never a problem. They just made

1:36it up in their head. So when we jump directly to implementation, we risk solving the wrong problem

1:43exceptionally 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

1:56the customer, whoever it is, internal, external, or both. And then we have business outcomes.

2:04Who can tell you the most about that? Usually finance and leadership. Maybe they captured more

2:10market share. Maybe they reduced churn. Maybe they increased profit. Maybe they made the value

2:17optimization of any particular product higher, whatever it was. Think organizational outcomes,

2:24and hopefully they are positive because positive is always better. Strong product owners try to

2:30find the alignment between all of them. And there's a huge difference between what somebody

2:37wants and what somebody needs. On the predictive project management side of the house, I can very

2:44clearly tell you what that is. The difference between want and need is money, and stakeholders

2:51are really good at describing what they want. And customers often reveal what they need through

2:56behavior rather than words. Think adoption. Learning to distinguish between the two is a

3:03competitive 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

3:16reduce recurring calls. They're trying to bring down trouble tickets. And engineering recommends

3:22addressing technical debt because it slows delivery. Now every request has merit, and everybody is

3:30operating in a system that they believe is within the best interest of that system. Nobody is

3:37competing with anybody else on purpose. Nobody is trying to be malicious. And the product owner's

3:43job 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,

3:56we should ask, what changes if we succeed? And how will we know it? What evidence do we need to tell

4:04us that we're right or wrong? You can confirm or refute, but you need to do one of them. If success

4:11can't be described, then the work probably isn't ready. And the outcome itself will create a better

4:19conversation. When discussions focus on outcomes instead of features, stakeholders begin collaborating

4:27instead of competing. Go back to my previous example. Sales wanted something. Engineering

4:33wanted something, etc. And when we have a conversation about the outcome, the opinions

4:40will shift to evidence. I think you understand the difference. And if we do that, the decisions become

4:48clear. Not easier, just more clear. And I don't like to say clearer because there's too many r's

4:55there. Don't think for a second that the trade-offs don't still exist because they do. But now they're

5:01grounded 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,

5:18that's the finish line. Because think about it. Let's say we deliver something every week

5:23and sales never increase and revenue never goes up and customer satisfaction stays flat.

5:31What are we really doing? Are we creating better outcomes or just better outputs? Because one does

5:39not automatically equal the other. And experienced product owners don't measure success by how much

5:46they shipped. They measure success by what changes after it ships. So let me leave you

5:53with a final question. If every decision influences future value, how should experienced product owners

6:01think about those decisions?

0:00Welcome to Section 3. Let's talk about the product owner's real decision space.

0:05Now, most product owners might believe they spend their time prioritizing work,

0:10but experienced product owners spend their time making decisions.

0:15The backlog simply reflects those decisions. And let's take a look at it on the screen.

0:21What's actually in the backlog? Maybe as a reminder for you, and maybe even me.

0:27Well, we have tech debt. We had some fixes along the way and we have to take care of them

0:32eventually. Tech debt. What about new markets? Should we do something to try and expand into

0:39that? Maybe this feature will take us out of this region into that one. And what about a key

0:45customer request? Or really, any customer request. Compliance, always a big deal. We should stay

0:52compliant 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

1:04with medical devices? I don't think so. What about upgrades? How can we make sure we're sustaining

1:12the architecture for the next 10 years? I don't know, but maybe we should talk about it.

1:18What about innovation ideas and experiments? There's a ton of stuff in the backlog, and that's

1:25the space where the product owner is trying to make decisions. So let's go a little further and

1:31talk about why that matters. Well, right out of the gate, every decision has a cost. Choosing one item

1:39means 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

1:52to do that very long. You have a fixed amount of time and budget and attention and development,

2:00and each one of them is a limited resource. Ultimately, value is only one variable. One feature

2:09may offer tremendous value, but arrive too late. What happens to the value then? Let's say you have

2:16a fire at the house, and you put it out with the garden hose, and then the fire truck shows up. It

2:22would have been nice 15 minutes ago, and obviously they're an important aspect, but what about the

2:29value that could have been delivered if they had shown up earlier? You see the difference? And that

2:35may be a little weird, but it's the first thing that jumped into my head. Another feature may

2:40reduce organizational risk, and maybe another one unlocks future opportunities. Experienced

2:47product 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

3:02quick returns. Others reduce future cost. Others reduce churn. Now, some of them might be high risk

3:10with potentially high reward. Every item becomes an investment competing for scarce resources,

3:17and I talked about that just a moment ago, so let's go back to PulsePoint. Leadership is asking

3:23for analytics. Support is requesting usability improvements, and engineering is requesting an

3:30infrastructure upgrade. Compliance definitely wants some regulatory updates. None of them are

3:37wrong. None of them are malicious, but they are all competing with one another. You only have a finite

3:44amount of resources, so the product owner's responsibility is deciding which investment

3:50creates 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.

4:04They explain why something is being delayed just as clearly as why something is moving forward,

4:10so you need to become comfortable with uncertainty. Perfect information rarely exists. If it did,

4:17we would always know what our customers want, and we would always be able to deliver it,

4:22but waiting for certainty often means missing opportunities. Experienced product owners become

4:29comfortable making thoughtful decisions with incomplete information, and the backlog becomes

4:36evidence. Instead of looking at the backlog as simply a task list, think of it as visible evidence

4:44of your product strategy. Every ordered item tells a story about what the company currently believes

4:50matters the most, so we need a new way of seeing things. Product ownership is not about organizing

4:58work. It's about making investment decisions repeatedly, thoughtfully, and transparently,

5:06and the backlog records those decisions. It does not make them. Great product owners think

5:12like investors long before they think like administrators, so let me ask one more question.

5:18If product owners are constantly making investment decisions,

5:22what 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.

0:04Hopefully, maybe just a little. Let's see the whole product system.

0:08Now product ownership exists within a dynamic system of customers and markets and organizational

0:15goals, technology and stakeholders and engineering. You're marketing customers and finance and

0:23executives and sales and marketing. Do you see the system? Because there's a lot going on

0:29here and it may look busy, but it doesn't make it look less true or rather it's not less true

0:36because it looks busy. I think you understand what I mean and what is firmly planted right in the

0:43middle value. So think about it. Products don't exist in isolation. They can't, which means

0:51product owners can't exist in isolation either. Every decision they make is influenced by forces

0:57inside and outside of the organization. So let's dig into it. Products live inside system and

1:07every 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,

1:22maybe not those last three, but if you ignore any one of them, you can have unintended consequences.

1:29So imagine a product lens. Instead of just seeing the backlog items, experienced product owners

1:38constantly 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.

1:53They always will, but they don't possess the entire picture. They only see their part of it.

1:59Engineering sees what they see. Finance sees what they see. The end users, the customers, well,

2:07they have their own view as well. Customers, usage data, market trends, operational constraints,

2:14business strategy. Every single one of them deserves and gets a voice. So let's expand the

2:22view. Let's say we go back to PulsePoint and a requested feature appears very valuable until

2:29market research reveals that competitors are solving a different problem, which begs the

2:34question, 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.

2:50No single perspective in the land of unicorns will win every discussion. And we are firmly

2:56in the land of unicorns, scrum.org, not where you work. Product ownership requires balancing

3:04competing viewpoints without becoming captive to any one of them. And the system constantly

3:11changes. Customer expectations and needs evolve. Technology moves. Think of AI. No one really

3:20understood it two years ago. And now it's everywhere. My toaster has AI. Business priorities

3:27shift. Product ownership is continuous adaptation. Not one time planning, not anymore. Oh, and it

3:36never was. So you must look for signals. Experienced product owners notice changing

3:43customer behavior, support trends, market movement, technical constraints, emerging risk,

3:49unexpected 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

4:03representation of a much larger product ecosystem. The product owner's responsibility extends well

4:10beyond it. So great product owners develop situational awareness. They don't simply react

4:17to requests. They think about and interpret the system that created those requests. So here's a

4:24question. If requests are coming from every direction, how are experienced product owners

4:31supposed 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

0:05in the real world. So consider Bosch power tools. Think about something as seemingly

0:11straightforward as a cordless power drill or a laser measuring device. If you're looking at the

0:17product through a narrow product owner lens, you might naturally focus on customer needs or

0:24features and improvements and what might come next. And nothing is wrong with any of those

0:29things. But now let's widen the lens. Bosch develops physical products that have to move

0:35from an idea through engineering and sourcing, manufacturing, distribution, sales, customer use

0:42support, and eventually the end of the product's useful life. Suddenly there are a lot more things

0:50capable 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

1:02features of the laser itself. They examined the product across its entire life cycle from the

1:09raw material they're going to use to make it, through manufacturing, through distribution,

1:14to how customers use it and eventually dispose of it. Now think about what just happened to our

1:21decision space. We went from what should this product do to questions like what materials

1:29should we use, where are those materials coming from, how will manufacturing affect our goals,

1:36what happens during distribution, how will customers actually use the product, and what

1:43happens when they're finally finished with it. That's a very different view of a product and

1:48Bosch's broader approach to product development reinforces the same idea. The company describes

1:54simultaneous engineering teams where manufacturing works alongside product and process development

2:01along 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

2:15I want you to put yourself in the picture of the product owner. You don't suddenly own manufacturing,

2:21you don't run purchasing, you don't control logistics, and you certainly don't control

2:26your customers. But if decisions in those areas can material affect your product outcome, can you

2:34afford not to understand them? Probably not. That's the wider lens we've been talking about

2:40in 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

2:53across our product system that should influence what we do next? Notice that I didn't say you

2:59need to control the whole system. What I said was you need to see it. Because once you see it,

3:06you can keep asking better questions. You can bring the right people in the conversation.

3:11You can recognize constraints earlier. You can spot opportunities that would never appear if

3:17your attention never moved beyond the product backlog. And you can make better decisions about

3:22where the product should go next. That's why I like the Bosch example. It reminds us that the

3:28product isn't just the thing we're building. There's an entire system around it. And sometimes

3:34the most important information a product owner needs is sitting somewhere well outside of the

3:39backlog. So maybe one of the simplest ways to describe the transition towards advanced product

3:45ownership 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

0:07product owners evaluate requests rather than automatically accepting or rejecting them.

0:13They don't automatically say no, and they certainly don't automatically say yes. Well,

0:19who's competing for it? It may seem real easy to say yes to the CEO. He is the CEO.

0:27But what about compliance, and what about engineering, or customer support,

0:34or even sales? How do we decide what should happen? We understand the from whom. We know

0:42what that means. And sorry about that. I got a little crazy. But another important question is,

0:48why 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

1:01section. Sorry about that. Anyway, now every request solves something. Hopefully, behind

1:09every feature request lies a problem that somebody wants solved. They think it needs solved, whether

1:16it's engineering, the CEO, sales, finance, compliance. It doesn't matter. And understanding

1:22the 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,

1:36you should be asking, why now? For whom? Compared to what? What evidence supports this? And by that,

1:45I mean, what evidence do you have that says this problem should be solved right now ahead of

1:51everything else? And what changes if we actually succeed? So let's say PulsePoint has five different

1:58requests, and you saw it in the graphic. You had sales and support, engineering, compliance,

2:06and 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

2:22instead of a partnership. And that's what you're really looking for. Now, every one of them is

2:28convinced that their request is the most important, but experienced product owners slow the conversation

2:35down before speeding decisions up. So you must absolutely separate urgency from importance.

2:43Urgent requests, and they all seem to be urgent, receive attention first. But important requests

2:50create 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.

3:06Questioning assumptions or their evidence? That's not opposition. That's your job. It's

3:13responsible product ownership. Strong product owners can challenge ideas while maintaining

3:19strong 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

3:35always agree with decisions because some of them are always going to go against their request.

3:42It must. Can you really solve everyone's request at the same time with limited resources?

3:49And the answer is no. The problem you have is they don't always appreciate understanding those

3:55decisions. So if you explain the reasoning and the evidence and the trade-offs, you are being

4:02transparent. And transparency, once again, is the only way to build trust. You also need to ask

4:10better questions because better questions lead to better products. Better questions lead to better

4:16outcomes. The quality of product ownership often begins on the quality of conversations that

4:22happen long before development even begins. Go back to what I said a moment ago. Why is this

4:29request the most important, and what evidence do you have to support it? Is it just in your head,

4:37or 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,

4:50every decision teaches something. Good product owners don't simply approve work. They learn from

4:57every decision, and they use that learning to improve the future decisions. So let's reflect.

5:04And yes, that is the reflection glide. Requests begin conversations, and evidence will guide those

5:12decisions. But value, that's what determines the priority. And if this is what experienced product

5:20owners 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

0:07expanding product ownership together beyond backlog management and now it's time to redefine

0:13the role completely. So here is your product owner. If we're going to redefine it, what is she doing?

0:22What are her qualities? What is she tasked with? Well, she's a decision maker and when I say she,

0:30I 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.

0:46You have the internal system, the external system, the overlap perhaps with a competitor

0:52or perhaps with a partner or a vendor. Think of a Venn diagram and you're sitting right in the

0:58middle of it. You must influence people and be a strong communicator and you must always

1:05be outcome focused and I hope you notice that it doesn't say anywhere that you should agree

1:11with everyone. You should accept everyone's request. You should always be saying yes. It

1:18doesn't say that anywhere because if you do that, that's the old definition of product ownership,

1:23not the new one. So let's drive on. Let me come back on screen one more time. Here we go. First

1:31and foremost, product owners are decision makers. Now the backlog doesn't create value. It's just

1:39a list really. The decisions the product owner makes, that's what creates value. Product owners

1:46are value optimizers because every decision they make is seeking to maximize the value within the

1:53limited 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,

2:08money, quality, risk, the industry, the market, the trends, whatever it is. That's a lot of Venn

2:15diagrams. In fact, I'm not even sure what that's called when you have that many circles that

2:20overlap, but it's pretty complicated. They're also continuous learners. Every single release

2:27provides evidence. Every customer interaction creates learning. Great product owners are

2:33continuously adapting. Notice it didn't say stagnating. You can't. Every customer request

2:41is different. So every situation is different. Every request is different. So why isn't every

2:47situation an opportunity to learn? And it is. Thanks, Bob, for pointing that out. Thanks,

2:54Captain Obvious. And product owners build alignment. Alignment with who? Well, customers,

3:01stakeholders, developers, leadership. There are a ton of different perspectives out there,

3:08and 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

3:21shared outcome. So product owners must think strategically. Today's backlog influences

3:28tomorrow's product. Experienced product owners constantly connect immediate decisions

3:34to long-term direction. And here's a kicker. They do it without authority. Very few product

3:42owners 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,

3:55hopefully, and your credibility. They become your most valuable leadership tools.

4:02So let's go back to PulsePoint. The PulsePoint product owner never became more successful by

4:07writing better stories. None of them do. They become successful because of better decisions.

4:15Everything else improved because of that mind shift. So here's a new mental model. The backlog

4:22simply isn't your primary responsibility. Value is. Always. The backlog is just one of the tools

4:30to 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

4:42refinement. And here's one more question before we finish this section. If product ownership is

4:49really about investment decisions, how should experienced product owners decide where to

4:55invest 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

0:06like you to carry forward into the next skill and the course. So let's go back to the opening story.

0:13PulsePoint did not need a better backlog. What they needed was better decisions. So let's talk

0:19about some of the major transformations they're going through and the key takeaways for this

0:24particular 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.

0:42Does stuff really create value or is it the outcome that creates the value? I know you know

0:50the answer. And every backlog item is an investment. So those decisions you are making

0:58are investments. Product owners must think in systems, not isolated requests. So think about

1:06your house. Let's say you want to vacuum the living room, the carpet. Do you keep the vacuum

1:13in the living room or perhaps in a closet somewhere? Okay. So if you do, that's now two

1:19parts of your house. And let's say you're trying to clean the windows. Do you keep the cleaning

1:24supplies near the window or do you likely keep them in a cabinet somewhere, maybe under the

1:29sink or in the laundry room? Notice how the system simply expands just because you're trying to make

1:36decisions. Well, the same thing happens here. And I hope that's not weird, but again, it's the first

1:42thing 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

1:57ownership. How can you make better decisions? You can't because every decision is yes. You know the

2:05problem with that one. And finally, product owners optimize value continuously. It's not a one and

2:13done. It can't be ever, I guess, unless maybe you have one backlog item left and I've never seen

2:21just one. So here's what I'm going to leave you with this week or next week. Perhaps every time

2:28someone asks you to prioritize a backlog item, pause for just a moment. And instead of asking

2:34yourself, where should this go? Ask yourself instead, what value does this create? And how

2:42will I know it? That one question has the potential to change not only your backlog,

2:48but the way you lead products. And here's one more thought. If every backlog item represents

2:54an investment competing for limited time and money and attention, then the next challenge

3:01isn'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.