Untold Stories

The Product Owner role is a challenging one to understand. I often hear people describe this position as the Scrum equivalent of a Business Analyst. This may be in part due to the established relationship between requirements and stories.

 

These roles are not the same. Product Owners are responsible for ensuring all features proposed fit with the overall product strategy. Meanwhile, Business Analysts propose requirements without necessarily taking the wider roadmap into account. The Product Owner role, as defined in The Scrum Guide, is responsible for the product backlog. The word owner highlights a level of accountability that an analyst does not possess.

 

Beware of some of the traps I’ve found with Product Owner

 

Confusing these roles is hampering the building of our software. I’ve seen first hand that we are struggling to identify suitable candidates on which to instil the honour of Product Owner. Here I discuss some of the traps triggered when identifying Product Owners, and the characteristics that people need to succeed in this role.

 

Cluster One

 

One common challenge faced by many of our teams is having a dedicated Product Owner. Historically, we have selected representatives from our client base to fill this seat. The typical profile has been a lead in that particular area with significant knowledge of current processes.

 

The key struggle we have with our Product Owner strategy is their lack of dedicated time. They have a day job that takes priority. When the going gets tough at work, their Product Owner responsibilities are the first thing that is dropped. This leaves development teams struggling to get the support they require on both ongoing development items and upcoming prioritisation.

 

It is important that the Product Owner and development team work together to build out these features. To guarantee development teams receive the support they need, and vice versa, Product Ownership must be a full time job. Only by having one person continually dedicated to the cause will ownership be guaranteed.

 

Missing Pieces

 

Another difficulty with the parallel role is that their expertise may apply to one small segment of a larger process. The expertise of our nominated team leads has proven to be immensely valuable in the identification of new features. Nevertheless, they are unlikely to know the intricacies of the next stage once they have handed over their output to the next team in the chain.

 

Choosing someone previously responsible for part of the puzzle introduces a level of bias. They often provide stories directly related to their role. Furthermore, they can miss proposing the enhancements that will benefit downstream stages, which also require representation.

 

Product Owners own the entire process puzzle, rather than just a single piece

 

Elimination of these predilections is important to obtain a holistic view. Through story identification, we can recommend process optimisations to identify the client’s true needs and remove manual stages. A dedicated Product Owner will be more likely to propose such enhancements.

 

I’m So Curious

 

Understanding of business process is vital to being an effective Product Owner. Starting with a complete comprehension of the business domain can introduce complacency.

 

Processes evolve over time. The funding process that I’ve come to know over the past few years has evolved. I’ll be the first to admit that keeping up to date with these changes can be a struggle. The knowledge I gained when I first joined the team remains useful. However, to provide useful solutions to our users, I must keep asking questions. A level of smugness can kick in if Product Owners don’t keep probing procedures at every stage.

 

Techniques such as User Story mapping can help Product Owners to ask the right questions

 

Effective Product Owners must be curious. They need to have the initiative to ask both the obvious and obscure questions. These techniques can be used in conjunction with user story mapping techniques to extract key features. This ensures that when developers ask the same questions when building these features, they are able to obtain the answers they need.

 

That’s How People Grow

 

Product Ownership is a massively underrated role in some regards. Part of the reason we struggle to attract full time collaboration by curious individuals is it doesn’t receive the recognition it deserves. Like any role, to attract strong candidates we need to show their work will be appreciated.

 

Organisations should ensure there is a career pathway for all role types, including Product Owner. The ability to manage a backlog and support development teams is not a trivial task. The best candidates don’t have to come from a business background. Strong technical individuals able to facilitate with users will make for excellent Product Owners if they see the role has growing space.

 

Product Owner is a superhero role that deserves more respect than it often earns

 

Adhering to the guidance outlined in this article will reduce the chance of encountering these pitfalls. Stop seeing Product Ownership as a secondary role. For people to aspire to be Product Owners, it needs to be seen as a viable role where colleagues will receive recognition, and be able to progress.

 

Thanks for reading!