Business analysis misconceptions of Product Owners

Published in

Serious Scrum

5 min readMay 28, 2023

In a previous article, I introduced business analysis-related techniques that can be used within product management or product ownership. When properly applied, practices related to business analysis discipline make Product Owners excel in their work.

Business analysis should be used for allowing:

1. Never losing sight of the bigger picture

2. Focus on the problem (Stakeholder management; Knowing the domain; Talking to users; and Problem-solving)

3. Aim for value

In the same way, business analysis practices, when applied badly, can become huge barriers to Product Owners’ work.

The most common way where business analysis is a barrier to Product Owners is when it’s applied in a traditional way — even though the discipline has adapted to an agile way of working. In my experience, the main examples include:

· Analysis paralysis

· Serving as clerks for sponsors

· Lack of collaboration

Let’s look closely at each situation:

1. Analysis paralysis

“This requirement is not yet detailed enough.” “It still needs to include some other user scenarios”

It’s already common sense that, when it comes to documenting needs or requirements, the business analysis work has abandoned the big specifications written upfront and that took some months to finalize (a.k.a. Requirements Specifications document). Rather, what is written is much more light-weighted — for instance, a group of user stories.

However, even though the usage of, for example, user stories, many times they are applied with the same upfront mindset as the Requirements Specifications document.

Common examples include teams only starting working when all Product Backlog Items (for the sake of this example, in the form of user stories) are written, or when these product backlog items take too much time to be shared with the team and include all there is to know about that item (they aren’t user stories anymore, but user novels — they have a description, acceptance criteria, never-ending list of usage steps, mock-ups, diagrams from different types, etc).

A common trap that Product Owners fall into (myself included) is thinking that if we write all down and follow the known formats, the message is passed on perfectly. Many times, my concern during writing the product backlog items was to clear it all up so that the team couldn’t have any questions before or during the development. If they don’t have questions, I did an excellent job, right? Right? Or should they ask questions?

But the issue doesn’t come every time in communication from a PO to the team. I have also experienced a communication issue in the opposite direction.

During a Refinement of some items with the team, I was presenting an item to the team and was able to refine the item to at least 3 different user scenarios. A team member kept asking for other user scenarios that in his opinion were worth discussing about the item and that, without those scenarios, the item shouldn’t go forward to the Sprint Backlog. I had to solve those issues with the customers and come back again — sometimes weeks after.

It’s a case of analysis paralysis triggered by the team members, where perhaps they could have started working on that item without those additional scenarios.

Turn it around: don’t focus on thinking about every tiny detail before a backlog item can be included in the Sprint backlog. Many details are uncovered within an ongoing Sprint in a conversation with a team member (e.g., they reach out to the PO to clear a doubt, and the “new” detail is only uncovered then. But, on the other hand, is addressed immediately).

2. Serving as clerks for sponsors

When “gathering” requirements, the job, most of the time, focused on attending meetings where they interviewed a group of people. Typically these people had significant roles in the product (although most of the time they wouldn’t be the future users of the solution!) and the Product Owners would simply be a clerk and register all their dictated “wishlist” items.

Both these approaches are based on the premise that your sources know what they need and dictate the solution. With the emergence of agile development methods and the shift from a project to a product mindset, efforts are now split into product discovery and delivery.

And the main shift on the premise of product delivery is that teams have to discover what are the user’s problems based on a set of assumptions and validate if a delivered solution contributes to the desired outcome. For Product Owners, this means being involved in both discovery and delivery, but for doing the discovery there has to be a shift in how they elicit and manage the requirements. They have to discover the right requirements rather than gather them based on one person’s point of view.

Turn it around: Every elicitation activity must focus on solving a problem rather than pointing to a solution. Applying product discovery techniques helps in focusing on the problems that are most valuable to the customer. They have to discover the requirements rather than gather them.

Pay a visit to your customers or users. The observed process is (almost) never as linear as initially described. The practice of “Go and See” is still highly applicable. Stand together with the users and identify pain points and points for improvement by simply observing or asking this directly.
In doing interviews, questions should focus on users’ past experiences with the product and the pain points during the process, instead of focusing on what customers want.
Story mapping allows focusing on sequencing users’ activities, thus focusing on the users and their pains, rather than the sponsor’s wants.

3. Lack of collaboration

Just like in an old-fashion waterfall manner, some professionals gather their requirements, isolate themselves to document the requirements, and then present them to the team. But, instead of presenting a detailed software requirements document, they present a big product backlog full of backlog items and their acceptance criteria.

Turn it around: don’t isolate yourself. Present the main ideas of the requirements to the team right after you acknowledge the requirements’ existence. For detailing them, don’t burden yourself with writing them all at once.

First, not all backlog items have to be written upfront. Focusing on the ones you predict the team should work on in the upcoming 2 to 3 Sprints is enough.
Then, writing the backlog items in collaboration with the team is far more useful — not to mention, far more fun! Collaborating this way assures that other perspectives are considered as well — technical, user experience, etc. The Story Mapping technique is a good suggestion. Story Mapping is used to assist in creating an understanding of product functionality and the flow of usage. The way it places user stories in their usage context allows prioritizing and sequencing their delivery within the big picture.

Conclusions

Many business analysis techniques can be applied in Product Owner’s daily work, and do good for them. However, they can be very harmful if applied badly. The most common situations I witnessed relate to analysis paralysis, serving as clerks for sponsors, and the lack of collaboration with the team.

Product Owners must focus on understanding the customers’ problems, needs, and behaviors, and then creating solutions that address these issues. In this sense, I shall reinforce the idea of business analysis used for:

1. Never lose sight of the bigger picture