Sometimes product owners are not enough.

In the simplest of Agile situations a development team will have a product owner who makes decisions around prioritisation and who signs off each story. This is very effective for getting things done but, among other things, it does require the product owner to be able to make informed judgements about all pertinent aspects of the work.

In more complex situations this is more of a challenge. The team may have additional demands placed on it—for example, accessibility requirements, security, architecture, etc. Sometimes these are relatively straightforward to handle. One way might be to incorporate the requirements as stories which the product owner understands and accepts. For example, they may agree with the need for adequate performance testing and be happy to prioritise the stories that enable that. Another way is to just fold all that work into the general process so that it’s not up for debate. For example, the team may be expected to produce their work in line with the requirements of a software architect, and so they just do that as part of their daily activity.

But sometimes it’s not so easy.

For example, there may be specific security requirements which neither the product owner nor the team appreciate. If these take up time that the product owner and the team feel is better spent on other things then it can be a challenge to get that security work done. Or perhaps the project is delivering to one department but intended also as vehicle for a new technology infrastructure for future benefits to other departments. Introducing that new technology may again be seen as an unnecessary diversion for the product owner and the team. Even if they do implement it they may not implement it well for its future use.

In these situations the lone role of product owner is not enough. Two things need to happen. First, these additional requirements need to be part of the business case (or “value proposition” if you want to keep the focus on delivering value). Second, someone needs to represent those additional requirements at the same level as the product owner. They may be another product owner, or they may be a less formally defined influencer.

In either case they and the original product owner need to work together and respect each others’ goals and expertise. Additionally, if there are further layers of governance (perhaps a project board), then both parties need their areas represented there.

The message from all of this is that if there are multiple goals of a project build then those goals need to be represented at the build level, with multiple product owners or similar influencers, and those interests need to be represented equally up the tree. This ensures all the intended value of the work is realised, however diverse it is.

Photo by Julie Danielle