In this installment of my blog series on “Anti-patterns that Doom a Product Owner to Fail” I dive into the topic of Product Owners who come from a technical background, rather than a business one. I’m not saying this can’t work, but if this is the situation you are in, watch out for these perils of being a “technical” Product Owner.
Product Owner came from a technical background
Problem
If your Product Owner used to be a developer or came from a technical background rather than having business experience, you may run into a few issues. Instead of expressing the “who, what, and why,” the technical Product Owner may attempt to define the “how”. But it’s not the Product Owner’s job to figure that out. His/her job is to maximize value.
Solution
Ensure that the Product Owner’s role is understood and define the boundaries between responsibilities clearly. A good Scrum Master can coach technical Product Owners in their role and steer them away from harmful practices that might come from their experience.
Acts as a Solution Architect instead of a Product Owner
Problem
Like the last issue, Product Owners who want to architect the solution will ruffle someone’s feathers. But for someone with a technical background, designing a solution may be second nature. And, as a technical Product Owner, s/he may be hesitant to trust someone else on the team with this responsibility.
Solution
One of the Developers on the Scrum Team should be responsible for solution architecture, not the Product Owner. The Developers should consult the PO, but they decide “how” they get the work done. The User Story and Acceptance Criteria should not contain any solutions but should allow the Developers to find the best solution to the business problem.
Unrealistic expectations of the team based on “experience”
Problem
With a technical Product Owner at the helm, s/he may have unreasonable expectations of what the team can accomplish based on his/her experience. When feeling pressured, the Developers may take on more work than can be completed in a Sprint; this will lead to missed goals, frustration, and an unsustainable pace.
Solution
Don’t have any expectations. Every team is different, and you can’t compare one Scrum Team to another. Only the Developers get to choose what they will pull into each Sprint. By having no expectations, you won’t be disappointed.
Not dealing with Technical Debt
Problem
Let’s be honest. You’ll never get rid of technical debt entirely. And like financial debt, when you let it pile up, it can be next to impossible to dig yourself out of it. Technical debt impacts the team’s ability to deliver valuable increments and will eventually reach a catastrophic tipping point. As the Product Owner, part of your job is to make sure this doesn’t happen.
Solution
Don’t ignore technical debt. Instead, be aware of it and plan to tackle it. You should only acquire technical debt with intention. Everything that falls into this bucket should be on your Product Backlog. To continue delivering value, target a certain number of items, points, or percentage of the team’s capacity to tackle each Sprint. This way, you’ll slowly start chipping away at the debt while improving the quality of your product.
Product Owner sizes the stories instead of the Developers
Problem
This one drives me nuts. A Scrum Master once asked me to do this, and I couldn’t believe it. I understood the reasoning behind it, but I am not qualified to size User Stories (I’m not a Developer). So, my estimates are wild guesses that won’t be helpful for anything other than attempting to forecast.
Solution
As a Product Owner, it’s not your job to size User Stories. The Developers on the Scrum Team are the ones who should size User Stories. Your role as the PO is to provide context to the team about why they are doing the work, support them by answering any questions, and clear up anything that needs clarification.
Pre-assigns Product Backlog items to team members
Problem
Having the Product Owner assign backlog items to specific Scrum Team members is inappropriate. It’s not the PO’s job to direct the team’s work. And just because one person on the team might have the most knowledge or expertise, it doesn’t mean that person should always get the story.
Solution
The Developers should volunteer to work on User Stories, not be volun-told. Letting the Developers choose their work enables the team to decide who works on what collectively. In addition, if you want to learn something new as a Developer, this could be an excellent opportunity for cross-training, which makes you more valuable to the Scrum Team.
Final Thoughts
While in some circumstances having a technical Product Owner may be an advantage, you also need to watch out for the “gotchas” that could cause problems. Make sure you’re not falling into any of these traps.
Now, it’s your turn. What are your thoughts on having a technical Product Owner? Is there anything else you have seen technical POs do that I missed? If so, let me know in the comments below!