Welcome to the next installment of my blog series on Product Owner Anti-patterns that spell Doom. In this blog, I cover leadership. Being a Product Owner is inherently a leadership position. To be successful, Product Owners must navigate every level of an organization, from the Help Desk to the CEO. Here are a few issues with leadership that may cause a PO to fail:
No Leadership Skills
Problem
Let’s be honest. Not everyone is born to be a leader – nor can just anyone learn to be a leader. Becoming a leader involves earning the trust of stakeholders and inspiring others to adopt your vision.
Leaders also surround themselves with people who are smarter than they are – and if you have an ego, this can be a bitter pill to swallow.
As a leader, you should serve your team – not the other way around. Leaders also need to protect their people and, at the same time, not get in their way so that they can accomplish great things.
Being a leader is no easy feat – nor is being a Product Owner. The PO has the burden of being both.
Solution
Products Owners who act as “God” aren’t representing the voice of the customer or the wishes of their stakeholders. To be a successful Product Owner, you must cultivate leadership skills. Find a mentor. Read books. Take personality tests. Don’t think about yourself or your success – practice servant leadership and humility. If you do these things, you will gain your team’s trust, and to steal a phrase from Dr. Laura, your team will “swim through shark-infested waters to bring you a lemonade.”
Inability to Negotiate
Problem
There will always be competing needs from your stakeholders. Some will perceive that they win, and others will feel they lose. Product Owners who promise every stakeholder that their needs are rated priority #1 will soon discover that instead of making one group happy, no one is happy. Being unable to negotiate will severely hamper your ability to get anything done.
Solution
This will sound crude – but Product Owners need to “grow a pair.” In other words, as a PO, you must be able to negotiate with stakeholders who have different interests. The verb “negotiate” means:
“To deal or bargain with another or others, as in the preparation of a treaty or contract or in preliminaries to a business deal.”
Dictionary.com
Negotiation involves give-and-take between parties. Product Owners are responsible for delivering the highest value to their organization, which means someone will typically have to wait while other priority work is delivered.
Product Owners must objectively evaluate how value is measured and make appropriate decisions based on the facts. Then it would be best if you tactfully communicate so stakeholders understand why you made a decision.
If there is communication and transparency, a PO can maintain good relations with stakeholders, even if they aren’t getting what they want now.
Not thanking and celebrating the Scrum Team’s accomplishments
Problem
Have you ever been on a team where your work was never recognized or appreciated? I can tell you; it’s very demoralizing – especially if your team produced brilliant work. As a leader, the Product Owner can, and should, applaud the team’s accomplishments.
Sure, not every Sprint will be perfect or meet the Sprint Goal, but when the team realizes a goal or achieves something great, you should celebrate despite obstacles.
Solution
A celebration can be as simple as a word of thanks verbally communicated to the team, or it could be in the form of a small token of appreciation. You could even resurrect a long-lost art – written communications. A short note of thanks will engender gratitude and trust when sincerely delivered. I recently received a hand-written note in the mail from my company’s former CEO, along with a gift card. It wasn’t much, but it meant so much to me to recognize my efforts and contributions.
Inability to make Trade-offs
Problem
Making a trade-off is when you give something up to get something else. It will be a bitter disappointment for the Product Owner who wants it all and wants it now. A team can only accomplish so much per Sprint, and the PO must recognize that something else may not get done when someone adds new ideas or stories.
Solution
A good Product Owner understands that not everything in the backlog will be built. S/he must also recognize what is essential and what is not – this is a crucial Product Owner skill. Ideas that are more valuable than others may have to fall by the wayside; items that aren’t as valuable should naturally filter themselves to the bottom of the Product Backlog.
Directs the work rather than letting the Team decide what to do
Problem
In this case, the Product Owner may think that s/he is also a Project Manager. Traditional PMs typically control and direct their team’s work and are responsible for delivering the solution, but that is the opposite of what a Product Owner should do. If a PO chooses the work during Sprint Planning and tells the team what stories to pull into the Sprint Backlog, you have a problem on your hands.
This kind of behavior will lead to a lack of trust and demoralize the Developers and the whole Scrum Team (which includes the Product Owner and Scrum Master). No one likes to be controlled or micro-managed. But by dictating what work you, as PO, expect the Developers to deliver without having any idea about what it takes to develop the work, you can’t possibly know what they can accomplish.
Solution
Only the Developers can decide what work they will work on each Sprint. Their job is to commit to delivering the work they plan for and determine how to accomplish the work. They should seek guidance from the Product Backlog, which will be an easy task if sequenced correctly to value and prioritize.
The Product Owner must trust the Developers to make decisions about what work they think they can accomplish. If there are technical dependencies, or if doing one thing first will make subsequent stories faster and simpler to develop, it’s up to the Developers to choose.
Picks solutions without consulting the Developers
Problem
When a Product Owner selects a solution but doesn’t consult the Developers, this leaves the whole Scrum Team in an unfortunate spot. The Developers’ job is to figure out how to solve the problem or opportunity. It may be to buy a solution, or it may be to build. But a Product Owner should not make this decision without first talking with the Developers.
Solution
Involve the Developers in decisions that involve selecting the best solution – as early as possible. They will have additional technical insight and opinions that you didn’t consider. Their knowledge may influence determining the right choice, given the context of the situation. Make sure to allow them to weigh in so the best solution option is selected.
Pressures the Team to work overtime
Problem
The Product Owner is the person ultimately responsible for the success or failure of a product. The developers should show a valuable working piece of the product each Sprint. Well, suppose the team is too ambitious or underestimates something or makes a discovery. In that case, any of these situations could jeopardize the team’s ability to meet their Sprint Goal.
If this happens (and it sometimes does), the Product Owner should not expect unrealistic outcomes from the Developers. Nor should the team be pressured to work at an unsustainable pace, leading to frustration, anger, and burnout. No one wants that to happen.
Solution
If something comes up that threatens the Sprint Goal, the team should immediately communicate their findings to the Product Owner. Based on the new information, the team should reevaluate what is possible, negotiate, and update the Sprint Backlog accordingly. The ability to pivot is one of the critical tenants of being Agile – and so is keeping a sustainable pace.
Decisions are not Respected
Problem
This issue isn’t about the Product Owner, but it’s about the people surrounding the PO. A Product Owner is responsible for making decisions, but it doesn’t exactly work in some organizations. In some companies, powerful or influential stakeholders can reject a decision and steamroll right over the PO. I know this is hard to believe, but I have seen it happen.
Solution
This often comes back to the problem of the Product Owner not having a spine. A PO must make good decisions, backed up by facts and evidence. In doing so, it is easy to demonstrate why your decision is sound, even if there is pushback.
A Product Owner needs to be fearless and a fierce protector of the product. This means defending against usurpers who attempt to take the product in the wrong direction. It may mean that you make some political enemies, but you can stand up to any opposition if you have integrity and facts to back you up.
Can’t deal with conflict
Problem
If I’m being honest… and I am, dealing with conflict has always been hard for me. In recent years, however, being in more Scrum Master and other leadership positions, I have been forced to face conflict rather than flee from it (it also helped me read about five different books on the topic).
Solution
For Product Owners, conflict is an inherent part of the job. There will always be competing stakeholders with different interests. There may also be nay-sayers or people who want you to fail. But as a PO, you can’t run away from conflict – you must deal with it. I know this is easier said than done, but you must do it if you want to succeed.
My suggestion on this would be to do what I did – read a lot of books. Research the topic on the internet. Find someone willing to role-play with you and practice the tools you learned from your reading. Start with minor conflicts and work your way up to larger ones (and they will happen). This way, you will be prepared, not scared to tackle challenging situations.
Final Thoughts
Well, that’s all, folks. Leadership is a crucial aspect of being a good Product Owner. Now, what do you think? What aspects of leadership have you seen go wrong in your Product Owner? Share your story in the comments below. I would love to hear what you have to say.