Product Owner: the things they often don’t mention
Being a Product Owner: the things that are rarely mentioned
Having an effective Product Owner (PO) on software development projects is a hugely useful and important role, whether using Agile or other methods. The way the PO is described, especially by many promoting some Agile methods, is at best ambitious. In many circumstances, it may not even be close to possible. Pretending we have one when we don’t (by the measures below) is going to be a real challenge.
The purpose of this post is hopefully to help you decide whether you really have one or not. Pretending we do, when we don’t, is seldom going to end well.
Note: none of the following relates to “classroom” or “text-book theory”. It reflects real-world human behaviours and issues that are commonplace around projects. These challenges, if not recognised and properly overcome can wreck any project very easily.
The Product Owner Role (as commonly defined in Agile methods) | |
Product Owner Responsibilities: | Implications: |
| How it’s usually described | |
| Are accountable for a successful end-product. | In the most common Agile methods, the PO owns the definition of what is required and developers produce the product, but it is only the PO who is accountable for the success of the project (the "value it achieves"). The development team are only expected to 'collaborate'. This is optimistic and very convenient for all of those who are not the PO, including the Scrum Master, who is only responsible for facilitating the “process”. |
| Define the product vision. | This is a task many people are not skilled to do. Many who are asked to do this may never have done it before. |
| Describe required product features to development team. | Doing this well will take a good deal of time and requires the skillset to do this successfully. |
| Prioritise the product backlog. | Done properly, this is a heavy responsibility and will often require a good deal of time, via ongoing analysis and trade-offs. |
The bits rarely mentioned | |
| Communicate, as required, with all key stakeholders. | This is a hefty responsibility time-wise. |
| Resolve conflicts among stakeholder needs. | This can be very challenging, to the extent that people sometimes will ignore this challenge rather than confront it. It takes personal qualities of a particular kind to do this well and maintain momentum towards a successful project. That relies upon time to communicate well during this process and the skills and resolve to do this. |
| Conduct trade-off analysis as required (e.g. scope and schedule). | This one is very challenging. It frequently occurs around issues often with little or even zero notice. Two key questions occur: does the PO have the time to do this (well) and how many POs would or could do this, even with significant support from the team (who would normally be very busy delivering the current Sprint) . |
Attributes of successful POs | These are the bare minimum attributes: |
| One Person: Not a committee. | Committees can exist but the PO is the focal point for the team. All other stakeholders should make their representations via the PO. This places great responsibility on the PO and requires a significant commitment of time by the PO over the whole life of an Agile project. |
| Availability: No 1 attribute is that they must be available to the team, before and throughout the development process (iterations), for planned events and often at short notice. Many of the responsibilities described above carry a heavy commitment of time. | Some try and focus this availability around Sprint planning. This is unrealistic. Most iterations (e.g. Sprints) involve development of the detail feature requirements, within the iteration itself. The PO must be available to do this or coordinate with those who will do this. |
| Domain knowledge: They must be able to make decisions as quickly as possible over priorities and functionality. Having to refer to others constantly will hamper progress significantly. | This makes your choice of PO quite limited in many cases. |
| Authority: They must have authority to commit to decisions about the product, constantly. Those decisions must be respected by all other stakeholders. | They have to be able go make many decisions even on behalf of whole committees. They cannot constantly refer to others or progress will stall or even stop. |
Conclusion: Having a participative, knowledgeable PO with the authority and time to do all of the above is priceless on any project (whether using Agile or not). However, you have to ask yourself, on a case-by-case basis, do we realistically have one (with the substantial amount of time that will be required across all iterations). If there is any significant doubt around this question it could be very challenging to attempt to use Agile development methods or a team model based on Scrum alone. | |
Related pages:
If you agree with any of the above you may find the following pages useful:
Share this:
Contact Us Now
EMAIL us today.
Or call ++44 (0)1865 784040
Subscribe to Blog via Email
Enter your email to subscribe to our blog and get notifications of new posts by email. (We don't SPAM - ever.)