Four Things Every Product Owner Needs

by Allan Kelly

To be a successful product owner you need four things. Unfortunately, you can't buy these four things in any shop.

First you need the skills to do the role - it helps to have experience but everyone has to start somewhere. So while experience helps, you can acquire it. Obviously the first set of skills you need concerns your particular brand of agile development. For scrum that means planning meetings, stand-ups, retrospectives, working with scrum masters, and so on. 

Then, you need to understand stories (probably user stories and epics), backlogs, prioritisation, and story splitting. Hopefully you want to add acceptance criteria and behaviour driven development to that list. A smattering of planning and forecasting skills will come in handy too.

A 2-day product owner course will start you on that path but that really is just the start. Nothing I've mentioned so far equips you to know what to write on the stories or how to decide priorities. Finding out what these things are is what I call "homework." It is essential but few of the books on scrum describe it, as those books stick to what the product owner does with the team in scrum.

Knowing what to put on stories means the product owner needs more skills. For product owners working an internal initiative or creating a product for one specific customer, that problem means the skills held by a traditional business analyst. Product owners creating products for sale to multiple customers (whether to enterprise customers or a mass-market website) need the skills of product managers.

Now before I go too far let me point out there are group of product owners who I call "backlog administrators". Such product owners don't decide what to build, they merely choose items from the backlog and push them through development. Such people are closer to project managers of old. This misses the whole point: product owners are primarily concerned with the "what." The "when" is given since business deadlines and sprint routines provide them. It is all a question of "what will add the most value in the time we have."

The list of skills could go on: working with the team, inter-personal skills, entrepreneurship, domain knowledge, business acumen to name a few. What would you add?

The second thing a product owner needs is authority: at the very least they need to be able to walk into a planning meeting and set out the items to be delivered in two weeks time. If others are constantly questioning the product owner or changing the priorities, it may be a sign that the PO doesn't have the necessary authority in the organization.

However, such problems might be a sign that the third thing is missing: legitimacy. It is not enough for the organization to give authority to the PO, the PO must be seen as the right person to make the choices. If they are not seen as the right person they will not command respect, they may ask for things and find others don't follow through.

It is important to recognise that authority and legitimacy are different things. One can be given authority but one must earn legitimacy. When one or the other is missing it becomes hard for the product owner to get things done. And when a product owner cannot get anything done, they cease to be effective. 

Finally, the fourth thing every product owner needs is time. Time to do the job. Not just time to write stories, attend planning meetings and work with the team - although that is all time consuming. They need time to do the homework too - visiting customers soaks up lots of time. Analysing sales reports, reviewing market research or dissecting webstats needs dedicated time. Squeezing analysis in between calls leads to half-baked result.

On top of that product owners are people to, people with homes and families. People who need time to switch off and relax too. There is a history of agile product owners suffering burn-out.

When product owners lack the time to do their homework they arrive at planning meetings ill-prepared. Opinion and guesses substitute for facts and reasoning, and over time legitimacy is undermined.

So, ask yourself: do you have the skills, authority, legitimacy, and time to fill the product owner role effectively?

About the Author

Allan Kelly still considers himself a software engineer—even if nobody pays him to code any more. Deciding what to build, understanding customer needs, designing the software, and organizing the processes are all part of software engineering to him. He helps companies and teams undertake software engineering using agile techniques working as a consultant, coach, or manager. Most of his clients are small innovative companies few people have heard of. His better known clients include Virgin Atlantic, Qualcomm, The Bank of England, Reed Elsevier, and Swift. Allan has pioneered techniques such as Value Poker, Time-Value Profiles and Retrospective Dialogue Sheets. He is the author of the perennial essay "Dear Customer, the Truth about IT" and a number of earlier books including Continuous Digital, A Little Book of Requirements and User Stories, Xanpan, and Business Patterns for Software Developers.

This article was contributed by Allan Kelly, author of The Art of Agile Product Ownership.