Should you have a Product Ownership function?

We caught up with Phil Osmond from PGO Product Consulting to gain his thoughts on building out a PO function and why it is important. Phil is a highly regarded PO and founder of Product Owner Lunch Club. Here is Part One of our interview:

If a Consultancy was considering building out a Product Owner function what advice would you have for them?

I always start by asking why. What problem are you trying to solve? What outcome do you want to achieve?

Some bad reasons for considering a product function include:

• everyone else has one
• the Scrum Guide says so!
• your engineers don’t want to manage their own backlog
• your team aren’t interested in the users or businesses cases
• you keep missing deadlines & delivering poor quality results 

But good reasons include:

• you have a product you want to invest in to help you serve your client(s)
• your client’s are asking you to build valuable products but they don’t have a suitable product owner
• you want to focus on outcome-driven development
• you realise you are building software in an emergent domain and no longer want to apply a deterministic mindset or principles. Instead you want to probe, sense and respond through incremental discovery & delivery of value

Software development and implementation is by nature emergent not deterministic. Your particular group of humans in this context have not used this particular combination of software before. Whilst there is much to learn from experience, if you continue to miss deadlines, overspend and deliver poor quality solutions there is much more to consider than merely hiring a PO!

Until you embrace an agile approach to breakdown and understand your problem domain, discover valuable solutions and test through incremental delivery with short feedback loops you’ll never get any real value from a product function. 

However if you are doing that and aspire to add real value to your client as a trusted partner then a product function will help you — and so can I!

Why is specific Product Ownership important? Couldn’t the responsibilities be given out amongst the team members or to a Scrum Master?

Let me start by saying, In cases where a client provides their own ‘product owner’ this is a moot point. Usually they’ll give your team the vision and goals to work towards as they seek to maximise the value they receive. In other cases they may benefit from coaching to help them — for their good and yours!  

But for teams who are not so fortunate, I believe a dedicated agency-side product lead can help you become your client’s trusted expert partner. They will help you build the right thing at the right time for the right people to maximise value. Value for your client, but also for yourself.

Building a product to enable this value exchange is the ideal sweet spot for product people. An experienced product leader will always seek to maximise the value delivered. This means preparing to invest in your product. Often it will mean going over and above simply fulfilling the brief!

This means there is someone on the team looking out for what the users need and translating that into value. Someone with a vision. Someone setting goals and expectations. Someone empowering the team to delight users by achieving beneficial outcomes. This is a highly accountable position, and one that requires expertise, time and experience. 

Give this careful thought before sharing this out across developers. Team ownership is necessary. The whole team does need to bear responsibility for what they build. But, do they have the skills? Do they have the capacity and knowledge to build the right at the right time for the right people to maximise value?  

But also let me ask — do you actually have a product? If you are an implementation partner integrating commercial off-the-shelf (COTS) software such as ERP or CRM solutions, it’s likely you may not. A specific product owner has little to offer your team if you don’t have a product. Instead you may have technical consultants who already seek to understand the client’s domain, needs and users, then translate this into an implementation.

In this context is it likely they currently act as the product owner. They are accountable for representing the goals of the user and shaping the backlog. They are accountable for ensuring implementation of a valuable solution! Here you may find an agile coach offers more value. They will help you avoid boiling the ocean and keep feedback loops short.

Resist saddling your scrum master or delivery manager with this accountability. They may be capable. They may want it! But — if they are accountable for team health and product health, which will they choose? It can lead to unhealthy (and unnecessary) tension.

With thanks to Phil Osmond from PGO Product Consulting http://www.pgoproductconsulting.co.uk/ for this informative guide. Watch out for the next installment which discusses the challenges faced without a PO, what Phil recommends you look for when hiring a PO and his views on the future of product ownership.

Coming out soon!

Agility on Demand have placed contract and permanent POs so please contact us to get information on salary/rate averages in your region.