Product owners: Want some advice from Scrum Masters and teams on how to be effective? You’ve come to the right place.
I’ve worked and talked with countless Scrum Masters and development teams over the years. They’ve told me about good product owners and bad product owners. They know that a good product owner can turn a good product into a great product—and a bad product owner can sink a project faster than any bad technology decision.
Successful product owners usually don’t have better resumes than their less-effective counterparts. What they do have is a knack for knowing what people need (whether those people are their stakeholders, customers, or teams) and ensuring they have it (or can understand why not). What’s behind that knack
I’ve found six things effective product owners must give to the various people they serve: Availability, Vision, Collaboration, High Expectations, Priorities & Flexibility, and Storytelling.
#1. Good Product Owners Are Available
Scrum teams are often under tremendous pressure to deliver more, faster. But that’s impossible without time and support from the product owner to answer questions and clarify expectations.
Start with the mindset that, as much as any developer, you’re part of the team. Sit with the team if you are in an office setting; if you are remote, participate in the team’s Slack or Discord channels. Attend daily scrums. Go to sprint planning, reviews, and retrospectives.
Remember your role on the team is to be the authority on what users want, and more importantly, what they value. Demonstrate that you understand the product and how it will be used—not just by writing user stories, but by knowing the product as it evolves and develops. That includes being able to demo new functionality at sprint reviews.
#2. Effective Product Owners Paint a Vision
The best product owners have a compelling vision for their product. This doesn’t need to be a Steve Jobs-style vision of an entirely new industry. But teams do need to know why a product is being created.
Product owners like you are responsible for making sure the product has a vision that you can articulate. If you can’t articulate it, don’t start building it.
Team members become motivated when you provide them with what Larson and LaFasto call “a clear, elevating goal.” According to these experts, the lack of a clear, elevating goal is the reason given most frequently for why teams fail.
The best example of a clear, elevating goal was President Kennedy’s call to land a man on the moon before the end of the 1960s.
- It was clear: Everyone would know if the goal had been met or not.
- It was elevating: We can easily imagine the excitement of being on a team of such historic importance.
The product goal should be just as clear. Of course, the goal does not have to be quite as elevating as putting a man on the moon, but it should be something we want to accomplish—either because the goal itself is meaningful or because of the challenge it will be to achieve it.
Examples of clear, elevating product goals
The following are exampels of clear, elevating product goals:
- Win a “Product of the Year” award from the magazine covering our industry.
- Reduce call duration in our call centers by three minutes per call.
- Create a product so simple to use that training time is cut from three days to half a day.
The product vision can (and should) change over time. Even Jeff Bezos of Amazon could not have anticipated all that Amazon has become. If he had, he certainly wouldn’t have given Amazon its initial slogan of “Earth’s biggest bookstore.”
#3. Successful Product Owners Collaborate with All Stakeholders
Product owners are great at understanding that users and customers are stakeholders in a product or project’s success. They’re also good at recognizing business stakeholders within an organization.
However, too many product owners don’t recognize the importance of another group of stakeholders: development team members! The team has a vested interest in the success of the product and must be included along with business, user, and customer stakeholders.
That means considering developers’ opinions on priorities.
And it means trusting their advice on product features and needs, too.
When team members ask to be able to do something, they want the product owner to trust that they are doing so for the good of the product.
For example, suppose team members want to clean up some old code. You, as product owner, might ask questions like:
- What would happen if we don’t ever clean up that code?
- What would happen if we put it off for two sprints?
It’s possible that answers to these questions lead to a decision not to perform that code clean-up. But it is more likely that the answers will help you assess whether it’s better to do the code clean-up now or in a few weeks.
#4. The Best Product Owners Set High Expectations
Have high expectations of your team. Developers thrive on solving challenging problems—things like ‘make this run ten times faster’ or ‘do that in one-fourth the memory’—when given the freedom and time to pursue creative solutions.
Having the time to do good work is key to success. I can’t imagine standing over Van Gogh’s shoulder saying, “Paint faster. It’s good enough.” Yet teams hear this nearly daily.
There will be times when products ship with known imperfections. There will be times a team needs to rush a feature doing a “good enough” version for now. And, believe me, the development team understands this.
But those times need to be balanced with times when team members can do quality work.
When people create anything beyond a certain speed, they take shortcuts that come back to haunt them (and you). Very few products are worth doing at high speed, and all rushed products end up costing far more over the next few versions.
Since you want to deliver as quickly as possible, with high quality, it’s wise to schedule in time for learning and improvement. Technical skills go out of date quickly. New technologies are developed. Old technologies are improved, enhanced, or shown to be usable in new ways.
Team members know all this. It’s why they want time to improve their existing skills and learn new ones. Many team members also enjoy the challenge and excitement that comes with learning.
It’s a win-win situation: team members do the hard work of learning something and you, as product owner, benefit from what they’ve learned.
#5. What Makes a Good Product Owner in Agile? Priorities and Flexibility
A couple of years ago, I was talking to a colleague and I made the comment that a particular practice “would be good for time-constrained projects.” They challenged me: “Show me a project that is not time-constrained.” I laughed and said, “You’re right. There’s no such thing.”
Essentially all projects are time-constrained to some extent, so product owners must prioritize the functionality they want built. If you say, “Everything is top priority,” then when the project runs out of time, you can expect a random set of functionality, because the team won’t have known what was truly the most important piece to finish first.
That doesn’t mean priorities are set in stone. Product owners can (and likely should) change their minds as the market shifts and as they learn more about the product that’s being developed.
For example, suppose the team is halfway through a product backlog and an opportunity presents itself to sell the half-finished product to an initially small set of customers. That might be worth considering.
Alternatively, suppose a fierce competitor announces some new blockbuster feature. Adding that feature to your own product may become a higher priority than much of the other remaining work.
Indecisiveness and random changes are annoying, but changes based on new knowledge are an important interruption. In fact, if the team has established a development process to meet a product owners’ high expectations, the team’s ability to respond to change can become a competitive advantage for the organization.
#6. Product Owners Are Good Storytellers
Teams need to hear about features in chunks that are big enough to understand but small enough to estimate. User stories perfectly meet this need.
But user stories cannot stand alone. Every user story is a placeholder for a conversation: a reminder for the product owner and the developers to talk about a feature. The user story may be the most visible part of a story, but the most important part is the conversations that take place to refine the story and communicate the desired behavior of the software.
User stories should be tied to users’ goals and lead to achieving the clear, elevating goal of the product. A good product owner will not just rattle off a list of stories; they will be able to relate those stories both to workflows and to knowledge of how users will interact with the system.
How to Be a Successful Product Owner
Great product ownership is hard. You have to spend time looking outward toward customers, users, competitors, trends in your industry and more. But you also have to spend time looking inward at the team, working with them, and answering their questions.
None of the six things I have described require any special skills, training, or domain knowledge. Anyone can do them. But the importance of these attributes may be one of the most important things for a successful product owner to understand.
Be available, prioritize and re-prioritize the work, tell user stories, articulate a clear, elevating goal, set high expectations, and collaborate. You’ll be rewarded with superior results.
