Remove Dependencies
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.
