Moving from task management into creating value
Do you know what the actual job of a Product Owner is?
A decade ago, when I got my first job as a Product Owner, I would summarize my job as managing stakeholders, clarifying their needs, and ensuring developers create solutions matching the pre-defined requirements. I spent at least half of my time working on the Product Backlog; I was afraid developers wouldn’t have all the necessary information to start coding. I did my best to close all open knots before sharing anything with them. That’s how I missed the point of a Product Owner is.
What worries me is that many people have a similar misunderstanding. I’ve seen many Product Owners investing too much time to manage their Product Backlogs. I learned the hard way my job was not managing backlog or stakeholders but identifying opportunities to create value and lead teams to solve meaningful problems.
Unfortunately, many people still think they have to write unquestionable Product Backlog Items. Here are some questions I often get:
- How do I write better User Stories?
- How detailed should the Product Backlog be?
- Should I have three or four Sprints of work in my Product Backlog?
These are tricky questions because it assumes your Product Backlog must be detailed, User Stories sharp, and your work predictable. When such assumptions guide Produce Owners, they will end up wasting a lot of energy by overthinking, and little power will be left to do the work that matters.
Let me elaborate on why you don’t need more than four hours a week to manage your Product Backlog. Hopefully, by the end of this article, you will know what not to do while managing your Product Backlog, and you will have more time to focus on creating value.
Sharp User Stories Lead To Wrong Conversations
Although you don’t need to work with User Stories, it’s often the first pick for Product Owners. I had good and bad experiences with this technique. The problem usually starts when the energy goes into writing instead of collaborating.
When I first worked with User Stories, I wrote flawless stories, at least I thought so. I generally started with an epic and then broke it down into several User Stories; each of them had a minimum of five acceptance criteria. I was proud of myself. My stories were sharp; any developer could work on them straight away. Now let me walk you through the problems with this approach:
- Requirement engineering: I became a requirement engineer. I had no time left to do what I was supposed to, e.g., measuring the outcome. At least 50% of my time went to writing User Stories.
- No room for imagination: as I defined everything upfront, developers had no room for creativity. They followed a plan, implemented features, and that’s it. Some liked this approach as they didn’t have to decide what to implement. Others hated me as they felt I was doing their work, and unfortunately, they were right.
- Waterfall mindset: I thought I had to define solutions and ensure developers implement them. Although we worked with Scrum, we transformed it into a waterfall approach.
My learning: Great User Stories get in the way of creating value. Don’t write great stories; write broken ones.
Broken User Stories lead to great conversations. When I started writing incomplete stories, developers started asking me, “How am I supposed to work with this?” and I would answer like this, “Let’s figure that out together. What I know is that we have a problem that’s worth solving, and you have the skills to find a proper solution for it.”
Great User Stories lead to discoveries, not to an implementation plan.
If you’re taking too much time writing stories, you’re missing the point. Just write something to start the conversation; that’s enough to collaborate.
Extensive Backlogs Leave No Space for Learnings
As human beings, we love being in control because it gives us a feeling of security. Without even noticing, we are constantly searching for safety. However, our standard behavior becomes an obstacle if we want to succeed with Scrum. The framework is all about embracing the unknown, and that doesn’t make us feel secure at all. Therefore, unintentionally (or maybe not), we do pointless things to feel we’re in control. One of them is transforming the Product Backlog into a plan.
Take a moment to look at your Product Backlog, and answer the following questions:
- How long would it take for your team(s) to tackle all items?
- How often do you adapt your Product Backlog?
- When was the oldest item created?
- Do the items contribute to a unified goal?
At the beginning of my career, I ensured the Product Backlot had enough work for at least three months, and I used to update the items several times a day. Whenever something popped up, I would jump to action and put it into the backlog. Also, I was incredible against deleting anything. Once in, never out. As embarrassing as it can be, that’s how I managed my Product Backlogs for years. That’s a clear example of poor backlog management.
It took me years to understand what I was missing the mark. I thought I had an Agile mindset, but how could that be true with such an extensive Product Backlog. I failed to embrace the unknown. My fear of the unknown trapped not only me but the whole Scrum team.
I found my way out by doing less work instead of more. First, I decided to remove all items older than three months and then evaluate all items in the Product Backlog and remove anything unrelated to our quarterly objectives. We went from 543 items to 31. And from that moment on, I learned a crucial lesson in my life:
Only when the old goes away does the new find its space.
I made peace with the unknown and started spending four hours a week with the Product Backlog instead of twenty.
Four Hours a Week is All You Need
As a Product Owner, you’re ultimately responsible for the Product Backlog, yet that doesn’t mean you need to spend your life managing it. Your mission is to maximize the value of the product or service you work for. To fulfill your assignment, you need to be smart and choose wisely where to put your energy into.
Managing the Product Backlog can be simple if you’re ready to embrace the unknown. It’s all about how risk-averse you are. Generally, Product Backlogs become quite prescriptive when we are afraid of failing. This attitude will ultimately make us miss opportunities because we focus on avoiding failure instead of maximizing success.
Here is my recipe for managing the Product Backlog in less than four hours a week:
- Set a Product Goal. Only allow related items to go into the Product Backlog.
- Write broken items. With this mindset, I leave room for creativity and collaboration. I focus on identifying what to do instead of writing precise requirements. Prioritization creates more value than sharp requirements.
- Delete the Product Backlog every second month. By doing that, I don’t even bother about writing pointless items. I know they will not survive after two months.
When managing the Product Backlog costs more than half a day per week, I know I am adding complexity to something that should be simple.
Simplicity is the best way of liquidating complexity.