top of page

Hats of a Product Owner


Product Owner Responsibilities

What would you say you do here?


The roles and responsibilities of a Product Owner are significant. Reflecting on and improving upon the skills to support PO duties are essential to the success of the role and the entire product team.



There are many “hats” required by a Product Owner but these are the most important from my experience:


  1. Facilitating conversations and transparency

  2. Focusing the team on the right work

  3. Modeling respect to foster a productive culture

  4. Coaching team on growth mindset & failure as a tool

  5. Asking questions to find the most potential value to add


Knowing Scrum is only part of the job


Some of the roles may seem like common sense or basic logic but a bit of finesse and human skills are required in addition to the hard skills of knowing the Scrum methodology.


The first step for any Product Owner is to get buy-in from their team on the vision for their product. If a strong foundation is not built, the relationships on the team will suffer as will the work. You can’t build a beautiful house without a strong base. As a PO, creating and developing great relationships with your team and all of your stakeholders will make wearing all the hats much easier.


Facilitating conversations and transparency


A user story is a placeholder for a conversation, and the Product Owner owns the backlog of stories. This doesn’t mean the PO does all the talking but is encouraging everyone to talk, share and think out loud together.


It may seem easy to bring everyone to a meeting but getting everyone to talk, especially virtually, is like forcing a horse to drink.


The PO needs to create an atmosphere where conversations and trust feel natural. Meetings should feel less like a burden or distraction from work but warm and inclusive. There is no one way to do this or a manual to follow. Being open and using a friendly vocabulary are a good start to building rapport and relationships that will lead to transparency.


Focusing the team on the right work


Most Product Owners inherit a backlog of work or can easily elicit requirements for projects that have been discussed for years. There is no shortage of work. The problem is what work to do first.


The most important part of owning the backlog is prioritizing it so the team knows what to focus on next. If the backlog is not regularly, weekly or sometimes daily reviewed, invalid work is more likely to be taking up space in the backlog or even worse, might get implemented.


Throw away work is horrible but not knowing what the team is going to work on is a bigger problem. The PO needs to clearly communicate the strategy or vision for each release/sprint/project. This requires knowing what work is most valuable to your stakeholders and sharing the WHY with the team. When a team understands not just WHAT they are doing but WHY it matters, the quality will always improve.


Modeling respect to foster a productive culture


It’s normal for all teams to have tension and perhaps even conflict as different roles have different perspectives. The variety of opinions should be encouraged and that means being respectful and accepting of them.


The Product Owner needs to model respect and encourage “productive and positive” feedback from the team not just during retrospectives but in all ceremonies or meetings.

The respect shouldn’t be exclusive to the team. The PO should model respect for all stakeholders and foster positive connections between all groups.


Coaching team on growth mindset & failure as a tool


If this sounds like the Product Owner is acting like a life coach, you aren’t wrong. The basic premise is that you can’t have long term success if you have a fixed mindset because you will naturally limit yourself if you are fixed on something. Growth requires openness and then the sky’s the limit.


If you watch a child make a mistake or fail, pay attention to how quickly they brush it off and try again. That’s the kind of reaction time you need to have and coach your team to have. Failure should be openly discussed just as wins and retrospectives should teach vs assign blame. Failure is not the end. Failure is the beginning of trying a new way.


Ask questions to find the most potential value to add


When you are trying to think critically you ask the five Whys, but getting clarity on needs shouldn’t be an interrogation but more like a Barbara Walters interview. Barbara was great at making her guest comfortable even if she didn’t ask the hard ball questions all the time. She kept them talking and that’s your job too.


The quality of your questions is important but even more so is when you ask and when to just let them keep sharing. Sometimes I have great questions that I write while they are talking so I don’t lose them but I don’t interrupt. The more they tell you the better your follow up question will be.


If you can’t think of any more questions, do the “mirroring exercise” of repeating what you believe you heard was the most important value needed to confirm. Then document it in a common vocabulary so it can easily be referenced by everyone later.


It’s tough...ask for help


Wearing all the hats and doing all the things can be overwhelming.

Evaluate yourself and determine what are your strengths and weaknesses. Who can you reach out to for help? What resources are available?


If you are lucky enough to have peer Product Owners, ask to sit in a couple of their meetings and observe how they interact with the team. Sometimes just sitting in a different space gives the meeting a whole new perspective.


Remember there is no one right way to wear all the hats but being mindful of each will help you stand out as an exceptional Product Owner.


Contact

AgileDad

109 Ambersweet Way 

Suite 130
Davenport, FL 33897

​​

Tel: 866-410-1616

Fax: 866-998-1919

LearnMore@AgileDad.com

  • Instagram
  • Linkedin
  • Youtube
  • Facebook
  • Twitter

Name *

Email *

Subject

Message

Thanks for submitting!

2024 AgileDad LLC  | Orlando, FL | Salt Lake City, UT |  Privacy  | Terms of Use  

 

bottom of page