A common reaction to the product owner role is to see it as too big for a single person. If the idea were that one person should do everything from guiding the vision to writing user stories, I would agree. But that’s not how I see the role; I see it as one component in getting to effective teamwork.
A colleague of mine once came into the office reeking of frustration. He told me what had happened. Hoping to get some help, he had just spoken with his project manager about needing clearer priorities.
“Too much is going on right now,” my colleague had said. “We’re not getting anywhere—we’re just skidding around. If you could help us prioritize, that would really help.”
“Well,” the project manager said, “we don’t really need to prioritize because everything has to be done by March 31.”
I have to confess that my first thoughts about that project manager weren’t particularly nice. However, as I kept thinking about the absurdity of the answer, I found one way to understand the project manager’s perspective: If you know beyond a shadow of a doubt that everything will be done by March 31, then prioritization isn’t that important. After all, everything will be done, so why worry about the order of doing things?
If you’ve ever worked on a development project, you know that we can never be that sure that everything will be completed on deadline. You also know that there are many factors in organizations that push us to act as if we were that sure. Uncertainty, mildly put, is seldom a welcome state, so woe unto those who mention it.
Unfortunately, if you want to be agile, you have to not only mention uncertainty, but also engage with it head-on. Unlike the project manager in the story above, an agile product owner can never hide behind the answer “Everything has to be done.”
If you are even slightly worried that your cherished plan might not play out as desired, you need to do very active and continuous prioritization work. Good prioritization is what lets you ship by the deadline even though some stuff turned out much trickier than you expected it and half of the initial requirements have been swapped for something completely different.
By prioritizing actively, we can change success from something binary—either we make it or we don’t—into something more gradual. By doing this, we increase our chances of succeeding in delivering something. If we prioritize really well, that something may even turn out to be far more valuable than anything we had penned down in our initial plan.
In other words: In development work, prioritizing well is the key that lets us survive in spite of budgets, deadlines, and unknowns.
The challenge is that prioritizing is really difficult. Prioritization in an agile context means seeing both the bird’s-eye view of things and the nitty-gritty details as we discover them. In practice, this often means the task of prioritizing is too difficult to be done well by a single person. Here are just some of the skills needed:
- Deep insight about the needs of the people on the receiving end
- Understanding how the business works
- Analytic thinking
- An understanding of what is technically possible
- The ability to learn rapidly in order to cover important knowledge gaps
- Knowing what other constraints are in play