In all large software projects there are multiple people involved: programmers, user experience experts, front-end designers and project managers (aka software developers). All these people play an important part in bringing a successful product from concept to launch.
All of these team members are important, but there is one member of the team that is essential for success, a role that is important to not overlook. That is the role of product owner.
Who is a product owner
It is key to identify the product owner at the start of the project and it is essential to identify the correct person to take that role. A product owner is someone who is empowered to make decisions on:
- Product direction
- Project budget
Deciding product direction means making decisions on what features are important and when the feature is “done”. Decisions that affect project budget are things like increasing scope (and accepting the increase to the budget), deciding on the best way to implement a feature with relation to cost.
Product owners play an essential role and have important responsibilities during a project.
Product owner responsibilities
Setting Priorities
It’s a strange thing, of all the projects that I have been involved with, there are always more features to implement than available budget. From projects of one week in duration to fifty, the nature of software development means that the number of features can always expand to fill the extra time given to developers.
Because of this, one of the most important responsibilities that a product owner has during a project is setting priorities of the backlog. Correct priorities are essential to ensure that the most important features are developed before working on less important features.
Tools like Pivotal Tracker make the act of setting story priority less painful by allowing you to drag stories around to sort them visually*.
*The most important stories sitting on top of the backlog, the least important at the bottom.
Decide whether features are “Worth it”
When starting out on a project, one of the first things we do at reinteractive is to break down a set of features into smaller feature stories. We then provide a points estimate to gauge how much effort we believe the feature will take to implement. At this point it is important for the product owner to look at each of the points estimates and consider “is this story worth it?”. If the answer is “no” then there is an opportunity to descope the feature or to explore simpler alternatives with the developer.
Be aware of velocity vs backlog vs budget
There are many reasons why it is difficult to predict the total duration of a software build. Each project has different outside influences, requirements change and surprises are revealed. We’ve found that the best way to measure progress is to calculate the project team’s velocity and compare it to the size of the project backlog.
When the velocity and backlog do not match budget, something has to give. Either we can decrease project scope or increase budget. Neither is fun, but it is important for a product owner to monitor these important project metrics* on a regular basis to ensure they can make the necessary decisions earlier rather than later.
*The metrics are available from Pivotal Tracker and similar tools.
Be responsive to developer requests
During the software development process, a software developer is converting ideas into product features. Often these features have many edge cases that are difficult to spot before development starts.
To decide the correct way to address edge cases, the software developer needs to either get clarifications from the product owner or they can make guesses. If the software developer guesses, sometimes they will guess wrong. This leads to wasted time performing rework. If the software developer has to wait hours for answers to their questions, the result is wasted time for the developer.
Timely action is also important when features need material from the product owner to complete a task, e.g. the copy for an email template, or maybe some company logo images. Other times the developer will need access to new individuals or sign-off on a design. Again, if the developer has to wait days to get access to those things, it can lead to inefficiencies.
The less time spent waiting on answers and rework means more time being productive.
Test stories rapidly to accept/reject
When a feature is delivered for acceptance testing, the sooner the product owner can review it the better. There are many reasons, but two big ones are:
- The sooner a feature is rejected, the quicker the developer can return to working on that feature. This means the feature will be fresh in their mind and easier to work on.
- Delivered features awaiting review is project scope that is hidden from view. Like an Iceberg that could potentially disrupt smooth sailing in your project, it is difficult to see how much potential effort is hidden beneath the surface from yet-to-be-rejected stories. The sooner the stories are accepted or rejected, the sooner you have clarity on project scope, which is essential for planning.
Be communicating with your end users (and facilitating communications)
The product owner is the representative of end user requirements. It is important for the product owner to be communicating well with their end users to make sure the product is going to satisfy their needs. Ideally the product owner can spend lots of time working with the end users to get the feedback on the product as it is developed and can facilitate sessions between the development team and the end users.
Give positive feedback to motivate
As the product owner it can be easy to fall into the trap of just giving feedback on things that need changing/fixing, but positive feedback is important as well!
The importance of positive feedback on the development team’s morale shouldn’t be overlooked, as telling the team when and where they have done a good job will boost morale and productivity. It will also help with other communication as people have a tendency to reduce communication with those who only have negative things to say.
To summarise: Communicate!
A lot of the above responsibilities of the product owner revolve around good communication. Communicate requirements, communicate priorities, communicate story acceptance, communicate with your end users.
Communication on a project is essential to a projects success. It is important not to expect a project team to work in isolation from the product owner, and it is important for the product owner to be highly involved in the project from start to finish.
So if you are starting a new project or in the middle of a project, make sure you have identified the product owner and that they are part of the day to day activities of your project.
