When the Product Owner role is going well, it’s super high-leverage. A good PO sets up a whole team to do more meaningful, valuable work. But because the PO role is so big and complex, it can go wrong in a few common ways. Here are 6 archetypes for how Product Ownership can go wrong, why POs end up falling into that pattern, and what to do if you catch yourself doing it.
The Technician
The Technician gets too far in the weeds on the solutions. The Technician often cares more about the implementation than the problem.
It’s easy to fall into the Technician pattern if you come to the PO role from a technical background. Getting into the details of the solution is fun, and it can feel satisfying to see the problem through all the way to the end.
If you catch yourself becoming the Technician remind yourself that you have a whole team responsible for a good solution, while you’re solely responsible for becoming the expert on the customer and the customer’s problems. If you start doing your team’s job, you’re unlikely to do it as well as all of them combined, and no one is going to be doing your job. Sometimes, this is a signal you need to develop skills on the problem side of things—if you have a technical background, you may be gravitating towards the work you feel most competent at.
The Dreamer
Almost the opposite of the Technician, the Dreamer only wants to focus on the big picture. “I set the vision. Let the team worry about the details,” the Dreamer says.
Becoming the Dreamer is attractive because, as one of our clients put it, “it allows you to stay in the difficulty-free possibilities, where you don’t have to address the constraints and realities.” Some POs love talking to customers and making slide decks of big ideas but hate the tactical work of building a product backlog and collaborating with a team on a solution.
If you catch yourself getting stuck as a Dreamer, the hierarchical backlog approach we teach is often the antidote. Instead of taking on the overwhelming and tedious work of breaking a big idea into all its user stories, find the first Minimum Marketable Feature of the big idea. Then, break that MMF into user stories. Then, if it’s complex, collaborate with your team to build that MMF and see what MMFs that work suggests come next. Check out our PO Board Humanizing Work Show episode for how to structure your backlog for this kind of thing.
Don Quixote
Like Cervates’s fictional Don Quixote taking on a field of windmills, the PO as Don Quixote solves imaginary, unvalidated problems.
It’s easy to fall into the Don Quixote pattern when you have an idea for a solution that you find particularly compelling. Maybe it even solves a problem you have yourself. And because of sunk cost bias, the Don Quixote pattern becomes stickier and stickier the more you invest in solving your unvalidated problem. You almost don’t want to know if you’re wrong about it.
When you catch yourself playing Don Quixote as a PO, the only real solution is to ask, “How could I discover as quickly as possible if I were wrong about the problem we’re currently trying to solve?” And then actually run the product assumption test that could invalidate your hypothesis about the problem. It’s so easy to accidentally design a test that just tells you what you want to believe—you may need to enlist the help of a neutral coach or colleague.
The Backlog Admin
The Backlog Admin takes requests from stakeholders and manages them. The Backlog Admin spends time polishing Jira tickets but rarely does customer research or product strategy.
The Backlog Admin pattern feels safe for the PO—you’re not going to get in trouble for building the wrong thing because it was someone else’s idea. And it often works in an organization because it allows stakeholders and leaders to feel like the expert, giving orders for what a product should do. It also can let an organization avoid difficult conversations about strategic priorities. Every request just goes on the backlog.
The first step to move out of the Backlog Admin pattern is often learning how to ask “why?” without asking “why?” The Backlog Admin needs to move from taking orders to understanding the rationale behind them to eventually taking ownership of backlog priority and even product strategy. But just asking “why?” of every request won’t work. It’ll too often provoke a defensive response: “Because it’s important. Just build what we need.” Instead, ask questions like, “What were you doing last time you wished the product had this?” and “If the product had this, what would that mean for you? What would happen next?” Where “why?” can sound like a challenge, questions like these communicate curiosity. After a while, you may come across a request that doesn’t seem to have a compelling rationale. Or perhaps one that isn’t the best way to achieve the desired outcome. Suggest an alternative. And with that, you’ve begun to move towards become a Product Owner, not just the Backlog Admin.
The Order Giver
The Order Giver tells the team what to build but doesn’t bring them along on the who and why. “I’ll worry about why. The team just needs to build the features I ask them to build.”
Being the Order Giver can make the Product Owner feel important. And giving orders can feel more efficient than building alignment, so it’s attractive to an impatient PO.
For some POs who fall into the Order Giver pattern, the fix is as simple as reminding yourself to communicate the who and the why for your backlog items. Share customer profiles. Craft and communicate a product vision. Connect user stories to larger features and initiatives.
But for many POs, being the Order Giver has a psychological basis:
- I want to be in control.
- I want to feel important.
- I don’t trust my team to make decisions as good as mine.
You may need to do some reflection or talk to a coach to address these. They can be sticky.
The Sphinx
Finally, mysterious and contemptuous, the Sphinx is the Product Owner who thinks the team members are idiots for not just understanding what the he understands. The Sphinx gives vague, incomplete information, not because he’s leaving space for team autonomy, but because “the details are obvious to any intelligent person.” Anyone who asks a question just doesn’t get it.
It can be easy to fall into the Sphinx pattern because the Curse of Knowledge cognitive bias causes us to assume that what’s obvious to us is just as obvious to everyone else. After learning a thing, we promptly forget that we learned it and start behaving like we always knew it—and assume everyone else on our team must know it, too.
Because this pattern is driven by cognitive biases, it can be hard to catch yourself doing it. Here’s what to watch for: If you find yourself starting to think your team just isn’t very smart, if you start thinking they’re asking stupid, unnecessary questions about your backlog items, you might be the Sphinx. The fix is to make their understanding of the backlog your responsibility.
Consider this: The word communicate comes from the Latin word meaning “to make common.” So, when have you actually communicated? Not just when you’ve said or written something, but when you and the person you’re communicating with have a common understanding of it. If they don’t understand it yet, it’s your responsibility to keep communicating. (Are there genuinely obtuse, unintelligent, or intellectually lazy people in the world? Sure. But assuming that’s your whole team doesn’t give you a lot of options. Better to assume they’re trying to do a good job and take ownership for your own communication.)
—
Isn’t it Interesting
Often, what looks like a process problem is actually a trust problem.
When, for example, a Product Owner is getting into the weeds of the solution, it can be tempting for a ScrumMaster or coach to say, “That’s not your job, PO. Follow the Scrum rules and leave the solution to the developers.” But getting into the solution details can be a signal the PO doesn’t trust the developers to own the solution. You don’t fix that by enforcing the process. You fix that by building trust.
Likewise, developers working on backlog items out of priority order. It’s tempting to focus on doing the process right. But this is a signal the developers don’t trust the PO to point them in the right direction. They’re making their own priorities. Fix this by building trust, communicating the “why” more clearly.
—
Learn More
Last updated