5 Things the Product Owner Shouldn’t Be Doing
Product Owners are accountable for maximizing the value of the product. That means setting direction, establishing the Product Goal, and ordering the Product Backlog around what matters most.
But accountability doesn't mean doing everything yourself. Great Product Owners delegate work that others can do so they can protect their time for strategy.
The Product Owner owns the direction and desired outcomes. The Scrum Team determines how those outcomes get delivered.
Great Product Owners know what to own and what to delegate. Here are 5 places to start.
1.) Don't be the team's copy editor
I once worked with a Scrum Team that would send Product Backlog items (often called user stories) back to the Product Owner if there were typos, so that the Product Owner could correct them.
This is the opposite of what needs to be happening.
The Product Backlog isn’t a showpiece. It's a means to an end. Its purpose is to make the work needed to achieve the Product Goal transparent and understandable. It doesn’t need to be a work of art. If a Developer spots a typo, they can fix it. If something needs clarification, they can add it or work with the Product Owner to clarify it.
There may be exceptions. If the Product Backlog serves as a legal or regulatory record, for example, greater document controls may be needed. But otherwise, sending work back to the Product Owner just to fix a typo creates a bottleneck without adding value.
2.) Don't write the entire Product Backlog yourself
The Product Owner is responsible for Product Backlog management. That doesn't mean they need to personally write every Product Backlog item.
I once worked with a Product Owner who had six Scrum Teams supporting her product, about 60 Developers in total. There was no way she could personally document every item on the Product Backlog.
Instead, three Business Analysts worked across her Scrum Teams and helped turn the Product Owner's direction into Product Backlog Items. If the Product Owner wanted to update the document upload process, she might speak to one of the Business Analysts (BAs), and that BA would work with stakeholders to break that work down into items for the Product Backlog.
If there was technical debt that needed to be done, a software developer might investigate and add items to the Product Backlog.
The Product Owner provided the direction. The Developers and Business Analysts turned that direction into actionable work.
How much information is in each Product Backlog item is up to the Scrum Team. Some teams want a lot of detail and others need just a general outline. But either way, the Product Owner doesn't need to be the only person putting all of that documentation together.
3.) Don't be the final quality gate
The Product Owner should not be expected to check everyone’s work or formally sign off on every Product Backlog item before it’s considered done.
The Developers are responsible for the quality of the work they deliver. In Scrum, "Developers" means everyone on the Scrum Team doing the work. Scrum Team members are responsible for the quality of the work they deliver. They are responsible for ensuring each item that they deliver meets the Definition of Done.
If Scrum Team members have questions about what is expected, they can reach out to the Product Owner for clarification. But that’s different from requiring the Product Owner to double-check or approve every completed item.
Sometimes what gets delivered won’t be what the Product Owner envisioned. Maybe there was a miscommunication. Maybe the team built what everyone agreed on, but seeing it in practice changes the Product Owner’s thinking. In those cases, the Product Owner can add new work to the Product Backlog or, where appropriate, decide not to release the Increment.
But those situations shouldn’t turn the Product Owner into a mandatory approval step. Requiring formal sign-off on every Product Backlog item creates a bottleneck, slows delivery, and undermines the Developers’ ownership of quality.
The Product Owner owns the desired outcomes. The Developers own the quality of the work they deliver.
4.) Don't tell Developers how to implement the work
The Product Owner communicates what the product needs to accomplish. They don't tell the Developers how to do their work.
I once worked with a Scrum Team that expected the Product Owner to provide the table names and even specific field names that needed to be updated for each Product Backlog item. If a table name was wrong, the Developers would send the item back to the Product Owner.
Listen, I know that level of technical detail is helpful, but the Product Owner shouldn't have to supply it. If the Development team needs Technical BAs, so be it, but that doesn't mean that such work must fall upon the Product Owner. The Product Owner determines the outcome. The Developers figure out how to get it done, including figuring out what tables, fields or other technical components need to change.
5.) Don't be the gatekeeper for stakeholder communication
The Product Owner doesn't need to be the gatekeeper for communication between stakeholders and the Scrum Team. (And neither does the Scrum Master, by the way).
The Product Owner remains accountable for the content and ordering of the Product Backlog, but that doesn't mean every stakeholder conversation has to flow through them.
Direct communication between Developers and stakeholders can be very helpful. Developers can gather clarification, surface questions, and help prepare materials. The Product Owner still makes the prioritization decisions, but the work of understanding stakeholder needs can be shared.
One of the best Product Owners that I ever worked with made this easy. She put together a spreadsheet that included the names of key stakeholders that the Developers could reach out to if they had questions about the way certain parts of the system should work.
The Product Owner still makes the prioritization decisions. But they don't need to be the middleman for every conversation. Giving Developers direct access to stakeholders reduces handoffs, speeds up communication, and frees the Product Owner to focus on product direction and priorities.
There are exceptions
None of this means the Product Owner should never pitch in. There may be times when Developers are getting up to speed on the product and the Product Owner's expertise is helpful in figuring out which tables need to be updated, who to talk to, or how something might be implemented.
But helping with the work doesn't mean becoming the person who must do it.
The Product Owner identifies outcomes that are needed, and the Developers determine how to achieve them. There is back and forth, of course, where Developers can give the Product Owners ideas on what might add the most value, and Product Owners can brainstorm with Developers on how that might best be achieved given the Product Owner's long-term vision.
Scrum has very few hard and fast rules and depends upon the creative intelligence of the Scrum Team. But great Product Owners do need to protect their time for setting direction, establishing the Product Goal, and ordering the Product Backlog (with input from Developers).
Delegate the rest so you can maximize value and improve customer outcomes.
Learn what great Product Owners do focus on.
Great Product Owners know where to focus their time and where to empower the Scrum Team. In the Advanced Product Owner class, you’ll learn how to focus on the work that matters most, maximize product value, and improve outcomes for your customers.
