7 Mistakes to avoid as a Product Owner

What do Product owner do?
They work to keep stakeholders, customers, and users happy. 
They do market research and examine data to help keep the product on the right course.
Product Owners work closely with team members and make themselves available to answer questions about work in the current sprint. 
And they ensure the team has a steady stream of new user stories for future sprints.
To be effective in their role, Product Owners need to avoid 7 costly mistakes.

Mistake #1. Product Owners introduce changes in the Sprint


All Product Owners tell the development team that what they work on will not change after a sprint has been planned. But that’s a hard promise to keep when customers and stakeholders change their minds or come up with new needs.

At some point, every Product Owner is tempted to make the mistake of bringing changes into a sprint rather than waiting for the start of the next. 

And you know what? In some cases, that’s OK. Some changes are very important and worth interrupting a sprint. But many others are not. Product Owners need to avoid the temptation to interrupt a sprint with something that only feels urgent because stakeholders are making noise about it. 

Product Owners can guard against these interruptions by soliciting the help of their Scrum Masters, letting them know it’s OK to push back any time they ask to bring something new into a sprint that's already in process. Most Scrum Masters know they should do this, but sometimes they’re afraid of pushing back. Let them know it’s OK.

Product Owners can include these new ideas in the Product Backlog and bring them up during the next Sprint Planning meeting. 


Mistake #2. Product Owners do not attend Sprint Meetings

While the Scrum Guide says it’s not mandatory for Product Owners to attend daily scrum meetings, the best Product Owners make every effort to participate whenever possible.
The Product Owner's presence can ensure that the team continues to work towards their Sprint goal.
 
Similarly, some Product Owners don’t attend Sprint Retrospectives. Or, just as bad, their teams don’t invite them. A Product Owner's participation in the Sprint Retrospective demonstrates an openness to improve and encourages team members to improve as well.

A Product Owner is part of the overall Scrum team. 

Make a commitment to avoid the mistake of skipping sprint meetings.


Mistake #3. Product Owners tell WHAT, and also HOW

Product Owners are tasked with telling the team what they need to build. A good Product owner will also share the product roadmap and continuously engage the team in Backlog Refinement meetings to ensure the team has clarity on the requirements. It’s the developers’ job to figure out how to fulfill that request. 
Suppose your company plans to implement a system to ease conference room bookings. You tell the team that’s what you want. They decide the best way to do that. Perhaps it’s with an App which will provide current booking status or an Outlook Calendar plugin which prompts availability of conference rooms.   
You can avoid the mistake of telling the team how by ensuring that you have shared the overall goal and the client expectations from each product backlog item. Refrain from going further and also telling how you want the team to fulfill the expectations. Product Owners, who have been developers in the past, may find it difficult to avoid this mistake.  

Mistake #4. Product Owners do not say NO, often

Product Owners set a product vision that will result in a product or solution that makes people happy. Product Owners need to remember that the Stakeholder happiness has to be achieved through the delivery of the right product.  Building the right product always takes precedence.
Product Owners need to remember that making people happy is not as important as building the right thing. Hence, every request they say Yes to, may mean saying No to some other item. In other words, they need to avoid the mistake of not saying No often enough. A hidden problem of saying Yes to too much is that it might mean saying No later to an essential, emergent requirement that just hasn't been recognized yet.
You need to be careful in how far ahead you commit what a team will work on. And remember that it's in the best interest of the final product sometimes to say no.

Mistake #5. Product Owners prioritize short-term goals

Good Product Owners set slightly longer-term product goals that they use to help them prioritize, whether that's through a formal product roadmap or some other mechanism. In doing so, they avoid the mistake of going from sprint to sprint always pursuing what is most important at the start of the sprint.

I recommend setting quarterly product goals. A 3-month horizon provides a good balance between a long-term goal and one that feels achievable. Additionally, a 3-month goal is one against which a team can notice progress. 

Mistake #6. Product Owners do not have authority to do the job well


Product Owners need to make quick decisions so they don't slow the development process down. They also need to know that these decisions won't later be reversed by their boss, or some other higher-up in the organization. When a Product Owner is overruled routinely, team members quickly learn to think of all decisions as tentative. 

A Product Owner who is lacking authority needs to have a conversation with the overruling party. To structure that conversation, prepare by writing down the various Product Owner responsibilities. Write things like: 

  • Prioritize the backlog
  • Determine release dates
  • Provide feedback on implemented features
  • And so on

Then collaboratively discuss the RACI matrix for each of these responsibilities with the higher level of management. Achieving this clarity of your responsibilities will often result in gaining more of the authority you need to fully succeed as a Product Owner.



Mistake #7. Product Owners do not like feedback

Product Owners need to keep an open mind and truly listen to feedback. Too many Product Owners make the mistake of getting overly attached to their vision and ignore feedback. They need instead to listen to customers, users, stakeholders, and, yes, developers too.
They don’t need to do everything suggested. But good products become great when Product Owners listen to feedback. 



Coach Ram

www.coach-ram.in


Reference: Mountain Goat Software


Comments

Post a Comment

Popular

Science of Influence

One of the traits that Project Managers or any Leader needs to develop is the ability to influence. Every project ecosystem consists of Stakeholders, internal and external. These include your own team members. The ability of a Project Manager to influence these Stakeholders will ensure that the project is in control. Dr. Robert Cialdini has developed 7 principles of influence which can be used by Leaders to influence others. 1.  Reciprocity :  When you do people a favour, they tend to respond in a manner you want them to. However, there are some points to note. - I t’s not about what is given, but HOW AND WHEN IT IS GIVEN . Be the first to give the favour. - Let it be personalized and unexpected. Tell them ‘ I am doing this only for you ’. Suppose, you have done a favour to a person and he/she says ‘Thank you’. What is your response? Many of us say, ‘Its okay’, ‘It was my duty’ etc. Some rare person may say ‘Now you also owe me a favour’.  Instead use this principle Respo...
Read more

CONFLICTS in Teams - How to address them?

Conflict on teams is inevitable. But here’s the real question: does it need to be resolved? Not always. In fact, the type of conflict matters just as much as how you address it. Some conflicts demand immediate resolution, while others can be channelled into creativity and progress. Knowing the difference is critical to leading a team effectively. At its core, conflict on teams falls into two categories: personal conflict and task-focused conflict. Personal conflict is what most of us think of first—tensions that get personal, unkind remarks, or behaviours that erode respect. Left unaddressed, this type of conflict undermines trust and productivity. Task-focused conflict, however, is entirely different. This is the natural tension that arises from diverse ideas and perspectives. It’s not a problem to be solved; it’s a tool to be harnessed. Handled well, task-focused conflict can propel a team forward. Let’s look at both in depth—how to resolve personal conflict and how to channel ...
Read more

Application of Scrum Values

The essence of Scrum are the 5 values. A Scrum-Agile project will not be successful unless these values are demonstrated in every event, while preparing every artefact and while performing any role. In fact, these values can be demonstrated in any environment to reap benefits. Here are 10 practical instances for each Scrum value that any team can demonstrate: COMMITMENT Team members dedicate themselves to achieving the team's goals and doing their best work. They commit to the sprint goals and support each other in meeting those commitments. Team commits to delivering specific user stories in the sprint backlog, even when facing technical challenges or scope creep requests from stakeholders. Team members commit to rotating on-call duties to ensure continuous support for critical production systems across different time zones. When a legacy system needs modernization, team members commit to learning new frameworks or cloud technologies requ...
Read more