Introduction
Product Owner is a widely recognized role in agile software development methodologies. In this article I'm going to tell you who a Product Owner is and how to become a better one. There will be practical tips and general advice. While the role is sometimes mistaken with the classic team lead position, Product Owner's job in general doesn't include as many responsibilities related to people management.
This article is a summary of what I've learned about a Product Owner role while working with one of my employers. It was written based on a series of interviews with other Product Owners, therefore it is an opinionated set of tips and suggestions. Contents of this article do not apply to every project at the but certainly can inspire you and educate you on general responsibilities of a Product Owner in a software services environment.
I'm going to use a PO acronym for Product Owner from now on.
I've collected this set of thoughts in order to pass the experience of being a PO to new and existing work colleagues but I'm sure an online community can benefit from it as well. I've been in the role multiple times and got a lot of feedback. It's time to share.
Disclaimer: Product Owner role described here is not a direct implementation of Scrum Product Owner. The tips are targeted but not exclusive to service-type work. I do not hold any Scrum certificate.
Let's start with some definitions. Most of the publications agree on the following statement about the role.
A (Scrum) Product Owner is accountable for maximizing the value of the product resulting from the work of the (Scrum) Team. How this is done may vary widely across organizations, (Scrum) Teams, and individuals.
~ scrum.org
The multifaceted nature of the role is also widely acknowledged.
But to do this, an agile product owner takes on several roles, including business strategist, product designer, market analyst, customer liaison, and project manager. In short, agile product owners are an integral part of any scrum team.
~lucidchart
The variety of responsibilities usually causes new POs to be lost. The struggle to balance interests of customers, management and development team is real. They have to deliver product increments on typically tight schedule. When communicating with everyone they have to stay assertive while having a limited decision-making power.
Considering the above, candidates for the PO role are expected to be experts in the field and possess strong domain knowledge accompanied with maturity in communication and willingness to learn the new responsibilities.
Who is a Product Owner?
I have held multiple conversations with other Product Owners and asked "who is a PO? what does she do?". There were too many answers to try to make a coherent block of text out of them.
- responsible one
- contact person
- team lead
- business analyst
- psychologist
- coach
- development team member
- proxy
- developer / scientist
- user perpective in mind
- converts wishes into actionable items
- maximizes value
- requirement collection
- martyr
- not a tester - but defines testing criteria
That's a lot.
Let's try to have a look at the role from four different perspectives: company's, team's, client's and a technical one.
From a company perspective Product Owner is someone who leads the contract. She is responsible for backlog and minds the definition of done. At the company I use as a case study for the article, in smaller projects, at least 20% of person's time spent should be spent on the role if one also maintains heavy technical engagement. Ideally one person should "own" one product.
From a team perspective, PO is the guide on the path forward. This is viewed by many as the toughest part of the job. She should also be a servant, catering to team's needs. PO usually is also responsive for team composition. She decides who's needed to successfully deliver the product. Teams usually expect POs to be scribes, maintaining notes from relevant meetings. POs are not supposed to micromanage but maintain functional product backlog. She doesn't have to know every single detail. PO should have a vision for the product, not the project. She should be a proxy and minimize organizational overhead for the development team.
Clients expect POs to be their point of contact, the responsible one. PO is their proxy, understands them and cares for the success of their project. Additionally, PO negotiates features with customers when a budget is limited (which is always). Product Owner should also coach inexperienced clients in software development methodology in order for them to understand consequences of certain design choices.
At this particular employer, leadership role candidates are sourced from individuals with higher competence levels. That said, good leadership doesn't come with expertise and requires additional knowledge and experience. From the technical perspective, PO should follow the company's SDLC (Software Development Lifecycle) or a set of standard practices in the absence of one. POs are advised to apply Continous Testing - "we think project goes smoothly because we don't test, we don't test because we don't want to know it's bad". Lastly, Product Owner should facilitate smooth and constant deliveries.
Other responsibilities of a Product Owner include:
- Risk management
- Converting stories into tasks
- Have a responsibility when it becomes blurred
- Maintain less than X backlog items (100 was pointed out as a good number)
PO in the project lifecycle
Product Owner should be present in the process from the beginning of the project development process. A typical process includes:
- Pre-sales
- Sales
- Picking a team
- Project development
- Support
- Sales
Presence of PO at different stages is debatable and is highly dependent on a company structure. It is however a consensus that every employee sells mostly indirectly by execution of their job and maintaining contact with clients.
On every of those stages one should remember a truth repeated numerously in the interviews I conducted:
BACKLOG is THE tool of PO
As a Product Owner, you should be aware of the key points of concern in Software Development Lifecycle, agile processes and your role in them. I have tips for some of the meeting types you're going to take part in.
Kickoff meeting
Here are key tips:
- send an agenda before the meeting
- state what is the purpose of the meeting
- introduce the team
- go over the scope
- organisational items: status meetings, communication channels, work result sharing, task management, resource access
- leave an opening for their ideas for the meeting
- propose several dates
Planning
The goal is to specify the value increment that will be developed in the next Sprint.
- Remind near and long term goals and priorities to the team
- Split the tasks into ones fitting in one sprint
- Don't get into details
- All attendees engaged
- TIMESLOT - respect it, productivity sharply decreases after one hour
Status meetings
By status meeting I mean a catchup with a client.
- start with a light topic
- form - not that important
- no need to prepare perfect slides everytime
- stick to a fixed agendas
- send summaries
- whole team not necessary
General meeting tips
- be prepared
- be the first one
- stick to the defined time slots
- ask for any additional time limitations
- some small talk is okay
- include client's logo in materials
- don't ask unprepared people for things you think they're not ready for, especially with bigger audience
- be yourself / human
Cultural differences
Keep those in mind. In the international setting, people are usually educated in intercultural communication or at least accustomed to it, so they will adjust their social behaviours to you. But it should work both ways. If you're starting a project with a client from a cultural or regional background you know little about, do some light reading.
If you're really into it, check out Hofstede Dimensions.
Closing thoughts
First time as a product owner can be stressful. But as long as you're sensible and communicate what you really mean you should be fine. We're all human.
Don't be afraid to ask for help. Your manager and business developers will likely help you with anything client contact related. And tech leaders are there for you to reach out and consult larger technical decisions. Use your environment to your advantage.
Discussion
If you have any insights, please share them below and let's have a conversation.
Cover photo by fauxels from Pexels
