One key characteristic of great Product Owners is that they help remove dependencies whenever the team encounters them.
Dependencies can show up in many different forms. Our team may need some code from another team in our company, but the other team hasn’t yet built it for us. Or one feature that we may have to build has a dependency on another feature that needs to be built first. Product Owners have to take these kinds of details into account because they are the ones responsible for defining the next pieces of work to be done and that work has to be ready to be consumed, which means that all dependencies have to be resolved by the time it goes into iteration.
In many ways I think of this as a management role that I take on as the Product Owner but the Product Owner’s responsibilities are more to remove technical dependencies whereas the ScrumMaster’s responsibilities are more about removing team impediments that relate to physical dependencies.
The ScrumMaster, for example, would be more responsible for helping a team member get a needed computer to do their work or office space to work in, whereas a Product Owner might be more focused on helping a team member resolve an internal or product dependency.
Some Product Owners are technical and can help team members with dependencies on libraries and frameworks. Other Product Owners are non-technical and can help team members understand their user’s needs more fully and more clearly. It’s not uncommon for different parts of the system to have different levels of dependencies and identifying these upfront can often help us resolve issues more quickly.
I like to say that my job as a Product Owner is to remove dependencies for the team and get out of their way. Good teams operate just fine on their own as long as they have the information and tools they need to do their jobs. My job as a Product Owner is to get them that information and tools and then let them do their jobs.
The role of Product Owner often doesn’t require the prerequisite of having been a software developer but I find that software developers can make excellent Product Owners because they understand the needs of developers and so are able to more directly address them.
Being the Product Owner on a product that people use is kind of like being the writer of a famous screenplay. You get to be the puppet master. You define the rules of the game. Before the implementation or even the design, you get to provide the context.
A good Product Owner is the product champion. They understand WHAT the product is, WHO wants it and WHY it is wanted. They understand their product and are able to convey that understanding to the team.
A simple but highly effective way of building software is to start with the most valuable features to the user because this allows us to focus our attention on the things that are most important first. However, some features depend on other features and in situations like that, we have to have a strategy for building those features in such a way that is most efficient and effective. The shortest distance between two points is not always a straight line. Sometimes it makes sense to provide services that other features can use but more often than not it’s more efficient and effective to start by fulfilling a single need and then later redesign a service to be more general purpose.
When building software developers sometimes get lost in all the details so having a Product Owner who holds the vision and keeps the big picture in mind can be helpful for developers. Holding the product vision and making sure the team has everything they need to do their work effectively are vital parts of a Product Owner’s job.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Product Owners.
Previous Post: « Answer Questions Quickly
Next Post: Support Refactoring »