Options:

Nuno Santos

Requirements Elicitation in Modern Product Discovery

Classifying product techniques by requirements type


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 the three types of requirements: **business**, **stakeholder** and **solution**. If your organization is shifting from project-led to product-led, this article presents an understanding where the techniques fit in this spectrum and will allow a better understanding of how and when to use them. The techniques presented are: "How Might We" (from Design Sprint), Jobs-To-Be-Done (JTBD), User Journeys, Kano Analysis, Continuous Customer Interviews, Opportunity Solution Tree, Story Mapping, and Epic Alignment.

Introduction

There may have been times in the past where business analysis or requirements engineering were (incorrectly) seen as a passive discipline. Some might have held the view that a requirements engineer’s job when “gathering” requirements was, most of the time, attending meetings where they interviewed a group of people and afterwards “producing” a requirements specification document reflecting the analysis and understanding of the information just gathered. Typically, these interviewees had significant roles in the product (although most of the time they wouldn’t be the future users of the solution) and the requirements engineer would simply be a clerk and register all their dictated “wishlist” items.

However, requirements aren’t lying around waiting for someone to collect them[1]. Of course, in this case we are talking about bespoke requirements engineering. Alternatively, one could turn to market-driven requirements engineering approaches, where elicitation is based on the needs of a mass market where customers cannot be clearly pinpointed.

Both these approaches are based on the premise that your sources know what they need and dictate the solution: yet how often is this actually realistic? More often there will be experimentation, change and the need for flexibility. Frameworks like Dual Track Agile from Marty Cagan’s book “Inspired”[2] influenced organisations to split their efforts into product discovery and delivery.

The main shift in the premises of product delivery compared to bespoke or market-driven requirements engineering is that teams have to discover what the user’s problems are. They discover this based on a set of assumptions and validate if a delivered solution contributes to the desired outcome. Thus, the tasks of a requirements engineer are very different to collecting or gathering requirements. They are not “lying around”[1] waiting to be gathered, but rather need to be elicited and, most importantly, to be discovered.

For requirements engineers, this means being involved in both the discovery and delivery processes. With the rise of the agile and experimentation mindset, modern techniques have been developed as support for product management. Requirements engineers may use such modern requirements techniques to challenge stakeholders’ perceptions on any assumed solutions and get to the underlying need.

Alongside adopting them, requirements engineers must also be aware how the techniques are better applied. We will see in this article how well-known techniques have different goals and are aimed for application in different contexts. We will present in this article these techniques for managing business, user and system requirements. The techniques presented are: "How Might We" (from Design Sprint), Jobs-To-Be-Done (JTBD), User Journeys, Kano Analysis, Continuous Customer Interviews, Opportunity Solution Tree, Story Mapping, and Epic Alignment. It will be detailed further that each technique focuses in one of the requirements types. Thus, they can be used, alone or combined, for detailing the problem space – covering the different types of requirements.

What has changed since “traditional” requirements elicitation

Before diving in, let’s note that, by “traditional”, we refer to ways of working in the waterfall era, i.e., before the agile movement. And, for the sake of this article, “traditional requirements” techniques are the ones described from foundational books of the requirements disciplines, such as Klaus Pohl’s “Requirements engineering”[3].

As stated previously, frameworks like Dual Track Agile[2] influenced organisations to split their efforts into product discovery and delivery. The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software. One can also say that in the Discovery track the goal is to “build the right solution”, whereas in the Delivery track the goal is to “build the solution right”.

Figure 1: Dual Track Agile[2]

Additionally, the requirements discipline has been evolving as a much more collaborative approach. And, with that, creativity techniques are getting more and more adoption as a support to requirements elicitation. The CreaRE workshop (Creativity in Requirements Engineering) – part of the International Working Conference on Requirement Engineering: Foundation for Software Quality (REFSQ) Scientific Conference – is dedicated to creativity in requirements engineering. There are at least 30 techniques to support creativity in requirements elicitation[4], which shows how much the discipline has evolved towards collaboration with other participants together with the requirements engineer.

Reminder of the classification of requirements

The International Requirements Engineering Board (IREB) classifies requirements into three categories[3]: business requirements, user requirements, and system requirements. Here's a brief overview of each:

  1. Business Requirements: These are high-level statements that capture the overarching goals and objectives of the organization. Business requirements describe why a project is being undertaken and what the business aims to achieve. They provide the context and strategic direction for the project.
  2. User Requirements: User requirements focus on the needs and expectations of the stakeholders who will interact with the system. They outline the features, functions, and behaviors that the system should exhibit from the perspective of its users. User requirements serve as a bridge between the high-level business goals and the technical details of system design.
  3. System Requirements: System requirements detail the technical specifications and constraints that the system must adhere to in order to meet the user and business requirements. These requirements cover aspects such as software functionalities, hardware specifications, performance metrics, and other technical characteristics necessary for the successful implementation and operation of the system.

Discovery Techniques for Elicitation of Business Requirements

1. “How Might We…” Technique

The "How Might We" technique is a crucial aspect of the design thinking process and is often used in design sprints[6] to frame problem statements and generate creative solutions. A design sprint is a time-constrained, collaborative process used to tackle complex problems and develop innovative solutions. The "How Might We" technique is particularly popularized by the design firm IDEO and is widely used in design workshops, brainstorming, and innovation processes.

The "How Might We" technique involves rephrasing challenges or problem areas into open-ended questions that invite brainstorming and creativity. By using this technique, you encourage your team to think beyond constraints and generate a wide range of potential solutions. Here's how the technique works:

  1. Identify the Challenge: Start by identifying a specific challenge or problem that you want to address. This could be related to improving a product, enhancing a service, or solving a particular issue.
  2. Rephrase into "How Might We" Statements: Take the challenge and rephrase it as an open-ended question that begins with "How might we...?" For example, if your challenge is to improve a mobile app's onboarding process, a "How might we" statement could be: "How might we create a more intuitive onboarding experience for new users?"
  3. Encourage Brainstorming and Ideation: The "How Might We" statements create a platform for brainstorming and ideation. The open-ended nature of the questions invites participants to generate creative ideas without feeling restricted by existing limitations.
  4. Divergent Thinking: During brainstorming, participants are encouraged to explore a wide variety of solutions, no matter how unconventional or seemingly far-fetched they might be. This divergent thinking often leads to breakthrough insights and innovative ideas.
  5. Convergent Thinking: After generating a range of ideas, the team can then engage in convergent thinking by evaluating and selecting the most promising solutions. This is where you refine the ideas and determine which ones have the most potential to address the challenge effectively.

The "How Might We" technique is an effective way to foster a creative and collaborative atmosphere during design sprints and other problem-solving sessions. It shifts the focus from problems to possibilities, and it helps teams explore solutions from different angles, often leading to innovative and unexpected outcomes.

2. Jobs-To-Be-Done

Another recent approach for defining the problem is “Jobs-To-Be-Done” (JTBD)[7]. Based on jobs theory and outcome-driven innovation processes, JTBD encourages us to appreciate why a product or service was “hired” (a JTBD metaphor). This way of defining the problem includes not only the functional dimension, but also the circumstances and emotional dimensions. The JTBD framework allows you to define your jobs: this includes setting your different customers, the different kinds of jobs (core, related, emotional, consumption chain and purchase decision jobs), as well as the desired outcomes[7]. Clayton Christensen’s book “Competing against luck”[8] provides many cases of JTBD and how they were used in comparison to other problem/opportunity framing approaches. A great template from Jurgen Appelo to write the JTBD is depicted in Fig. 2.

Figure 2: based on Jurgen Appello [9]

Discovery Techniques for Elicitation of User Requirements

1. User Journeys

User Journeys, also known as Customer Journeys or User Experience (UX) Journeys, are a product discovery technique that originated from the field of User Experience Design (UXD) and User-Centered Design (UCD). User Journeys provide a visual representation of the user's interactions and experiences while using a product or service. They aim to capture the user's perspective, emotions, actions, and touchpoints across different stages of their interaction with the product.

User journeys are often used as part of the design thinking process. Design thinking is a human-centered approach to problem-solving and innovation that emphasizes understanding and addressing user needs and preferences. The process has 5 stages[10]: Empathize, Define, Ideate, Prototype, and Test. User Journeys are commonly used in the "Empathize" and "Define" stages of the process.

Here's how User Journeys fit into the design thinking process:

  1. Empathize: In this stage, designers aim to deeply understand the needs, emotions, and experiences of the users. User journeys help create a detailed visualization of the user's interactions, thoughts, and feelings as they engage with a product or service. This visualization allows designers to empathize with users and gain insights into pain points, challenges, and opportunities for improvement.
  2. Define: User Journeys contribute to defining the problem space more precisely. By analyzing the user journeys, designers can identify key touchpoints, bottlenecks, and areas of focus. This information helps in formulating design challenges and defining the specific problems that need to be addressed.

2. Kano Analysis

Kano Analysis, although developed in the 1980s, is still very much adopted worldwide in product management. It is a framework used in product development and customer satisfaction management to prioritize and understand customer preferences and how they relate to product features. It categorizes product or service features into five distinct categories:

Figure 3: Kano Analysis framework[11]

Kano Analysis helps businesses prioritize feature development by understanding which features will have the most significant impact on customer satisfaction. It also emphasizes the dynamic nature of customer preferences, as what was once an Excitement Need can become a Basic Need as customers' expectations evolve. By categorizing features and their effects on satisfaction, Kano Analysis provides a valuable framework for product managers and designers to make informed decisions about feature prioritization and customer-focused innovation.

3. Continuous Interviews

Interviews are a crucial part of the elicitation of a product or service’s requirements. Teresa Torres has described a set of “continuous discovery habits”[12]. In this approach, she advocates interviewing and engaging with customers not only in the early stage of product development, but also at a continuous cadence (preferably a weekly one). This enables their actual needs to be discovered and adequately framed. 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 (or opportunities).

Fig. 4 depicts a template for the interview notes based on suggestions for the intended outputs of these interviews.

Figure 4: based on Pawel Huryn [13]

4. The Mom Test

A common mistake is to have interviews around the solution to be developed. But an approach from Rob Fitzpatrick, the “Mom Test”[14], teaches us differently. This metaphor suggests that if you were to ask your mother about a solution, she will always like your idea. However, asking the right set of questions can make her tell what you really need to address.

It has similarities with “Continuous Discovery Habits”, as the questions should focus on their past experiences (e.g., the last time the interviewee used a given product or service) to discover an opportunity. Performing these kinds of interviews allows us to depict the problem as a question, rather than waiting for the interviewees to tell us the solution they want.
Interviewers must ensure stakeholders talk about their life instead of hearing the interviewers’ own ideas for a solution. And, first and foremost, should listen much more than talk. The goal is to truly empathize with them.

5. Opportunity Solution Trees

Teresa Torres has described a technique that is used together with the customer interviews known as opportunity solution trees[12]. The insights from conducting the Continuous Interviews should allow us to identify opportunities for our product.
Opportunity solution trees are a visualisation 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 (Fig. 5).

Figure 5: Opportunity solution tree [12]

Discovery Techniques for Elicitation of System Requirements

1. User story mapping

User story mapping[15] is a very popular technique in the requirements engineering, business analysis, product ownership and product management communities.

It is a technique where team members collaboratively discover how a set of user stories solve a customer problem. 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 (Fig. 6). This in turn ensures that the solution will support the user’s activities that were presented.

Figure 6: User story mapping template; Credits: jpattonassociates.com

2. Epic Alignment

“Epic alignment” is from Nils Janse’s book with the same name and proposes a single source of truth about the requirements, in the form of “lightweight” documentation based around epics. The structure that is proposed for this documentation includes information that is incrementally added to what we know about a given epic throughout the product development stages (namely, Ideation, Discovery, Prioritization, Refinement, Development and Testing).

The structure of these documents allows information in an epic to be followed: which user stories are included, and the details that are needed for their implementation (Fig. 7).

Since it encompasses information about epics, stories and details, it also ensures all three types of requirements are included - business, user and system.

Figure 7: Example of an epic documentation[16]

Click for detailed view of figure 7

Conclusions

Product discovery focuses on ensuring the customer receives a product or service that they value. It does this by understanding their problems, needs, and behaviours, and then creating solutions that are aligned with these factors. Instead of creating a Business Requirements Document (BRD), which can be limiting and inflexible, product discovery leads to the creation of a product backlog that is based on customer feedback, insights, and experimentation. In product management, backlog items are viewed as hypotheses to be validated, rather than fixed requirements, allowing for greater flexibility and adaptation to changing customer needs. Performing product discovery is indeed a shift in requirements elicitation, and the techniques in this article are some examples of how discovery is very different from “requirements gathering”.

References