When a large enterprise begins its agile transformation, a moment almost inevitably arrives: someone asks, "so what happens to the BAs now?"
The answers usually fall into two categories. One: "the BA becomes the product owner." The other: "the BA stays, but now works with an agile methodology." Both answers are partly right - and partly exactly the misunderstanding that stalls many agile transformations in financial services.
Over the past few years at FrontX, we have stepped into several projects where the confusion between BA and PO roles caused most of the problems. Not technical debt, not poor architecture, not slow developers. Role confusion.
In this article we look closely at the difference between the two roles, when you need which, and what happens when they are confused.
What is the real role of a business analyst?
The business analyst owns the business requirement. That sounds simple, but in reality it is an extremely complex task.
A BA's job isn't writing documents - the document is just the tool. A BA's real work is uncovering the need behind the business request, identifying the processes and systems involved, and articulating requirements precisely enough that developers and testers can work from them without ambiguity.
On an insurance project, for example, the BA doesn't just record that "the customer must be able to submit a claim online". The BA uncovers how many departments the claims process touches, what data has to be validated, which systems need to be integrated, what exception-handling rules apply, and how it fits into the existing contact centre process. That isn't one meeting's work - it is weeks of analysis, stakeholder interviews and process mapping.
What a BA doesn't do - at least ideally: prioritise the development backlog, make business trade-off decisions alone, or run sprints.
What is the real role of a product owner?
The product owner owns the product. In an agile framework - with Scrum as the basis - the PO is the one person who decides what the team builds and in what order.
The PO manages the backlog, prioritises and makes decisions. When developers have to choose between two features, the PO decides. When stakeholders bring new requests at the end of a sprint, the PO filters and prioritises. It is a responsible, decision-making role.
What a PO doesn't do: write detailed specifications, carry out gap analysis or document processes. The PO defines what needs to be built - but not necessarily exactly how it should work.
This is where the boundary between the two roles is sharpest: the BA owns the question of how it should work, the PO owns the question of what we build now.
Where the two roles merge - and why that is dangerous
The problem isn't that the roles overlap. Some overlap is natural and healthy. The problem is when one person stands in place of both roles - alone, with both responsibilities.
In financial services this is especially critical, because the complexity of business processes demands in-depth analysis. When launching an insurance product, you can't postpone detailing the requirements until the sprint review. When integrating a banking core system, you can't work on a "we'll find out along the way" basis.
We regularly see three specific symptoms at clients where BA and PO roles are mixed up:
Symptom one: developers don't know whom to ask. If a developer has a question about business logic and it isn't clear whether to go to the BA or the PO, delay or misinterpretation inevitably follows. In most cases the developer asks whoever is easier to reach - who doesn't necessarily give the right answer.
Symptom two: the specification is incomplete, because "we'll find out in the sprint". This is the most common misunderstanding of agile. Iteration doesn't mean you don't need to think ahead - it means details can be refined. But the core business logic, process boundaries and integration points must be clear before development starts.
Symptom three: testers don't know what the expected behaviour is. If the QA team can't derive test cases from the specification - and instead writes its own interpretation or asks developers "is this right?" - the requirements aren't concrete enough. That isn't a testing problem. It is a BA problem.
When do you need a BA, when a PO - and when both?
There is no single right answer, but there is a usable decision framework.
A PO alone is enough when: the product is well defined, the business need is clear, the team knows the domain, and projects move forward in short, low-risk iterations. Typically: internal tools, iterations on well-known B2C products.
A BA is definitely needed when: several business areas are involved, there are compliance or regulatory requirements, the system integrates with existing legacy systems, the project runs longer than three months, or the client doesn't know exactly what it wants - only what it wants to achieve. That covers the vast majority of financial services projects.
Both are needed when: you are in a larger agile transformation that requires both in-depth analysis of business needs and continuous prioritisation of the development backlog. In this case the BA and the PO aren't competitors - each is incomplete without the other.
The most effective set-up we have seen at FrontX: the BA uncovers and specifies the need, the PO prioritises it and plans it into the sprint. The BA is there for questions that arise during implementation; the PO is there for stakeholder alignment. Not competition - a division of labour.
What this means at FrontX in practice
When we join a project at a large financial institution, one of our first questions is: who is the BA and who is the PO - and do they understand each other's roles?
If the answer is "one person does both here", that isn't necessarily a problem - but it must be managed deliberately. One person can't analyse in depth and prioritise continuously at the same time. One of the two suffers.
FrontX BAs don't hand over the document and move on. They are there during implementation, at the first demos, and when testers find the first inconsistency in the specification. Because that isn't a failure - it is a natural part of the job.
If you are looking for a senior BA who understands financial services processes - or if you are a BA who wants to work on serious projects where your role really matters - see how we work: frontx.hu/en/careers
Frequently asked questions
What is the most important difference between a business analyst and a product owner? The business analyst owns the discovery and documentation of the business requirement - answering how it should work. The product owner owns development priorities - deciding what we build now. In a healthy agile project the two roles complement rather than replace each other.
Can one person be both BA and PO? On small projects, yes - but in large organisations and complex financial processes it is risky. When one person fills both roles, one area suffers - usually in-depth analysis and specification.
When does an IT project need a business analyst? Definitely when several business areas are involved, when there are compliance or regulatory requirements, when the system integrates with legacy systems, or when the project runs longer than three months. On most financial services projects all of these apply.
How can BA-PO role confusion be resolved in a large enterprise? The first step is to define the roles explicitly and communicate them within the team. The second is to make it clear in every decision who is responsible - clarifying the business requirement belongs to the BA, prioritisation to the PO. If the organisation has no experienced BA, bringing in an external senior BA resolves the situation quickly.
What do FrontX BAs do differently? FrontX BAs don't hand over the document and move on - they are involved throughout implementation. Every FrontX BA has a financial services background, so insurance, banking or leasing processes don't need explaining. That means faster specification and fewer misunderstandings during development.
László Behán is Managing Director of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development at Groupama Biztosító and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services. LinkedIn profile | FrontX insights
