The Great Product Owner: Listening, Investing, and Learning With the Team
“A great product owner is not the person with all the answers. It is the person who creates access to the right evidence.” – Oluyomi Emmanuel
Oluyomi shares the example of a Product Owner whose strongest habit was asking the team for feedback, listening without defending himself, and then acting on what he heard. In one sprint review, the team looked at internal metrics and raised a difficult concern: they were completing work, but it did not always seem closely connected to what customers needed.
The Product Owner could have defended the roadmap or blamed incomplete metrics. Instead, he treated the feedback as evidence worth investigating. He secured a training budget and enrolled both himself and the whole team in behavior-driven development training. More importantly, the training did not remain a certificate exercise.
The Product Owner joined the learning and helped bring BDD practices into refinement, stakeholder conversations, and interviews. The team’s conversations moved from abstract requirements to specific situations and expected outcomes. Hidden assumptions became visible earlier, and the team could challenge unclear requirements constructively before implementation began.
Self-reflection Question: How does your Product Owner show the team that feedback changes real behavior?
The Bad Product Owner: The Absent Product Owner as a Role Design Problem
“An absent product owner is often not an individual time management problem. It is usually a role design problem.” – Oluyomi Emmanuel
Oluyomi also describes the absent Product Owner anti-pattern. In his example, the Product Owner was not careless or uninterested. The structural problem was that the same person was both Product Owner and line manager, so the Product Owner role kept being squeezed into whatever time remained. Epics existed, but the team lacked enough context to refine them.
Questions accumulated, refinement became a place to discover missing information, and important decisions waited for someone who was rarely available. Oluyomi first asked for more Product Owner availability, but that did not change the system because the competing responsibilities remained. He then created a stakeholder map for the major areas of work: who had the business problem, who owned the desired outcome, who had specialist knowledge, and who would be affected by the change.
Inviting relevant stakeholders into refinement gave developers direct access to context. The lesson was not to remove product ownership, but to stop making the Product Owner the only messenger between the team and every stakeholder.
In this segment, we refer to behavior-driven development, product ownership, and stakeholder collaboration.
Self-reflection Question: Are you compensating for an unavailable Product Owner in a way that keeps the real organizational design problem hidden?
Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!
About Oluyomi Emmanuel
Oluyomi is a Scrum Master, Agile Coach, and Product Lead with over seven years of experience helping teams work better and deliver meaningful digital products. Having worked across energy, consumer platforms, and fintech, he is passionate about building high-performing teams, creating clarity, and turning Agile principles into real business and customer value.
You can link with Oluyomi Emmanuel on LinkedIn.
