Product Owner vs Business Analyst: The Importance of Both

In the product owner vs business analyst discussion, it’s sometimes difficult to trace a distinct line between the responsibilities of a business analyst (BA) and those of a product owner (PO) on a software project. Both roles often have overlapping responsibilities that make it tough to tell where one ends, and the other begins. To muddy the line even further, every company defines what each role means per their internal needs and within the context of their individual organization. As such, a product owner might have more of a business analyst role in some companies, and a business analyst might include the role of product owner in others.

At MentorMate, we have a whole team of dedicated business analysts who we staff to projects that require them. In contrast, a representative of the client’s team usually serves as the product owner. Let’s settle the product owner vs business analyst debate by looking at each of these roles independently, and how they interact with one another on a project.

An effective business analyst is an excellent listener and communicator.

As a Business Analyst at MentorMate, I’m an inseparable part of the scrum team. My main goal is to help the developers gain a better understanding of the product requirements and the expected behavior of the product. To achieve this, I maintain the dialogue between the client, the project manager, the product owner, the Scrum Master, and the QA specialists.

Whenever I’m assigned to a new software development project, my first priority is always to understand the business domain of the client. I ask the right set of questions which helps me capture the client’s requirements. Immediately after gathering those requirements, I start analyzing them and breaking them down into small pieces of work like Epics, Features, and User Stories with Acceptance Criteria. All of those elements make up the product backlog, the incremental completion of which leads to the delivery of fully functional products and product features.

For projects that are a little more complex in their technical requirements, the MentorMate BA team has a Technical Business Analyst that we can assign to the project’s scrum team. Our Technical BAs have the expertise to analyze and document not only business processes and requirements but technical ones as well. These specialists bridge the gap between business problems and their corresponding technological solutions.

Product Owner vs Business Analyst: How Both Contribute to a Software Project’s Success

As previously mentioned, the roles of a business analyst and a product owner overlap a fair amount. They both require a very similar set of skills and their responsibilities complement each other well. At the end of the day, both are working towards the same goal: creating a valuable software product.

It’s important for both a product owner and a business analyst to be aware of each other’s key responsibilities. In many instances, a software development project will have either only a product owner or only a business analyst. This might happen because the project is rather small and there is no need for both, or because it is not part of the company’s strategy to split the responsibilities.

For example, MentorMate has a client who develops staffing software for recruitment agencies to manage and track applicants through the hiring and onboarding process. In my role as a business analyst on that project, I own the business requirements. My primary responsibility is writing the user stories in accordance with the gathered requirements. Based on that, the development team can better understand what the required behavior is of any given feature. 

However, our client is still adapting to the agile way of working, and scrum teams are still taking shape so I often find myself also in the shoes of a product owner. As the name suggests, the product owner owns the product. They are the go-to person to give guidance on what feature is in or out of scope or which feature should be developed next. 

In the case of our example, the MentorMate team is responsible for all of that. The client assigns a project to us and gives us the frame of the work that needs to be done. We decide the release priority for each feature and we make most of the decisions like scope change or feature functionality change. We inform the client of the changes, who then validates our decisions, and we move forward with the development. 

This approach gives us a lot of freedom and flexibility to be independent and move fast, as we are not dependent on a slow, multi-level approval process. 

In other MentorMate projects with different clients, a product owner would sometimes create user stories as placeholders to make sure they’re placed in priority order for the team to develop. In that case, a business analyst steps in and adds the acceptance criteria to ensure that the developed features meet the business requirements.

Product Owner vs Business Analyst: Final Thoughts

A clear split of responsibilities can only happen when each of the roles exists in a project, on a team, or in an organization. In any other way, a business analyst will have to play the product owner’s role and the other way around. 

Regardless of if the roles are filled by one or two individuals, all of the above-mentioned activities need to be completed for a project to be successful. Lately, more and more companies have come to understand the value of split responsibilities for both roles. That approach allows the product owner to focus on the product functionalities and future development. At the same time, the business analyst can focus on the requirements articulated by the business. The result is a successfully and efficiently delivered software product.

Photo by Kvalifik on Unsplash