Modern Elicitation for Business Analysts that work in product discovery
If you are working on products, you have realized product management handles requirements in a different way. When a business analyst or a product owner is eliciting requirements, there is a shift from eliciting stakeholders’ wishes to discovering better and faster ways to solve stakeholders’ problems. This article presents how discovery techniques, popular within product management, fit in business analysis areas of elicitation, analysis and validation. Also, we will see where they fit as well as in the three types of requirements: business, stakeholder and solution. Understanding where the techniques fit in this spectrum will allow a better understanding of how and when to use them.
What is a product discovery and how it works
Putting it simply, product teams split their efforts into product discovery and delivery. For delivery, agile development methods contributed to frequent releases to the market. Such release will be often the resulting output from an initial product discovery. This means that product discovery will uncover problems and propose solutions, in the form of product features. Those features will pass from ideas to real life during the product delivery.
One could think that the road could end up there, but it’s never enough pointing out that after the delivery, it is essential to take learnings from it. Namely, if our assumptions were correct and those features indeed solved the discovered problem, and also if it was in fact a problem worth solving.
On this continuous discovery spirit, some techniques arose in the product development world: Jobs-To-Be-Done (JTBD), Continuous Customer Interviews, Mom Test, Opportunity Solution Tree, Story Mapping, and Epic Alignment. I have written an article that can be found in BA Digest Q3 of 2023 that presented them as modern requirements techniques.
Jobs-To-Be-Done
Another recent approach for defining the problem is “Jobs-To-Be-Done” (JTBD). JTBD encourages us to appreciate why a product or service was “hired”, including not only the functional dimension, but also the circumstances and emotional dimensions. The book “Jobs to be Done — Theory to Practice” by Anthony Ulwick describes a framework that you can use to define your jobs, from setting your different customers, the different kinds of jobs (core, related, emotional, consumption chain and purchase decision jobs), and setting the desired outcomes.
The behaviors of the customers that afterward lead to the definition of the “hired” job are identified by observation. Observation is a common elicitation technique. In this case, rather than observing (or shadowing) in order to replicate a given process, an observation within JTBD aims to relate a behavior to a customer’s outcomes. It is used to define afterward the strategy for achieving the customer’s outcomes, thus the output — i.e., the job(s) — will be treated as a set of business requirements.
Continuous Customer Interviews
Teresa Torres described a set of “continuous discovery habits” to engage customers in a continuous cadence. The main shift in doing interviews is that questions don’t focus on what customers want. Rather, questions should focus on their past experiences to discover an opportunity. Below it’s a template for the interview notes from Pawel Huryn, based on the suggestions of the intended outputs of these interviews by Teresa Torres.
As the name states, it uses interview techniques. Once more, a very popular way to perform elicitation. As mentioned, the main shift is that questions that are asked focus on their past experiences to discover an opportunity. Each interview will focus on opportunities for a user, thus the opportunities that arise will deal with user/stakeholder requirements.
The Mom Test
Interviews only have value if we can depict the problem in question, rather than telling us the solution interviewees want. That is the premise of the Mom test, by Rob Fitzpatrick: your mom will always like your idea, but doing the right questions can make her tell what you really need to hear to succeed. So, the Mom Test is another interesting approach for conducting stakeholder interviews. It has similarities with “Continuous Discovery Habits”. The questions should focus on their past experiences to discover an opportunity.
Just as continuous interviews, the same classification applies to the Mom Test. It’s a way to perform elicitation based on interviews, depicting user/stakeholder requirements.
Opportunity Solution Trees
The insights from conducting continuous interviews should allow us to identify opportunities for our product. Another habit from “continuous discovery habits” is opportunity solution trees. Opportunity solution trees are a vizualization of potential solutions to a customer problem. They involve breaking down the problem into smaller opportunities, generating multiple solutions for each opportunity, and then evaluating and selecting the most promising solution.
In our requirements process, it shall be noted that the opportunity solution tree is a model that uses insights from conducting interviews. Thus, it is part of requirements analysis and it’s a model that will deal with user/stakeholder requirements.
User Story Mapping
User story mapping is a popular technique in the business analysis, product ownership and product management communities. The method consists of sequencing the user’s activities, and allows further elicitation to take place so that detailed stories and tasks can be captured. This in turn ensures that the solution will support the user’s activities that were presented.
Classifying this technique in a single stage can be tricky. I believe it encompasses elicitation, analysis and validation of requirements. It’s a technique where team members collaboratively discover how a set of user stories solve a customer problem.
End users may be involved in the collaborative process as well, most probably giving inputs in the user journey and the sequence of activities — which makes it an elicitation technique. Sequencing activities may be an output of previously performed elicitation, like observation, interviews, or document analysis, so the further sequencing of user stories and tasks results from the analysis of that information.
Lastly, acceptance criteria may be included in the details of the story mapping, which forces the team to start stepping up into the requirements validation. In the case of users not taking part in the collaborative process, the model may be used to validate together with users that the user journey is indeed correct.
Concerning the type of requirements we are dealing with, the part with activities and stories relates to user/stakeholder requirements. However, the model that results from this technique typically will have a bigger part regarding the details as tasks to be performed. And those details are to be dealt as solution requirements.
Epic Alignment
“Epic alignment” is from Nils Janse’s book of the same name. It proposes a single source of truth about the requirements, in the form of “lightweight” documentation based on epics. The structure of documents (see figure below) includes information that is added over time to what we know about a given epic, throughout the product development stages of Ideation, Discovery, Priorization, Refinement, Development and Testing.
The structure of these documents allows us to follow the information about an epic, which user stories are included, and the details that are needed for their implementation. There is no doubt about it that these documents are outputs of analysis work. Since it encompasses information about epics, stories and details, it also assures all three types of requirements are included — business, stakeholder and solution.
This completes the review of these techniques. There are more out there that could be in the article. Do you have any suggestions for techniques? Let me know in the comments.
To know more about the mentioned approaches, each one has at least a dedicated book. I before reviewed them in an article in the Analyst’s Corner, here.
