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

Luckily, we’ve known for a long time what to do when faced with what at first seems like a need for a superhero. We use a team instead. I’m not thinking of a product owner team, here. I’m thinking of a well-formed, cross-functional, and multiskilled development team. Such a team can contain within it all the skills needed to manage the challenging task of discovering, analyzing, and prioritizing the true requirements.

So, why do we need a product owner if the entire team does work that just a minute ago looked like product owner responsibilities? We still need a product owner because the job of the product owner is not to serve up requirements; it is to make sure the team is thinking about and working on the right things.

Still, as soon as we switch to team mode, a new challenge arises: We need to find a way to think effectively together. When done right, thinking together feels like a creative wonderland. When done badly, it feels like a frustrating and wasteful misuse of everybody’s precious time.

Product owners who want to make use of the entire team’s thinking abilities need to learn some truths:

• A good product owner has enough knowledge and understanding to make excellent prioritization decisions.
• A great product owner feels such strong ownership of the product that he or she is willing to invest great effort in making sure we don’t just make the right decisions, but also that we make them in the right way. In the end, true responsibility for the product is something that needs to be shared by all involved in creating it, and that only happens if we manage to engage the entire team fully.
• A fantastic product owner grows the entire team’s knowledge of the problem domain over time so that everyone understands how prioritization needs to be done. This helps avoid a situation where the product owner becomes a bottleneck in daily decision-making.

For nontrivial products, effective agile prioritization needs to be a team’s work. Because the task of breaking down the work into small bits is so hard, the knowledge of the entire team is needed. The goal is to take a myriad of interacting factors and wrestle from them a clear and shared prioritization. Again, this does not mean always working in consensus mode. Skill, deep understanding, and great facilitation go a long way toward ensuring we move ahead intelligently and quickly. Still, sometimes we get stuck, and then it’s useful to have the product owner make the call, if only to break the logjam and do something.

In searching for efficiency, some agile teams unwittingly sacrifice the cooperative and conversational ideals that agile was founded upon. They assign roles, play parts, and prepare for the inevitable blame game. Sure, thinking together is hard. And sure, sometimes we can succeed by improving efficiency and clocking more hours. However, if we can build our skills and get over our feelings of discomfort, thinking together may just turn out to be our strongest competitive advantage.

In practice, this all means that for a trivial product, the product owner may very well be the one person who analyzes and presents requirements to a few developers. But in a just slightly more challenging product, it’s more helpful to see the product owner as someone who focuses on the overall direction, and the entire team as responsible for talking to customers and capturing those conversations as user stories.

When the product owner is seen as someone who should feed requirements to developers, the role becomes overburdened by the sheer amount of work and the complexity of it.

A more effective way to use the product owner role is to see it as responsible for engaging the whole team in discovering and pursuing a grander goal. Such a shared and exciting goal is what makes a group gel into a team, guides it toward the right product, and makes possible those tricky tradeoffs that let us be really agile—in the true sense of the word.