Business analysis tips for effective Product ownership
A view from business analysis reference guides
It’s not new that a good application of business analysis practices (traditional or agile) helps Product Owners improve their day-to-day work. From working closely with the team on a daily basis, to see far better “the forest through the trees” at a roadmap and an organizational level. This article explores practices proposed by the International Institute of Business Analysis (IIBA®) that make Product Owners excel in their work.
Business Analysis and Product Ownership
By the time agile started kicking in for teams that were working in a waterfall setting, one of the topics discussed at the time was the “disappearance” of the Business Analyst (BA) role. Because most frameworks didn’t include such role. But also because the job of BAs focused on gathering requirements upfront, and writing heavy documents didn’t make any sense anymore.
Also, Product Ownership started being seen as the natural next career step for BAs — just like it was, in the past, that BAs would “evolve” into Project Managers. And, in fact, it is a great possibility. It’s just not the only possibility.
There is also another possibility, where BAs partner with POs to collaborate in developing great products. The company where I work adopts this collaborative model, for example.
If collaboration is not an option in the work setting, then POs have a lot to gain in adopting the BA’s way of working, techniques, and mindset.
In the 4-Quadrants of Product Ownership , Business Analysis stands together with Product Management, Project Management, and Leadership. The BA quadrant is presented concerning the elicitation of User Stories and Acceptance Criteria, and how they partner with the team, with the testers, and most importantly with the customer.
Using business analysis knowledge domains and techniques that strengthen product ownership is present in reference documentation, for instance:
- Guide to the Business Analysis Body of Knowledge (BABoK) version 3 (from IIBA®)
- Agile Extension of the BABoK (from IIBA®)
- Guide to the Product Ownership Analysis (from IIBA®)
- Business Analysis for Practitioners (from PMI®)
Using proper business analysis domains and techniques
Now, let’s deepen the knowledge areas and techniques. Mainly, product management or ownership should use business analysis within the following points:
1. Never lose sight of the bigger picture
When we introduced the business analysis quadrant of product ownership, we mentioned the tendency to focus on the elicitation of User Stories and Acceptance Criteria. But focusing too much on that may lead to a misfocus on solution specifics.
The principle of “See the Whole” from the Agile Extension of the BABoK suggests an analysis of the need in the context of the big picture, focusing on the business context and why a change is necessary. Here, the value of the solution is created by gaining an understanding of the context, the solution, and the stakeholders.
The Story Mapping technique is already commonly used among Product Owners. 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.
Techniques like Scope modeling or Context diagrams also allow early discussions on the main (business) events — ie, prior to the solution events — and external entities that surround our problem.
2. Focus on the problem
Every consulted documentation suggests focusing on the problem rather than jumping to a solution. Business analysis practitioners are introduced as problem solvers. Some problems are complex enough that there are multiple solution options that can all deliver the same outcome. The principle of “Analyze to Determine What is Valuable” from the Agile Extension of the BABoK suggests that, through business analysis, we should be able to:
- identify solution options worth considering for implementation,
- work together with the team to determine whether each option is viable or not, and
- recommend the solution options based on which solution option provides the maximum outcome with the minimum output and fits within identified constraints.
This is a big one, so we can also cut it into sub-topics.
2.1. Stakeholder management
Managing stakeholders is a crucial thing in the business analysis world. Starting from the fact that stakeholders are a key item from IIBA’s Business Analysis Core Concept Model™ (BACCM™). As defined in the BABoK Guide, stakeholders are the ones receiving value from the change that is enabled by business analysis.
Dealing with stakeholders can be a complex task. The list of stakeholders and how to engage with them can vary if you work with them in multiple horizons — the Agile Extension of the BABoK present the Strategy, Initiative and Delivery horizons. All reference documentations for business analysis consider stakeholder management as critical tasks. To identify them, they suggest techniques such as Job Analysis or Persona Analysis. For managing the ones you identified, they suggest techniques such as stakeholder map, RACI matrix, and onion diagrams.
These techniques will provide a clear view for answering questions like:
- “Who is able to submit requirements?” Stakeholders will have different interests but also different levels of influence, so depending on the output of the techniques such as stakeholder map, RACI matrix, and onion diagrams, they can be a source of requirements or not.
- “Which communication style is proper for whom?” The language used (formal, informal, technical, non-technical), the periodicity, and other aspects are part of a Business Analysis Plan that both IIBA’s BABoK and PMI’s Guide use to define how all business analysis work and deliverables will be done.
2.2. Know the domain
The Guide to the Product Ownership Analysis has an interesting statement right in its early pages:
“The biggest risk of product development is to create a great product that nobody wants.”
Business analysis allows learning about the problem or opportunity to adequately understand the situation. Both the BABoK and the PMI Guide include techniques for easing such learning.
Through Document analysis, it is possible to review the existing documentation about current processes, methods, or systems that support the business. This is typically the first action to a newcomer in the domain.
Observation is a key technique that allows to accompany and observe people performing their work and learning about the process first-hand.
Process modeling may be used to document the “as is” process. It serves as an output of the two previous tasks.
This learning process can’t be concluded if users are not involved. But there are so many different forms of involving them, that they need a separate topic.
2.3. Talk to users
Never, ever, stick only to requests submitted by stakeholders. Get off your seat and talk to users. Understand their problem. The Guide to the Product Ownership Analysis has an entire domain about how to “Cultivate customer intimacy”. It’s about knowing as much about your customers as possible, and strongly advocating for their needs throughout product-build activities, in order to build a product that resonates with them.
The Customer Journey Map technique (as per the Guide to the Product Ownership Analysis) reveals the customers’ experiences and motivations when interacting with a specific brand and products at various touchpoints.
The Empathy map technique (also as per the Guide to the Product Ownership Analysis) allows gaining deeper insight into the experience and emotions of customers, showing how to get into the hearts and minds of customers.
These two examples may be the starting point for other business analysis work. For example, this will give you better tools to know your users and assist you when you develop your personas.
Other great tips to talk to users come from “Continuous discovery habits” (book by Teresa Torres” and from the Mom Test (book by Rob Fitzpatrick). Very briefly, both books show how to engage with customers and their problems through insightful interviews.
2.4. Problem solving
After analyzing the problem, the goal of business analysis is to propose solutions by means of the analysis’ outputs. The BABoK and from the PMI Guide include several techniques through analysis and modeling (for example UML and BPMN diagrams) that help with that.
One facet of business analysis is the process analysis, where techniques as Process Modeling (from the BABoK and from the PMI Guide) help understand a business process. Another example of applying process analysis is the Customer Journey Map technique (as per the Guide to the Product Ownership Analysis). Value stream mapping is a visual technique (which is described in the Agile Extension of the BABoK and the Guide to the Product Ownership Analysis, but has been presented to the world from the lean manufacturing community) to identify necessary improvements to the business process and to depict how the value stream will look like after the implementation of the improvements.
Another input is from analyzing and suggesting answers to complex problems. Namely, the Agile Extension of the BABoK proposes techniques aiming to reduce complexity by breaking down systems and ideas. One example is the modeling technique of Functional decomposition (from the BABoK and from the PMI Guide). From the Agile Extension of the BABoK, the technique of Story decomposition. Here, this technique is used within Backlog Refinement activities. The goal is to split large items into smaller ones that meet the INVEST criteria, where, for example, as per the Agile Extension of the BABoK, one may use for decomposing epics to stories.
3. Aim for value
For every ongoing product/project/initiative, business analysis make sure they still make sense and add value to the organization. The Agile Extension of the BABoK has an entire horizon focused on the alignment with the organization’s business goals, the Strategy horizon. In this horizon, analysis targets customer’s expectations, the organization itself and the ouside environment.
For the alignment with the business goals, the technique of Impact mapping is a visual approach to depict the value creation (the why) instead of feature development from a product/project/initiative (the what).
Another way is to analyze the relationship between business objectives and solution requirements. As the BABoK and the PMI Guide define different types of requirements — business, stakeholders, solution (functional and non-functional), and transition requirements — they all have relations between them. So eliciting and documenting these requirements, in addition to manage their relations in a traceability matrix, allows analyzing how each solution requirements (or feature) contributes to targeting the business need.
Conclusion
In summary, there is a lot of business analysis-related techniques that can be used within your product management or ownership.
Business analysis should be used for allowing:
1. Never lose sight of the bigger picture
2. Focus on the problem (Stakeholder management; Know the domain; Talk to users; and Problem solving)
3. Aim for value
This is my perspective on how some of the reference guides from the business analysis discipline — from the IIBA® and PMI® — are useful contributions for improving product ownership tasks.
The proposed guides encompass more techniques than the ones here presented, which can improve the product ownership role. Also, besides these institutions, there are guides from other institutions, as well as books and articles from other authors, that provide similar value as the ones presented in this article. Check out guides from institutions such as International Requirements Engineering Board (IREB®), International Qualifications Board for Business Analysis (IQBBA®), or British Computer Society (BCS®). Some examples of authors with books and articles are Allan Kelly, Howard Podeswa, Angela Wick, Fabricio Laguna, James and Suzanne Robertson, and Kent McDonald.
The goal of the article is to present possible viewpoints on the potential contribution of business analysis. As each point was only described briefly, some articles focusing on each one may come in the future.
