Product Owner Vs. Business Analyst: Who’s the Agile Superhero in a Low-Code Environment?

As an Engagement Manager at OutSystems, I’ve embraced the mission of helping customers maximize the results of agile approaches with our low-code development platform. And a question that I often get is: in an agile team, what's the difference between a product owner and business analyst, followed by, is there a need for having both these roles for a successful project?

I can't give you a short answer to the first one, but I can give it to the second question: it depends. I’ve seen agile projects with business analysts acting as product owners succeeding, but I’ve also seen projects without a designated product owner failing. 

That’s because every agile development project comes with its unique set of challenges. It’s funny how we tend to forget about that. At the project start, sometimes the scope is not clear. Sometimes the timeline is challenging, or even unrealistic. And other times, the right team members are not in place to help ensure the project’s success. Sometimes it’s all three.

In the world of agile, success falls heavily on the ability to communicate efficiently and effectively. Breakdowns in communication can lead to poor results, such as:

• Deliverables missing key features
• Deliverables missing key functionality within the features
• Deliverables including undesired additional features and/or functionality
• Deliverables that are lacking in quality (buggy)
• Project delays

The need for having a product owner, a business analyst, or both depends on the particularities of each project. So, if the questions I shared above have ever crossed your mind, fear not. In this blog post, I’ll discuss what’s the role and responsibilities of the product owner and the business analyst, and if and where these two roles intersect.

He or she can help provide the vision of the product without having to worry about how it is technically implemented. And s/he serves as a voice from the business side, a single point of contact to get alignment, clarify questions, reach consensus, and drive decisions.

The PO is frequently associated with scrum practices, but to stay focused I’m not going to get into the differences between agile and scrum here.

While the PO is on the business side of the fence, the BA is more likely to be on the technical/agile team side. They are usually trained in technical analysis and design, which makes them less business knowledgeable than the PO but more technically skilled.

What’s the difference between Business Analyst vs Product Owner?

Simply put, the PO is the voice of the customer, and the business analyst acts more like the representative of the development team. But, full disclosure: the division between these two roles is not that black and white.

The PO is more business and customer-oriented, while the BA is often more tactical and focused on the project. But given the training and skills of a typical BA, they're usually also qualified to undertake some of the tasks of the PO. This includes most of the backlog management functions, breaking large stories into smaller ones, modeling workflows and data, define business rules, and address non-functional requirements. For that reason, these two roles often overlap.

Business Analyst vs. Product Owner: roles and focus. 

So this begs the question: do you really need these two personas for a successful agile adoption? Can’t the BA replace the PO? In the next section, I’ll share a few real-life examples in an attempt to answer this question.

Product Owner: The Real Agile Superhero?

I recently met with a coworker who has a long history of delivering successful agile projects. She recalled working on several projects over the years without a PO, and shared the following experience:

“[On one project,] we were re-writing an existing app built using another technology. The customers thought that since we were just migrating an app from one technology to another, there was no need to have a PO.

They believed that analysis and reverse-engineering of the current apps should have been enough to build the new ones. Due to delays gathering the information needed from different channels, sprints usually were not ready when they started, user stories were blocked during the sprint, and assumptions had to be made. This caused rework later and [negatively] impacted the delivery.”

The reality is that an agile team will be challenged to bridge the business side of the project without a PO. The project vision, key drivers, and success criteria may be non-existent or ill-defined, or they could be defined based on the IT perspective and not the end user’s. Ultimately, the PO increases the value of the product by bringing insight to what the product is trying to achieve.

The same coworker also remembers working on projects with ineffective PO’s as well:

“[We had] one project delivering an HR Onboarding and Offboarding app. The client Project Manager tried to be the PO for this app. The first release was a total flop because it didn't meet the needs of the end-users. The various end-user teams ended up delegating one person from their team to provide input to the PM, and the app became a big success after several more releases.”

In the first example, no one stepped up, and the project suffered. In the second example, the PO was ineffective, but the team took the right steps to address the issue. The takeaway from both of these examples is that there needs to be a dedicated individual (or individuals) from the business side that is able to provide insight, commitment, and communication for the business. He or she should be able to provide the vision for the app. If that’s not possible, then s/he needs to be prepared to work with team members who can help them define the vision to address the underlying business need.

In a positive example, another coworker remembers a highly successful project that started without a PO. She recalls,

“The QA department wanted to save time, improve SLAs, and have increased oversight over their work but didn't have a minute to spare. We trained one of their admins to be a BA, and they became the de facto PO, who was responsible for gathering and clarifying requirements. [As a result] this app was highly successful, and we had metrics of how their SLAs improved with the new process and app.”

The takeaway here is the same. It is possible to get good results from an agile team without a PO. The BA can indeed replace it, as long as s/he able to step in as the superhero and play the PO role. However, it’s going to require some helping hands, commitment, attention to detail, and good communication. The key to success is understanding the context of the app and the underlying business need. To accomplish this, the business needs to be able to identify key users and stakeholders and ensure they are readily available to help provide that context. They should be able to verbalize their wants, needs, and current pain points. Only then can the project team begin to extrapolate the value that the business is seeking.

Final Thoughts

In the end, having an experienced PO will certainly benefit an agile team. He or she should be able to do everything mentioned above, in addition to providing clarifications and driving decisions. The result should be a more efficient team and a more effective product. Incorporating feedback from key users into the product is a top priority.

If the PO does not have proper domain knowledge—the case of the BA— then he/she must be able to identify these key users (or work with the business to identify them), collect as much information as possible, and ensure that it gets worked into the product. It’s all about understanding the context of the app and the bigger picture. Add in commitment and good communication, and you’ve got your agile superhero.

In the meantime, if you want to learn more about the technologies and approaches that companies with higher levels of agile maturity are investing in please take a look at the State of Cloud Application Development Report.