A Simple Primer on Use Cases in Product Management
Introduction
Use cases describe how different personas put a solution to use and for which events.
The Use Case technique is used in the product management, product development, and product testing domains.
Use cases are interpreted differently in various product development tools and methodologies such as Unified Modeling Language (UML) and Lightweight Software Development (contemporarily known as Agile).
Complicating matters are entrenched and inconsistent variations to the use case, resulting in a myriad of related expressions.
This simple primer outlines product management's perspective of a use case, according to the Blackblot PMTK Methdology™.
The Focus of Use Cases
The Use Case concept is employed in various ways in both the solution and problem spaces.
In principle, the concept of a use case has a similar meaning to product managers and product developers.
Technical people in the solution space, particularly product developers, regard the use case as a design tool that describes how the system will respond to user actions.
Product developers often see the use case as a detailed record of a step-by-step action-result interaction, resembling a workflow analysis developed by User Interface (UI) designers.
However, the methodologies and languages used by product management (problem space) to document user-focused use cases are often very different from those used by product development (solution space) to write product-focused use cases.
User-focused use cases are created by product management (problem space) and later presented to product development (solution space). These use cases are fundamentally focused on the user and its goals.
To provide a developmental context, the product developers often add technical and design details to create a suite of enhanced use cases that will give the product development team with sufficient information to begin designing, developing, and testing the product and its features.
Consequently, there are many instances where the product developers reformat the user-focused uses cases provided to them by product managers to the language used by product development (such as UML) to create product-focused uses cases.
After reformatting the use case, the product developers begin to add the technical and design specifics imperative to the use case.
In Agile/Scrum, the combination of a User Story and Acceptance Criteria is essentially the same as the classic Use Case.
In the Blackblot Product Manager's Toolkit® (PMTK) methodology, use cases in product management are detailed as part of the Blackblot Procedural Requirements Management™ Model (PRM Model) methodology for creating high-quality, usable market requirements.
Use Case Definitions and Clarifications
Use cases define events (specific instances of usage) and describe who (persona) does what (interaction) with the product and for what purpose (goal).
The purpose of use cases is to describe how different personas put a solution to use and for which events.
Use cases are helpful to construe functional requirements and perform system structuring.
Therefore, use cases influence the design of a feature or product, but they are not the design or technical specifications of that feature.
Following are key definitions and clarifications in the Blackblot PMTK Methodology™ that relate to use cases:
- A Use Case is a specific way of using the system by performing some functionality. The collected use cases specify all the existing ways of using the system. Each use case constitutes a complete course of action initiated by an actor, and it specifies the interaction between an actor and the system.
- Uses cases focus on single instances of use. Combining several use cases forms a Scenario. A scenario is a succession of logically linked use cases and is sometimes presented illustratively using a Storyboard (visual representation of the sequence of events).
- In several published books covering the topic of use cases, the Persona may be referred to as the Actor or the User, and the Product may be referred to as the System. These terms are and can be used alternately.
Use Cases in the Problem Space
The second Blackblot PMTK Methodology™ foundation rule states that "Product management resides solely in the problem space."
Does this mean that use cases, which deal with the solution, are part of the solution space and, therefore, not product management's responsibility? The answer is a conditional No.
Use cases are meant to help product developers design and build features via a better understanding of product and user interaction. Corroborating this thought is the notion in UML that "A use case represents a functional requirement, showing what happens, but not how the system achieves it."
This means that use cases are truly about the user's interaction with the product and the user's goals from using the product, and therefore they are predominantly a part of the problem space.
Use Case Writing Scenarios
According to the Blackblot PMTK Methodology™, there are three scenarios for writing use cases:
- A Market Requirements Document (MRD) exists, but no product concept and no Product Requirements Document (PRD) exists. In this scenario, no use cases are written by anyone.
- A Market Requirements Document (MRD) exists, and there is a general product concept, but no Product Requirements Document (PRD) exists, so actual features are not documented. In this scenario, the owner/writer of the Use Cases document is the product planner who may prepare (with the product architect as a contributor) high-level and descriptive use cases which describe how possible future features in the product would be possibly employed by different personas. The Market Requirements Document (MRD) includes these descriptive use cases.
- A Market Requirements Document (MRD) and a Product Requirements Document (PRD) exist, and consequently, there is a definitive product concept and documented actual features. In this scenario, the owner/writer of the Use Cases document is the product architect who prepares (with the product planner as a contributor) detailed use cases that describe how different personas would employ actual features in the product. The Product Requirements Document (PRD) includes these detailed use cases.
Summary
This short primer described the general structure, timing, and nuances of writing use cases from PMTK's product management perspective (not product development).