Business analysis in Product Ownership is much more than eliciting Product Backlog items
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. If one thinks that business analysis only applies in Product Ownership by eliciting and writing down Product Backlog items and acceptance criteria, then it will never achieve its full potential. This article explores practices from my business analysis background, where known business analysis reference guides provide added value to improve Product Owners’ accountability — and at which the job of writing Product Backlog items will be the ultimate output of the business analysis worked until then.
Business Analysis and Product Ownership are collaborators rather than conflicting. One example of this kind of collaboration is proposed in the 4-Quadrants of Product Ownership, where 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.
I believe that this is a limited perspective of the value that business analysis brings to Product Ownership. The adoption of business analysis techniques depends on the place (if there is one) of a business analyst in the product team. There are cases where Business Analysts embraced product ownership as the next step of their career. There is also the case where Business Analysts and Product Owners co-exist and collaborate together. Finally, it may be the case where Product Owners have no business analysis background — and for whom this article may be of good use.
Through my business analysis experience, I saw many business analysis knowledge domains and techniques that strengthen product ownership to be present in the reference documentation. The guides referred to in the article are not of free access, and it’s not my intention to make this a sales pitch. I used the guides since ever in my business analysis career, and shifting my mindset to product ownership didn’t make me use them less. the guides are - but are not limited to - the following:
- 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®)
So, how do these reference guides help Product Owners?
1. To help prepare the upcoming iterations
When the business analysis quadrant of product ownership was introduced above, it was 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.
A Product Owner works closely with the team to deliver Sprint Backlog Items but doesn’t lose sight of the Product Vision and the roadmap — if existing. It always helped me the principle of “See the Whole” from the Agile Extension of the BABoK, which suggests an analysis of the need in the context of the big picture. Thus, the goal is not to focus on the daily work or the current iteration (or Sprint), but to always be aware of the product vision, product (or organizational) goal, and envision how the next iterations will deal with that.
In order to understand the big picture, there had to be a combination of analyzing the system but not falling in the trap of over-analyzing it. Reference guides also include techniques like Story Mapping (ie, how the user stories address your problem. See here for more) and Scope modeling or Context diagrams (ie, what’s in and what’s out. See here for more) to be aware of what composes our problem. I use Story Mapping within my product discovery to figure out the order through which problems are addressed (in several Sprints). I use Context diagrams at the beginning of a project or when I join one, for a clear sight of the problem’s ecosystem — it may also help decide if a given feature is in or out of scope.
2. To prevent jumping to the solution instead of solving a problem
Every consulted documentation suggests focusing on the problem rather than jumping to a solution. Business analysis practitioners are introduced in their community as problem solvers. In the guides mentioned in the article, there is an overall goal of shifting the idea that performing business analysis is acting as a clerk for only taking orders but rather figuring out what is needed to solve the problem. My business analysis background has taught me that some problems are complex enough that there are multiple solution options that can all deliver the same outcome. Through business analysis, one 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.
What exactly does this mean? During interviews (see point no.5), the interviewees have the tendency to jump to suggesting solutions (e.g. they ask for a specific button, a given column from data, or even the use of some API). One could easily just write Product Backlog items based on those proposed solutions. However, the reference guides have taught me that we should focus on understanding the problem first, check the existing solutions out there, discuss each possible solution with the team and stakeholders, and write Product Backlog items based on the solution decided together. Most of the time, since at the time the assumptions were yet to be validated, the solution adopted was one that required the least effort to implement.
3. To figure out which stakeholders are a source of requirements
Not all stakeholders that interact with you will (or should) make requests to be added to the Product Backlog. Some will have more interest in submitting such requests, while others will be more interested in the project’s progress. Just like the Context diagram, I classify stakeholders in the beginning of a project or once I join one. To identify them first, I follow techniques from the guides such as Job Analysis or Persona Analysis (ie, fictional characters to represent a user or stakeholder. See here for more). They are efficient, and not heavy, to help that no class of stakeholders was skipped during the initial stakeholder analysis.
Stakeholders will have different interests but also different levels of influence, so depending on the output of the techniques such as stakeholder map (more here), RACI matrix (more here), and onion diagrams (more here), they can be a source of requirements or not. Personally, I use more the stakeholder map. It’s a document to have close by when I need to discuss any particular requirement or any topic related to the delivery of a Product Backlog Item.
4. To help identify which problem is worth solving
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.” (IIBA®, Guide to the Product Ownership Analysis, p.5)
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 one to accompany and observe people performing their work and learn about the process first-hand. The guides describe many types of Observation that exist and how to perform them properly.
Whenever possible, I sketch up learnings from applying these techniques in a Process model. It may be used also to document the “as is” process. Personally, understanding a process model (and combined with Story Mapping, from point no.1, and the Customer Journey Map, from point no.5) is useful for me to make sure the Product Backlog Items that were written support all the process’ steps.
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.
5. To engage closely with 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.
For example, from the Observation (point no.4), I used to document my learnings through the Process Model. But the model alone didn’t reflect user’s pain points during the process, only its steps. I later added the Customer Journey Map technique (as per the Guide to the Product Ownership Analysis). This technique reveals the customers’ experiences and motivations when interacting with a specific brand and products at various touchpoints (see more here). I personally use it as it is not time-consuming because it doesn’t require extensive modeling.
Whenever possible, I include the Empathy map technique (also as per the Guide to the Product Ownership Analysis). This technique is used to gain deeper insight into the experience and emotions of customers, showing how to get into the hearts and minds of customers (see more here). I don’t consider the Empathy map to give insights on the inputs for writing Product Backlog Items. Rather, this model is great for building good relationships with customers, which will reflect on better interviews for discovering the right requirements.
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.
6. To assure the right value for the organization is targeted
For every ongoing product/project/initiative, business analysis makes sure they still make sense and add value to the organization. Just like the See the Whole (point no.1) for “pleasing” the stakeholders’ and customers’ needs, it must also be considered the need to “please” 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 customers’ expectations, the organization itself and the outside environment.
For the alignment with the business goals, the technique of Impact mapping (see more here) is a visual approach to depict the value creation (the why) instead of feature development from a product/project/initiative (the what). Differently from having which Product Backlog Items have been delivered, Impact mapping shows which business goals are being solved each time Product Backlog Items are delivered. I find it useful in demonstrations of a delivered increment, or any project progress-related meeting with stakeholders.
Conclusion
In summary, there is much business analysis involved in product ownership beyond writing Product Backlog items and acceptance criteria.
In fact, to be able to write them down, many business analysis techniques allow proper preparation to get the most out of Product Backlog items that you will write after.
This article described business analysis techniques to:
1. Help prepare the upcoming iterations
2. Prevent jumping to the solution instead of solving a problem
3. Figure out which stakeholders are a source of requirements
4. Help identify which problem is worth solving
5. Engage closely with users
6. Assure the right value for the organization
