Picking the right Product Owner

For a lot of our customers working with Made is their first exposure to Agile. As part of any project, we’ll ask them to nominate a Product Owner to work closely with us throughout. Picking the right person for the job can make or break the project – so how do you make sure you choose correctly?

Why can’t someone at Made be a Product Owner for us?

We believe the best software is built when the business side of things is working closely with the engineering team. Nominating a primary stakeholder is the best way of ensuring a good line of communication and therefore securing the best return on your investment. No-one at Made can understand your business as well as a member of your team. For us to try and gain such an understanding would add a lot of time and cost to a project, and would likely lead to inferior results.

What makes a perfect Product Owner?

Ideally you should appoint someone who has been with the company a little while and understands well how the business functions – but also knows your organisational dysfunctions. Once development starts we’ll look to progress at a very rapid pace, so having someone on the inside able to get quick answers to questions is key to avoiding expensive project delays.

Someone who sticks to their guns, especially to other stakeholders; at the start of a sprint we spend a lot of time breaking stories down into technical tasks in order to deliver them in the most efficient way, as a shippable increment at the end of the sprint. Changes to a sprint halfway through are often unnecessary and whilst we’ll do our best to try and accommodate them, a Product Owner needs to understand that this is going to potentially push promised user stories out of the sprint.

Being a Product Owner is pretty time consuming, and we generally advise that they should be available to us at least 3-4 hours a day, if not full time. We’re probably not going to need all of that time, but having someone available to answer questions and help resolve issues as they arise will greatly accelerate the rate at which we can work.

A willingness to compromise is important; there’s no such thing as perfect software, but it’s easy to get hung up on small details trying to get everything ‘just right’. There’s an issue of diminishing returns here though. We will happily spend many hours moving a pixel here or there to make sure your responsive site looks great at every screen resolution if you want us to, but this is going to push other user stories down the backlog and potentially out of reach of your budget. Understanding where we can add the most value, right now, is the hardest job for a Product Owner.

We don’t expect someone who lives and breathes the Agile manifesto, many of us have worked on Agile teams for many years, so we don’t need you to be able to pick it up overnight. We strongly believe that Scrum gives the best results though, so for best results you should pick someone with a willingness to embrace something new, and work within the process rather than trying to subvert it.

About the Author