The product owner role is critical in software development

When the product owner role isn’t strongly developed, it can derail the best-run software projects. How do you deliver the right product when the business is less than fully engaged?

I didn't set out to write a column about the product owner role. But over and over, in recent conversations with software pros, the term keeps coming up.

Our product owner is a roadblock, and failure to get fast answers is holding back the team, one software pro told me. Our product owner doesn't sit with us, and she has a ton of other job responsibilities that have nothing to do with software development, another said. One guy I talked to had a success story to share. His team found a way around the product owner roadblock,  and now their product owners routinely respond in two minutes.

The product owner role

The reason people are talking about the product owner role is simple; the success of all software projects hinges on getting the product owner role right. The term comes from the Scrum approach to application development, but it applies to all software projects, even those that aren't Agile.

The product owner is the keeper of what the business wants, what it needs and what it will accept from the software under development. In other words, does the software empower the people who use it to do their jobs better? Does it help the business sell products, deal with suppliers, or respond to customers faster and more efficiently?

If the software your team delivers can't accomplish a subset of these goals, it doesn't matter how well it works, how high the quality, or how quickly it was released. Or, as Agile consultant Janet Gregory, co-author with Lisa Crispin of the 2014 book More Agile Testing, put it: "The biggest risk in software development is delivering the wrong thing."

The part-time product owner

A key cause of the product owner roadblock is that many businesses outside the software sector remain reluctant to dedicate a full-time business person to software development projects, said Voke founder Theresa Lanowitz. "When you put business people on software development projects, it costs the business money." Part-time product owners result in a "lack of business engagement" in software development, she said.

With limited access to their product owners, software teams are forced to make do. Questions remain unanswered, and even when responses arrive, part-time product owners can't do as good a job as those who are present full time, said Johanna Rothman, management consultant at Rothman Consulting LLC.

"I know I said that before, but I like what I see now," Rothman said, offering an example of what a full-time, fully engaged product owner might say. When a product owner isn't available to the team, it's really a bad thing, she said. "You're shortchanging software development, because you're always optimizing for the one who isn't there."

The product owner role roadblock

Gregory said one thing she sees among her clients is product owners who want everything to go through them. In large projects this creates a roadblock. "The product owner has become a wall in some cases; they think they have to know everything," she said. For large, complex software projects, where the team may need answers to a dozen different questions at any time, this simply isn't practical, she said. To keep a project on track, it's important to empower more people to get that information, Gregory said. "To understand what we are building, we have to go outside [the team]. Don't let the product owner stand in the way."

Product owner: The two-minute response

In mob programming the whole team, including the product owner, works together around a single screen. But even in organizations successfully implementing this software development approach, product owners have other responsibilities.

Woody Zuill, former software development manager at Hunter Industries, was able to keep product owners engaged, even when they were working on something else. "We'd call with a question and the product owner would say: 'Here's the answer,' or 'I'll be right over.'"

I asked Zuill why he thought his product owners remained engaged while others don't. "They noticed we delivered [working software] daily," said Zuill, now a senior consultant at the Berkeley, Calif. coaching and training firm Industrial Logic Inc. "They were using the software [to do their jobs] and they saw that we were improving every day." What's more, they saw what happened when they didn't provide timely responses. "When they didn't get back to us, we simply moved on the other projects," he said. That was an awakening for one product owner. "I promise to get back to you within two minutes of your call," he told Zuill, after that happened to him.

Now, that's an engaged product owner.

Next Steps

Changing roles of a product owner

Agile projects pose challenges for project owners

Mob programming boosts teamwork to the next level.

Dig Deeper on Topics Archive