Working With Your Product Owner: The Relationship That Drives Delivery

I have worked in Agile teams where the BA and Product Owner relationship was genuinely excellent. The Product Owner set the direction. The BA translated it into requirements. Each brought something the other did not have: the Product Owner brought authority, strategic context, and stakeholder relationships; the BA brought analytical rigour, requirements expertise, and the ability to translate a business vision into specific, buildable work. Together they formed the most effective partnership in the delivery team. I have also worked in teams where this relationship was broken. Where the Product Owner and BA were duplicating each other's work, arguing over backlog ownership, or simply operating independently with no shared understanding of their respective responsibilities. In those teams, the backlog was incoherent, priorities changed without reason, and the development team spent significant time waiting for clarity that never quite arrived. The difference between those two experiences was not the methodology. It was the relationship. And the relationship, in both cases, was largely shaped by how the BA chose to approach it.

What the Product Owner Role Actually Is

The Product Owner is responsible for maximising the value of the product delivered by the development team. In Scrum, they own the backlog, define the priority, and make the final call on what the team builds and in what order. In practice, however, the Product Owner in many organisations is a business stakeholder who has been assigned the role without the training, the time, or the organisational support to fulfil it properly. They may have strong opinions about what the product should do. They may have excellent stakeholder relationships. But they often lack the analytical skills to translate their vision into well-formed requirements, the bandwidth to engage with the delivery team as frequently as Agile requires, and the authority to make the prioritisation decisions that the role demands without needing to escalate every call. This is not a criticism of Product Owners. It is a reality of how Agile roles are implemented in most organisations. And it is the context within which the Agile BA must operate.

What the BA Brings to the Partnership

The BA's contribution to the BA and Product Owner partnership is analytical. Where the Product Owner provides the vision and the authority, the BA provides the structure, the rigour, and the translation. Translation is the core of it. The Product Owner speaks in terms of user outcomes, business value, and strategic objectives. The development team needs to work from specific, testable requirements. The BA is the translator between these two registers. They take what the Product Owner wants and convert it into stories, acceptance criteria, and backlog structure that the team can build from. This is not a passive activity. Good translation requires the BA to ask questions the Product Owner has not thought to ask themselves, to identify gaps in the vision before they become gaps in the backlog, and to maintain the connection between individual stories and the strategic objectives they are supposed to serve. A BA who only writes down what the Product Owner says is a transcriptionist. A BA who helps the Product Owner think more clearly about what they actually need is a genuine analytical partner.

The BA also brings continuity. Product Owners change. They go on leave, they move roles, they get pulled into other commitments. The BA who has maintained a clear, coherent backlog with well-documented rationale for every priority decision is the institutional memory of the product. When a new or temporary Product Owner steps in, it is the BA's documentation and context that allows delivery to continue without a reset.

What a Functioning Partnership Looks Like

A functioning BA and Product Owner partnership has a few observable characteristics that are worth naming because they give you a concrete target to work toward.

There is a regular working cadence between the two. Not just in ceremonies. A standing check-in, weekly or fortnightly, where the BA and Product Owner review the upcoming backlog together, discuss priorities, surface any concerns about story readiness, and align on the sprint goal before planning. This meeting is not a ceremony. It is the working conversation that keeps both roles in sync.
There is a shared understanding of what is in the backlog and why. The Product Owner can explain the priority logic. The BA can explain the requirements behind every story. Neither is surprised by what the other says in a planning session or a stakeholder conversation.
Decisions are made cleanly. The Product Owner makes priority calls. The BA makes requirements calls. When these areas overlap, which they regularly do, the two work through it together rather than deferring to each other or escalating unnecessarily. The team does not have to wait for the BA and Product Owner to resolve a disagreement in the middle of a planning session.
The Product Owner is visible in the ceremonies. They attend sprint reviews and engage genuinely with stakeholder feedback. They are present in refinement sessions when strategic priorities are being discussed. They make themselves available for questions that the BA cannot resolve alone. This visibility is partly about engagement, but it is also something the BA needs to actively encourage and support, particularly when the Product Owner is time-constrained.

The Three Dynamics That Break the Partnership

Role confusion: The most common partnership problem is unclear boundaries. The Product Owner and BA are both involved in requirements, both attend ceremonies, and both communicate with stakeholders. Without clear agreement on who owns what, duplication and conflict become the default.

The most practical resolution is a simple, explicit working agreement: the Product Owner sets the what and the why, the BA defines the how and the how well. The Product Owner decides which capability to build next and why it matters. The BA defines the specific requirements, acceptance criteria, and edge cases that describe what it means for that capability to be built correctly. This is not a rigid division, but it is a clear enough starting point to prevent most role confusion.

An unavailable Product Owner: Agile assumes a Product Owner who is genuinely available to the team. Many organisations assign a Product Owner who is also doing their day job, attending other meetings, and managing stakeholder relationships across multiple programmes. The practical result is a Product Owner who can give the team thirty minutes a week instead of the several hours that proper Agile engagement requires.

The BA's response to this should not be to fill the Product Owner role. That creates a different problem: a BA who is making strategic product decisions without the authority or the stakeholder relationships to make them well. The right response is to work with what you have. Prepare tightly focused questions for every interaction so that limited time produces maximum clarity. Document decisions and rationale so that each conversation builds on the last rather than starting fresh. And surface the availability problem to the Scrum Master and sponsor as a delivery risk, not as a complaint about an individual.

A Product Owner who bypasses the BA: Some Product Owners add stories directly to the backlog, without going through the BA's refinement process. The stories arrive at sprint planning unrefined, without acceptance criteria, without edge case coverage, and sometimes without a clear rationale.

The instinct is to let it go and fix it during planning. Resist that instinct. A story that enters sprint planning without proper refinement will either delay planning, result in a poorly defined sprint, or carry an unresolved requirements question into development. None of these outcomes serves anyone.

The conversation to have with the Product Owner is not a challenge to their authority. It is a quality conversation. Stories that have not been through refinement consistently cause problems during sprints. The refinement process exists to protect the team's velocity. When stories skip it, the team pays the cost. Most Product Owners respond well to this framing once they have seen the evidence.

When the Partnership Is Genuinely Broken

Sometimes the BA and Product Owner relationship breaks down in a way that cannot be resolved through working agreements and quality conversations. There is genuine conflict, a fundamental misunderstanding of roles, or a level of dysfunction that is affecting the team's ability to deliver. When this happens, it is a problem for the Scrum Master and the programme leadership, not just the BA and Product Owner. Escalating a broken partnership is not a failure. It is the right call. What matters is how it is escalated.

Frame it as a delivery risk, not a relationship complaint. Come with specific evidence: sprint velocity data, a list of stories that had to be re-refined, standup blockers caused by unclear requirements, stakeholders who stopped attending sprint reviews. Data is more persuasive than narrative, and it keeps the conversation focused on the project rather than the people.

The BA who brings this conversation to their Scrum Master or delivery lead with evidence, a clear analysis of the risk, and a proposal for how to address it is demonstrating exactly the kind of senior BA thinking that gets people trusted with the most complex programmes.

Go out and be successful.

Oluwatosin Ogunkoya | Flotog BA Insights | www.flotogbainsights.com

Tomorrow: Series Finale. Agile BA in your career, what mastery looks like at every level, six interview questions with model STAR answers, and the principles to carry forward into every Agile team you work in.