Mike Lyons says delete backlog items you can't justify to customers. Keep only what matters, prioritize ruthlessly at the top, and stop refining work buried deep. He walks through a Schedule Predictor example and shows how the Value Proposition Canvas feeds what you actually build.
When I teach new product owners about backlogs, I start with one. If you can't explain why each item matters to your customer, throw it out. In 20 years, this approach has never failed me. But what exactly is a backlog? Simply put, it's an ordered list of everything you might build for your product. Think new features, enhancements to existing features, defect fixes, technical work like architecture and security patches, even research and legal requirements. I like to say it this way. If it's in the backlog, we might do it. If it's not in the backlog, there's no chance we're doing it. The key word here is ordered. Your backlog puts the most important items at the top. You know, the stuff your customers need most right now. Everything else, well, it just kind of falls below that. And unlike a traditional to do list, your backlog is. It's always changing. It's evolving as you learn more about what your customers really need. And it should be a pretty short list with the most important items having the most clarity. There isn't much point in having a really well refined item that's at the bottom of the list where you may never get to it. Now, I want to pause here because I've mentioned the word feature a number of times, but I think it's important that we define it, that we give it more context as we describe the backlog. A feature is a specific piece of functionality that solves a real problem for your users and delivers clear value. You use features every day. Your phone unlocks when it sees your face, your car beeps when you're too close to another vehicle. And your microwave has a popcorn button that knows exactly how long to cook that bag of yummy goodness. Ew, gross. When it comes to features, as a product owner, you need to be crystal clear about two things. What problem each feature fixes, and how that feature helps your customers. So before building anything, write down the good things you think that will happen when people use the this feature. It's really your kind of best guess about the benefits. I would call it a benefit hypothesis. Then make a simple checklist of what the feature needs to do to be considered complete and useful. We would call that acceptance criteria. Let's look at an example for taskflow. We know that our customers need to deliver projects on time and within budget. From that, we might create a schedule predictor feature. So our feature title is Schedule Predictor. Well, what good things do we think will happen when people use this feature? Maybe our benefit hypothesis is when teams use this feature, they'll finish more project on time and within budget. And then we have a set of acceptance criteria like the tool looks at teams, past work, speed and patterns to predict when the current project will actually finish, shows a clear likely finish date that updates automatically when things change, sends an alert when the predicted finish date is more than five days later than the planned date, and lets users click on the prediction to see what data was used to make it. So you would do this for each feature that you have in your backlog. Each one would have a title, benefit hypothesis, and some acceptance criteria. Let's connect this back to the Value Proposition canvas that you created earlier. Your canvas is actually a goldmine for identifying features. Here's how. Look at the customer jobs side of your canvas. Each major job your customers are trying to accomplish is a potential feature for taskflow. One key customer job was delivering projects on time and within budget. That's where I got the idea for the schedule predictor feature I just described. The Panes section of your canvas is especially valuable if you each significant pain point can translate into a feature that solves that particular problem. Some pain points taskflow customers identified included inaccurate project estimates leading to missed deadlines. We might wanna prioritize a feature around historical performance analytics. And in the gains section, the desired outcomes often translate into innovative features. Maybe the canvas showed customers wanted confidence in client presentations. Well, we might develop a Project Health Dashboard feature for that. I think you'll find it's pretty easy to start a backlog. Heck, you probably already have some ideas that need to get added in there. I have ideas, thoughts, the best thoughts. But if you find yourself getting stuck, I've got a powerful tool for you right here in your digital workbook as well as below this lesson called the six Ways to Innovate from the Customer Profile. Think of it as different lenses to look at your customer needs. You'll find six approaches in the tool, and it's worth keeping handy whenever you're brainstorming new work for the backlog. Your backlog isn't just a list, and it's your promise to build things that actually matter for your customers. Keep it ordered, keep it lean, and never add anything unless you can explain why your customers need it.
