Product Owners have a tough job. They’re required to take a swarm of opinions and coalesce those opinions into a single, unified vision. Undoubtedly, some stakeholders won’t agree with that vision, and they must invest time and energy in soothing the disgruntled. Further, if a Product Owner is thinking too far forward, the team gets restless because they have questions and the Product Owner is locked away in a conference room. The balance is unforgiving, and frankly, I don’t envy the role of the Product Owner. Most days, I write to the Scrum Master or agile coach but not today. Today, I want to share two tips with our Product Owners. I have a ton more Product Owner tips, but let’s start here and see what happens next. Let’s get started.
Opinions about backlogs are like assholes
Everyone has one, and most of them stink. Let me explain:
- Stakeholders and leadership often want a detailed backlog. Everything should be articulated, estimated, and crystal clear. After all, a clear backlog gives them control over their destiny. However, I’ve found that it’s the illusion of control it provides and not control itself.
- Team members usually enjoy items that they can work on in isolation. In other words, forget cross-discipline stories. Thinking creatively about how to parallelize or communicate across disciplines is hard. Of course, just because something is hard doesn’t mean you shouldn’t do it. In this case, the value of breaking down silos will greatly benefit the team.
- Scrum Masters want a backlog that follows the principles of INVEST. After all, that’s what we were taught in the CSM course, and what we hear from others in the community. INVEST is an excellent mental exercise, but splitting stories across the such boundaries is often challenging and can be time consuming.
All the while, Product Owners simply wants to spend time understanding the customer so what should they do? My advice is this. Experiment but don’t stress. Try new things until you strike the right balance. That balance is found when you hear the fewest complaints, and over time, the maturity of the team and organization might require you to tweak that balance. That’s a good thing. After all, agility implies flexibility so embrace it. As far as practical things you can apply with your teams, these two resources might come in handy:
There’s a laundry list of other readings on the topic, and there also exists a number of techniques that can help you and your teams craft an effective backlog. User story mapping, for example. In fact, that leads into my second tip.
The why. The what. The how. In that order.
I can’t tell you the number of times I’ve seen a Product Owner begin by explaining what the team should implement before describing why do the work at all. Stop. Just stop.
Fall in love with the problem, not your solution.
Five times out of ten, your team will find a solution twice as effective as yours at half the cost so you’re robbing yourself of the opportunity to succeed! To that end, start by explaining the why. The problem. It’ll drive vision, create passion, and it leaves the opportunity for them to problem solve along side you. This, in turn, will create engagement and ownership, and you’ll find team members driving vision with one another, leaving you with more time to pave the road for future work.
Secondly, collaborate with them to identify the what. The solution. Do so by means of user stories and acceptance criteria and prioritize these stories based on feedback from customers, leadership, and the team. Finally, leave the how to them but be available to answer questions that will inevitably arise.
I jotted down many more Product Owner tips, but I want to stop here for now. Did you find this blog post useful? If so, let me know in the comments below, and I’ll happily put together another list of Product Owners tips. One more thing before I go though. It’s not easy work so if you haven’t thanked a Product Owner lately, do so now. He or she will appreciate it.
Update: If you’re interested in more Product Owner tips, check out When Prioritization and Customer Empathy Aren’t Enough.
Do you want to get notified when new posts are published? Leave your email below.
Awesome. I will be sharing with my POs.
Good to hear, Mark. I hope it helps them and their teams.
Great article – definitely one I will be sharing and thanks for writing 🙂
I would put the “Why / What / How” tip at the top though – if I had three bits of advice to give a PO / PM, all three would be “work out what the problem you are trying to solve is”: if you understand that, the stakeholder conversations are much easier, the developers feel they are doing something useful and you can start working out its real value so you can tell if the solution is worth building.
Definitely agree more tips for POs would be good – looking forward to seeing more of yours…
Thanks, James. The order of the tips was arbitrary so I’m curious. What’s your logic for reversing them?
Pingback: Confluence: Jumia Travel | Jovago
Good one. I shared this to the POs that I work with. Like many others, looking forward for your complete list.
thanks.