The Responsibilities of a Successful Product Owner
Every software project begins with a vision. Now, that vision could be based on a gap identiﬁed in the market or a pain point that is felt within your business. Often, the success stories that become embedded within our everyday lives (Uber, Airbnb, Xero) focus on the big vision. What we aren’t told about is the hundreds (possibly thousands) of small decisions made by a product owner that determined whether the software succeeded. This article will focus on the role of the product owner and the commitment required to perform the position.
Firstly, it’s important to draw a distinction between the product owner and the business owner. In some cases these two roles may be performed by the same person. But they are two distinctly different roles. Where the business owner focuses on ﬁnancial and growth metrics, the product owner is solely focused on the product.
It is critical that the product owner is a single person. If there’s one point you take away from this article, let it be that. While there may be many stakeholders or collaborators involved in the project, there needs to be a single voice that distils stakeholders feedback and instructs the development team. The role of the product owner is a near full-time role. If you’re considering starting a software project and already perform the business owner role, consider whether you have the time available to also be the product owner. We’ll outline below the responsibilities and time commitment required at each stage.
Product Owner Role Description
The key role is to ensure that items being delivered are providing maximum value possible to the organisation. This means having an intimate knowledge of the product backlog and the organisations goals. A great product owner will almost become a part of the team, their success is highly tied to the success of the development team.
While it’s important to be that liaison within the organisation, it’s equally important to understand the needs of the end users. Before you begin building the product, this means setting up interviews and having those conversations with users. It’s important to ensure you’re acutely across the challenges they are facing and how your product can help them. Once the product is released, this means monitoring the analytics/usage of the application and measuring its value.
The responsibilities and commitment required from a product owner does change based on the stage of the product. We’ll break down the stages as they’re outlined in the Way of Working.
The primary responsibility of the product owner during the Brief stage is to validate the problem statement with the target audience. This means ensuring that the software built is seeking to address a pain point, and a number of people experience that pain point. A product owner should be looking to dedicate 1-2 days to this.
During the engagement with WorkingMouse (or another development company), the product owner is expected to attend the Brief meeting as well as a review session. During these meetings, the product owners experience within the industry and knowledge of the organisations goals and objectives are critical to developing the problem statement and the success criteria. This generally requires a 3 hour commitment.
During Scoping, the product owner is expected to attend every scoping meeting. It is critically important for them to be present to give feedback and help guide the product success team. In addition, they are responsible for connecting the team to users for interviews. The time a product owner generally spends with WorkingMouse during scope is 5 hours per week. This lasts for 2-4 weeks (depending on the Scope length).
Outside of the time directly spent with WorkingMouse, a product owner is expected to communicate and facilitate with other stakeholders within the business. As mentioned above, it is important to have a single voice to make decisions. But it is equally important to understand that within an organisation a product impacts many other areas, whether it be at a C-suite level or employees expected to use the software. So, the product owner must dedicate time to communicating with other stakeholders, distilling the information and presenting the most relevant ﬁndings to the development team.
Tough questions are asked during the project scope. The product owner should be prepared to answer these difﬁcult questions to feed into the design and development of the product.
As the project proceeds into development, the product owner is expected to be the consistent attendee to all scrum ceremonies (planning, review and UATs). These are on average a 4-5 hour commitment every fortnight. UATs should be completed in either a dedicated session or by allowing 2-3 hours each fortnight.
Perhaps the most important responsibility during development is to champion the backlog. As with any agile software project, priorities change as you make learnings. It is the product owners responsibility to ensure that the backlog represents current priorities and as such is an accurate reﬂection of your plans for the product. If there is a pain point that is especially time-sensitive, ensure that is communicated to the squad lead and modify the roadmap/backlog accordingly.
Additional responsibilities include:
- Follow up on action items coming from meetings and discussions.
- Respond as promptly as possible to squad lead/developer requests - generally these are blockers and could result in lost time for your project.
- Ensure all stakeholders are updated on progress and decision points, the development team treats you as the source of truth.
As the product is released and transitions into support, the product owner’s responsibilities change. Rather than working intimately with the development team, they are instead working closely with users. When the product can be tested in the market or within the organisation, we maximise the amount of learnings that can be made. It is the duty of the product owner to document these learnings to feed back into future development.
The primary responsibility is to log and monitor any issues or enhancements through the service desk. It is important to give the support team as much information as possible when dealing with bugs so they can replicate and ﬁx any edge cases that have been found. We believe it’s important to provide training on how to log a well-documented support ticket. If the support team have queries about replicating the bug, it’s important for the product owner to be available to handle these.
It is also necessary to conduct user acceptance tests and follow the same release process during support. As a result, many of the responsibilities from development carry over into support.
- Ensure there is only 1 product owner,
- Treat it like a full-time position,
- Develop a strong relationship with the development team,
- Upskill where needed.